See also: IRC log
<trackbot> Date: 19 May 2014
<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus
<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-pfwg/2014May/0061.html
<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-pfwg/2014May/0061.html
<MichaelC> scribe: andrewlarkin
jc: Hearbeat draft:
... aria stuff next on list
cg: some ancilliary annotations.
Come up with some grey issues
... tokenized list for aria annotation
... reduced flexibility in the future
... but advantages - apply multiple aria annotation types
... allow screen readers to have customizations on a per
annotation level
... placing aria-annotation type on annoatation, not tet
... *text
... if type is not in DOM, how do you know what type of
annotation it is
... we should make it clear and simple, that is the annotation
type
... concerns?
rs: two parts
... have things like a note, need relationship to what you're
annotating
... also global spelling checkers
cg: I agree with aria-invalid
points
... this is more around comments and footnotes and such
rs: let's say we have a comment
on a range of content
... what are you going to put on the relationship
... you may have teh comment elsewhere in the doc
cg: could use localized roles,
but
... define that relationship, put in document, some sort of id
ref list that points elsewhere
<jcraig> <el aria-annotatedby="ann">some annotated</el>
jc: we have some annontated
text
... then annotation might be a div, say role=annotation
... aria local role is note, or special note
... other is aria-annotation-type?
cg: could be replaced by localized role
jc: we watn annotation-type as tokenized list
<jcraig> <div role="annotation" aria-locrole="Special Note" aria-annotationtype="note">the annotation</div>
cg: if we want to replace it with localized role
<jcraig> id="ann"
jc: concept we discussed is that
annotationtype is recognized token
... so if there is special behavior for screen reader or
AT
... I do want to hear notes, but not deletions, for
example
... trigger specialized behavior based on type
... annotationtype would be localized string
... don't want to make them exclusionary
cg: localized roles wouldn't have screen reader understand what kind of annotation that is
jc: annotationtype is mandatory,
localized optional
... question for engineers?
cg: i'll get to it, let me cover
other stuff first
... or that is next
... in original proposal aria-annotatedby
... overwhelming majority is to cut aria-annotationfor
... browser can do mapping
... spoke with some IE devs
... historial reason for no reverse relationship mapping,
anytime we loaded DOM we'd have to check reverse relationship
for every attr
... idea is if statement for each attr adds up
... we're investigating
... we'll look at Firefox implementation
... at this point, the voice is let's remove aria-annotationfor
and leave it to the browser to do reverse relationship
jc: other browsers have done fast
lookups using attribute selectors to create reverse
relationships
... give me any element that matches *[aria-annotatedby],
return list, don't have to do it on every element
rs: do you have a list of base types?
cg: i can pull together for next
time
... accounting for annotations that aren't in the DOM
... suggestion to look into indie UI
... still looking into it, spoke w/ Cynthia on PF call
... we don't want to make annotation-specific solution
(thanks James)
jc: let's move on with solutions we have
rs: do we want to wait?
jc: recommend accepting
proposal
... whether or not it's necessary for 1.1
... no problem putting it in 1.1.
rs: there's a number of products that could use this
jc: all of these are valid and necessary
rs: too big to push it off
... i don't see any objections
... waiting on annotation types
... we also have role=note
... if we have localized roles, do we need annotation
types?
jc: it's possible we could skip
annotation role if you want to use note for this
... if you're doing read all in a screen reader, you want to
hear insertions, but not info about deletions
... you might want to do this when exploring line by line
... don't see how screen reader can do that logically without
differentiation type
rs: I could see someone wanting to put annotationtype on a note
jc: let's put it in Call for
consensus
... specifically call out if role=annotation is necessary or if
role=note suffices
rs: I'll take care of sending it out
cg: I'll come back with
types
... last things
... overlapping annotations
... we talked about, provided example of suggetstion: have two
tokens
... for aria-annotation for, id ref list would have two
... broken up into first span have annotation type of comment,
second annotation type of comment and reference, third just
reference
... poor design to rely on screen reader to identify adjacent
spans as related
... open to suggestions
jc: I think I heard you say
opposite of what we said before
... annotationtype on span and anotationfor on annotation
itself?
cg: I mispoke, i meant annotationby
<jcraig> <span aria-annotatedby="ann1">not overlapping</span>
<jcraig> <span aria-annotatedby="ann1 ann2">overlapping</span>
jc: pasting it in...
<jcraig> <span aria-annotatedby="ann2">not overlapping</span>
jc: these would be siblings
... inside one is overlapping
cg: screen reader or api could determine that two adjacents point to the same id.. concerns that it's not explicit
jc: given that markup has to be
well formed, what are the options?
... we might use attributed strings, but no pattern for that in
the web
... did devs have alternate proposal
cg: not at this point. If there
are any suggestions, great
... html does not allow for this thing too well
jc: they may discuss it with team
that works with rich text editing
... same thing happens with adjacent spans for bold and
italic
cg: rich text editing working group?
jc: no, just the people working on it
cg: that's the last item
rs: alright, next - issue 587
jc: does it make sense for Chris to update his proposal
cg: currently in pdf, just update and send out pdf? or some other place to put it
rs: put this out in text, is pdf accessible
cg: yes
rs: text better
js: here's what we discussed
doing
... we're looking to identify consensus, right?
... useful if subject said as such
... and annotations
... ususal we ask a minimum of 48 hours
rs: we can discuss in Monday's next meeting
cg: I won't be here for next two weeks
rs: 31st is memorial day
js: 26th
jc: I'll be out june 2nd
rs: we're not going to be meeting
on monday for sure
... ok, discuss at next regular meeting at 2nd
cg: I'll be on vacation
js: james, too
rs: we'll give people a chance to discuss it then
jc: sounds good
<jcraig> issue-587?
<trackbot> issue-587 -- Consider allowing the aria-selected state on any focusable element, or add a new attr like aria-active or aria-current -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/587
rs: moving on issue 587 - introduction of aria-current
<richardschwerdtfeger> issue as this should not feed into a selection model on some platforms
<richardschwerdtfeger> - We did agree to keep aria-selected on tabs for backward compatibility
<richardschwerdtfeger> and because it is working.
<richardschwerdtfeger> - We need a way to refer back to the container as ATs don't want to hunt
<richardschwerdtfeger> the DOM for this information
<richardschwerdtfeger> - A challenge is that we need reverse relations on some platforms
<richardschwerdtfeger> - There was a concern over syntax
<richardschwerdtfeger> - This discussion is to try to reach consensus on a way forward.
<richardschwerdtfeger> - https://www.w3.org/WAI/PF/Group/track/issues/587
<jcraig> Note from last week was Cooper proposed aria-currentfor="IDREF" in today's call.
rs: last thing was
aria-currentfor relationship
... are people accepting taking that approach?
... would allow us to know what item is current for current
container
... not specific to type, in general. Things like
navigation
... some widgets
... leave a grid, want to know where you left off -
context
... we'd have to look at current roles
... do people agree with semantics?
<Zakim> jcraig, you wanted to say on link for link list, on listitem for trains, etc.
jc: we'd be remiss if we failed
to mention that Cynthia had issue with currentfor
... requires authors to do more than use aria-current
... also, yet another thing that relies on a fixed ID
... idref great in some regards, but gotten us into areas we
want to get out of, like with activedescendant and shadow
DOM
... whatever solution for that problem we could insert
here
... long term is we don't have a great solution
... using selectors as idref
... current with boolean is easier
<Zakim> MichaelC, you wanted to toss out ideas of scope property and selector value type
jc: currentfor more explicit, less flexible
rs: we don't want AT to hunt the DOM for it either
mc: current and a boolean attr
and something like scope. Forces two attrs, but only when you
need scoope
... can define the attribute as a selector
cs: id ref, also can have role, I think there are times when you want to use an id ref is good sometimes, but want to
<Zakim> joanie, you wanted to ask in what case the current element and the current container would not both be in the dom but still be of interest?
jd: there are cases with shadow DOM can't point. Wouldn't there be cases when they're not in the DOM and not relevant?
(forgot Joanie's last name, sorry!)
<joanie> diggs
awesome thants
jd: not convinced I'm understanding using containers...
cs: that's kinda why I liked
Michael's scope
... go to nearest ancestor that has role=nav
jc: what about tying to the aria-scope proposal?
<jcraig> aria-scope="selector([role=nav])"
cs: not up on selectors proposal
<jamesn> wouldn't that be any nav?
jc: insert selector where you would insert idref
cs: like a css selector
... i like it
jc: could point to selector in
shadow DOM
... likewise, could say aria-activedescendant is
aria-active=true
... were discussing equivalent of queryselector=all
... could have queryselector upwards
... if it's an ancestor it would be really easy to
implement
jn: other would be xpath or xpointer
cs: does it work in html?
rs: too much for author to remember path
jc: not common enough
... every web dev knows CSS
cs: political allergy to XML
rs: how far back does query selection go?
cs: I'd have to look in IE
<bgaraventa1979> reverse css selectors are common in libs like jQuery
rs: doing this in javascript is different
jc: might be able to do this in
CSS4, subject selector, go partway up the chain
... might be reverse selector as well
rs: let's look into this
... cynthia, can we give you action to look at how far back
selector goes in IE?
jc: it's available in current browser versions
<richardschwerdtfeger> ACTION: Cynthia check how far back querySelector goes in IE [recorded in http://www.w3.org/2014/05/19-aria-minutes.html#action01]
<trackbot> Created ACTION-1441 - Check how far back queryselector goes in ie [on Cynthia Shelly - due 2014-05-26].
jc: not like we have a backwards compatibility
rs: I have to deal with on a regular basis w/ gov't customers
jc: going forward, aria-currentfor will only be implemented in browsers with querySelector supported. No user agent is going to back-port aria-currentfor to some previous UA that doesn't have querySelector implemented.
cs: might need some try
catches
... if aria-currentfor isn't there, it's what we have now
... should be able to handle it with error control
... shouldn't need to browser sniff
... maybe I'm missing something...
jc: even screen readers have
error handling... if not recognize id, won't read it
... not a spec bug
rs: are screen readers going to resolve the querySelector from the DOM
jc: any screen reader should have error handling for non-matching ids
cs: fail silently or do
something, which is better than now
... shouldn't result in breakage
jc: and if it does, bug in screen reader
rs: you think there going to be
able to call a querySelector
... if we pass querySelector, it has to resolve to somewhere in
the DOM
... don't know if AT can call querySelector
jc: any AT should fail silently
with new syntax
... this is not going to match any idref
rs: but what if they wanted to
determine currentfor
... you'd like them to go back to the node
jc: are you saying we should not implement this...
rs: maybe this is an opportunity
to get them out of the DOM and into the api
... what ends up happening is that you have customers that say,
oh you don't work with IE
... never goes to AT
cs: I agree, it should go through
API
... and if you're using the newest version of IE it should
work
rs: most of he windows vendors
with IE are using the DOM
... I would like to look into it
... just saying maybe when we run into this... is it easy to
refer back to the accessible from the DOM in IE
cs: I don't think so
jc: ECMAScript you can map keys
to DOM elements
... pretty awesome
... ECMAScript 6
... can use a DOM element to map back to JS view controller
(that is awesome)
rs: do we want to go forward with querySelector
<jcraig> ack q+Map
<Zakim> jcraig, you wanted to ask who is here from 415 area code?
jc: I was just point of order... who is 415
bg: that was me
rs: if we do this we're opening a
can of worms
... we can wait another week, but do we want to go for using
querySelector here?
jc: I think we should move
forward using idref, we can later add selector
... will get pushback if we do it now with selector
cs: this is just another use case for shadow DOM and selectors
rs: have to look if that's in aria 1.1 products
<jcraig> issue-653?
<trackbot> issue-653 -- Need to support selectors in ARIA relationships -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/653
rs: probably is face to face item
<jcraig> action-1427?
<trackbot> action-1427 -- James Craig to Propose (at-risk) solution for selector references to be used in conjunction with IDREF -- due 2014-04-28 -- OPEN
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1427
jc: we don't know if there's any type of precedent for this kind of thing
rs: are two linked?
jc: yes
rs: close 653...
jc: no, don't close it
... gonna propose solution, but not done
... could propose resolution for current / currentfor
... we want both?
rs: if we had selector, I wouldn't want scopoe
cs: i thought start with idref and selector later
mc: if we're gonna have current and scope or currentfor, i'd rather go for scope
<jcraig> aria-current="true/false" aria-scope="IDREF"
mc: two versions is
confusing
... selector is separate issue that shouldn't impact decision
for current
... can leave as idref for now
jc: I agree
... move ahead with aria-current and aria-scope
rs: don't know how aria-scope would work for labelledby
mc: might cause us to revisit
other things
... even if it doesn't apply to other things now, it may in the
future
rs: you can have labelledby, controls, would you apply it to all of those?
mc: not ready to decide on
that
... the scope would be a bit like controls
... general way of associating one element with another. Says I
have meaning in the context of the other.
rs: controls could be elsewhere,
don't know how those two could be put together
... I like the idea, don't know how we can apply it
jc: implies for relationship
instead of by relationship
... implies upwards direction
... scope means variable scope in prog lang
... is this in the scope of some ancestor block
rs: is aria-scope semantically similar to scope attribute
jc: this is the problem with 1.1 ballooning, even I'm not sure what's in the draft always
rs: I don't think we had aria-scope before today
jc: scope we decided was not necessary because of col header and row header for those
rs: if we're introducing scope anyway we should revisit
jc: in either case, james nurthen raises good point... authors might mix up @scope
<jcraig> mc: @aria-context
cs: sounds like naming is an issue
jc: I think I like context
... it means the same thing in CSS
... in all those cases very much the same def
rs: when you say context, this is
context within which aria-current would reside?
... can't be guaranteed controls would be impacted
<jcraig> In CSS, means the same thing: contextual selectors, positioning context, etc.
rs: labelledby, flowto,
describedby...
... I think limited to certain attributes
... current could apply...
... we should say which attributes it applies to
... as long as it's not everything
... ok, we have consensus
... right, context would apply to container of some sort
... summarize: aria-current is boolean
... which would indicate current item in context
... aria-context take idref, in future possibly some other
reference (selector, etc)
... would apply to container of the aria-current that it
applies to
... may apply to other attributes
<jcraig> issue-587?
<trackbot> issue-587 -- Consider allowing the aria-selected state on any focusable element, or add a new attr like aria-active or aria-current -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/587
jc: we still have more to think about... are we in agreement to make this an editorial action?
rs: I think we are at this point
jc: we don't need final HTML,
just need language
... I want member of group is because I have 70+ actions
rs: I'm happy to take action, it'll take me some time to review
bg: I'd be happy to try to take it on
js: raised by steve faulkner
jc: bryan you want to take this one?
bg: yeah, if you send me details on how to do that
<richardschwerdtfeger> ACTION: Bryan create spec. text for aria-context and aria-current [recorded in http://www.w3.org/2014/05/19-aria-minutes.html#action02]
<trackbot> Created ACTION-1442 - Create spec. text for aria-context and aria-current [on Bryan Garaventa - due 2014-05-26].
<jcraig> action-1442
<trackbot> action-1442 -- Bryan Garaventa to Create spec. text for aria-context and aria-current -- due 2014-05-26 -- OPEN
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1442
<jcraig> trackbot, associate action-1442 with issue-587
<trackbot> action-1442 (Create spec. text for aria-context and aria-current) associated with issue-587.
<richardschwerdtfeger> ACTION: Cynthia check earliest version of IE implmented querySelector [recorded in http://www.w3.org/2014/05/19-aria-minutes.html#action03]
<trackbot> Created ACTION-1443 - Check earliest version of ie implmented queryselector [on Cynthia Shelly - due 2014-05-26].
rs: ok... we have 15 minutes
left...
... let's go on to something less meaty
jc: I have a thought..
... one of the reasons the Accessibility API on iOS has been
successful is because we kept it simple
... when we run into something complex we find adoption to be
constrained by that complexity
... not pointing out specific attr
... but anything we add is increasing complexity
... we should avoid unnecessary complexity
... context may be something that can replace attributes
... may combined pressed, selected, checked
... all similar but on similar roles
... topics we can combine to make adoption easier
(+1 to jc)
cs: combining particularly of checked and pressed
jc: our screen reader implements selected, same as checked
cs: we have selected and
toggled...
... I think there are lots of different ways to slice this
stuff
rs: pressed and checked have been together since... forever
mc: relationship to accessibility
APIs is important, simplicity is important...
... we took up a simplification, and when Lisa game back said,
oh, no you ruined...
... how much do we want to let taxonomy drive decisions
jc: taxonomy should not drive decisions
cs: agree
rs: helped us clean up a lot of
things
... things that were helpful for us is that there was a lot of
duplication
cs: is it immplemented anywhere?
mc: every now and then someone
asks me about RDF
... but nothing significant
jc: to my knowledge, no user
agent uses it in implementation
... chrome doesn't, either
rs: let's see... if
something...
... let's wrap up
zakim: bye
<richardschwerdtfeger> trackbot, make minutes
<trackbot> Sorry, richardschwerdtfeger, I don't understand 'trackbot, make minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/aria-annotatedby/*[aria-annotatedby]/ Succeeded: s/fast lookups to create/fast lookups using attribute selectors to create/ Succeeded: s/has *[aria-annotatedby]/matches *[aria-annotatedby]/ Succeeded: s/soltution/solution/ Succeeded: s/role=annotation is necessary/role=annotation is necessary or if role=note suffices/ Succeeded: s/curernt/current/ Succeeded: s/j: there are cases/jd: there are cases/ Succeeded: s/aria-currentfor will only be implemented in browsers with querySelector/going forward, aria-currentfor will only be implemented in browsers with querySelector supported. No one is going to back-port aria-currentfor to some previous UA that doesn't have querySelector implemented./ Succeeded: s/No one is going to back-port/No user agent is going to back-port/ Succeeded: s/james raises good point... authors mike mix up/james nurthen raises good point... authors might mix up @scope/ Succeeded: s/no user agent uses it in implementation/to my knowledge, no user agent uses it in implementation/ Found Scribe: andrewlarkin Inferring ScribeNick: andrewlarkin WARNING: No "Topic:" lines found. Default Present: +49.322.110.8.aaaa, rich, +1.603.882.aabb, joanie, +1.215.286.aacc, +1.512.445.aadd, Leonie, Michael_Cooper, jcraig, Stefan_Schnabel Present: +49.322.110.8.aaaa rich +1.603.882.aabb joanie +1.215.286.aacc +1.512.445.aadd Leonie Michael_Cooper jcraig Stefan_Schnabel Found Date: 19 May 2014 Guessing minutes URL: http://www.w3.org/2014/05/19-aria-minutes.html People with action items: bryan cynthia WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]