Protocols and Formats Working Group Teleconference -- 19 May 2014

<trackbot> Date: 19 May 2014

<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus

<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.

- DRAFT -

Protocols and Formats Working Group Teleconference
19 May 2014

Attendees

Contents

Summary of Action Items