- From: Janina Sajka <janina@rednote.net>
- Date: Tue, 6 Mar 2012 19:11:10 +0000
- To: WAI XTech <wai-xtech@w3.org>
- Cc: W3C WAI Protocols & Formats <w3c-wai-pf@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, Leif Halvard Silli <xn--mlform-iua@xn--morm-qoa.no>
The following is taken from the minutes of the WAI_PF Face to Face on 5 March and is being made public pursuant to a resolution of PF recorded in Action-970: http://www.w3.org/2012/03/05-pf-minutes.html#action05 This extracted discussion pertains to the citations identified in the email thread beginning at: http://lists.w3.org/Archives/Public/wai-xtech/2012Feb/0033.html The above was also forwarded as public comments to PF: http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0002.html Extract from the Protocols and Formats Working Group Teleconference 05 Mar 2012 Attendees Present +1.512.973.aaaa, Cooper, Janina_Sajka, Rich_Schwerdtfeger, Joseph_Scheuhammer, Jon_Gunderson, James_Craig, +1.512.973.aabb, Cynthia_Shelly, James_Nurthen, Andi_Snow-Weaver, Mary_Jo_Mueller, Ann_Abbott, AlexQiangChen, David_Bolter, jongund, Tom_Brunet, jcraig Regrets Chair Janina_Sajka Scribe MaryJo, cyns, janina, Rich, Andi, Andi_Snow-Weaver JS: ... Looking at HTML citations are in order. Was sent to public comments last night. <AndiSnow> http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0002.html <jnurthen> scribeNick: jnurthen JS: Need to look at what the HTMLWG folks have seen in our docs which have led them to conclusions that this all will work fine <AndiSnow> http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0002.html JS: This is something we don't need to to look at where these came from <cyns> scribe:cyns http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0002.html UAIG Last Call Comments Disposition, HTML 5 citations We need to look at Leif's mail and find the places where the text is unclear. need to figure out what the right official process is. <richardschwerdtfe> http://www.w3.org/WAI/PF/aria-implementation/#include_elements http://www.w3.org/WAI/PF/aria-implementation/#include_elements <scribe> scribe: cyns first HTML comment is http://www.w3.org/WAI/PF/aria-implementation/#include_elements This is what we were talking abou this morning. <MichaelC> Comment 364 <http://www.w3.org/WAI/PF/Group/comments/details?comment_id=364> we were silent on @hidden in the spec. this morning we added that display:none, visibility:none, aria-hidden SHOULD not be in the tree. The cititation didn't include display:none; visibility:hidden, or @hidden. does @hidden map to role presentation? does the HTML 5 spec say so? <richardschwerdtfe> http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html no, presentation is not mapped to @hidden <janina> scribe: janina rich: as i read it, they say must not, and we just agreed on shouldn't ... their equiv in html5 is hidden none ... we could say for host langs that explicitly say somethng should be hidden, that content should not be exposed to a11y http://www.w3.org/html/wg/tracker/issues/204 cyns: we tend to agree html's issue-204 seem appropriate, regardless of longdesc rich: so mod to uaig, something like "if host lang semantics that define hidden must not be exposed to a11y api" ... "however if determined by aria-hidden alone, it's a should not" ... reason can't put the text in the dom is that it can't be walked ... can't nav it because it's hidden ... when we do describedat, will ask browsers for a vehicle to render that location cyns: implementing this feature makes it act exactly like ie's longdesc, markup is flattened into string text <MichaelC> I've entered the comments from the message as 8 discrete comments: https://www.w3.org/WAI/PF/Group/comments/list?comment_id[]=363&comment_id[]=364&comment_id[]=365&comment_id[]=366&comment_id[]=367&comment_id[]=368&comment_id[]=369&comment_id[]=370 <MichaelC> a few said "no comment" so I didn't add anything <richardschwerdtfe> Proposal: Any host language native semantic for hidden (display:none, visibility:hidden, HTML5 @hidden) that states that an element is hidden, the element and its descendants MUST NOT appear in the accessibility tree. An element market that is hidden solely through the provision of an aria-hidden attribute set to "true" SHOULD NOT be exposed as an object in the accessibility tree. The exclusion in the accessibility tree includes its descendants. thanks, michael <clown> "element *marked*' <richardschwerdtfe> Proposal: Any host language native semantic for hidden (display:none, visibility:hidden, HTML5 @hidden) that states that an element is hidden, the element and its descendants MUST NOT appear in the accessibility tree. An element that is hidden solely through the provision of an aria-hidden attribute set to "true" SHOULD NOT be exposed as an object in the accessibility tree. The exclusion in the accessibility tree includes its descendants. Now looking at next item -- 2 of 9 <clown> 2 of 9 is: http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_relations_reverse_relations thanks, clown <clown> my pleasure janina agreement in room to add language 'unless hidden re sec 5.1. ...' now discusing wether we actually are in agreement ... considering content visible only when requested ... dscribedby and labeledby have the extra feature that grabs a string for 5.6.3.2 <richardschwerdtfe> A reverse relation exists when an element's ID is referenced by a property in another element. For APIs that support reverse relations, user agents MUST use the mapping defined in the following table when an element's ID is referenced by a relation property of another element and element corresponding to the element's ID is exposed as an object in the accessibility tree. <richardschwerdtfe> A reverse relation exists when an element's ID is referenced by a property in another element. For APIs that support reverse relations, user agents MUST use the mapping defined in the following table when an element's ID is referenced by a relation property of another element and element corresponding to the element's ID is exposed as an object in the accessibility tree as defined in section 5.1.1. <annabbott> cys: All ARIA references must point to an element that is exposed as an accessible object in the accessibility tree. When the referenced object is not exposed in the accessibility tree (e.g. because it is hidden <link>, the reference is null. aria-labelledby and aria-described by have an additional feature, which allows them to pull a flattened string from the referenced element to populate... <annabbott> ...the accname or accdescription fields of the accessibility API. This feature is described in the Name Calculation section <link>. <clown> ;-) rich: if something isn't exposed in the a11y tree, there's no mapping cyns: the confusion comes from the referenced ones, not the others now to 3 of 9 <clown> http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table <clown> ^ 3 of 9 cyns: we may want to consider whether reverse relations is the correct locus for the above ... rich: think if it's hidden, it's not mapped ... my surmisal based on the html comments i see asw: so not every section, but more than once, so where? rich: suggest a note ... just to make sure another errant thread isn't waiting to be pulled now 4 of 9 <clown> 4 of 9: http://www.w3.org/WAI/PF/aria-practices/#Descriptions_external rich: we need to take the reference to the link out jn: we use this a lot, something very similar, a description of a screen shot ... we use longdesc clown: this is to get the same result via describedby cyns: so an example, this one good, this one not may be the needed clarification. jn: a wcag failure technique ... it works fine if visible, and good for that <richardschwerdtfe> *ACTION:* joseph Modify section 4.1.2.3 in the APG to limit the cases where the "d link" example does not work when the description is "hidden" per the ARIA 1.0 glossary definition of hidden [recorded in http://www.w3.org/2012/03/05-pf-minutes.html#action04] <trackbot> Created ACTION-969 - Modify section 4.1.2.3 in the APG to limit the cases where the "d link" example does not work when the description is "hidden" per the ARIA 1.0 glossary definition of hidden [on Joseph Scheuhammer - due 2012-03-12]. now 5 of 9 <clown> http://www.w3.org/WAI/PF/aria-practices/#Descriptions_tooltip <MichaelC> action-969: for comment 366 https://www.w3.org/WAI/PF/Group/comments/update?comment_id=366 <trackbot> ACTION-969 Modify section 4.1.2.3 in the APG to limit the cases where the "d link" example does not work when the description is "hidden" per the ARIA 1.0 glossary definition of hidden notes added jn: a lot of code for something fairly simple cyns: needs to be focusable rich: anything to change here? cyns: don't think so, but need to point out this doesn't solve the problem rich: far too much work--more work than dlinks ... far too much work for the author agreement in room: longdesc and describedat are preferable to this because they're so very much simpler simpler means it happens more often, and it's correct more often <clown> http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_remaining_description now on 6 of 9 cyns: no examples of using longdesc in our doc, because ours is an aria doc, and longdesc examples need to be in the html docs jn: we have more ... cyns: it's true that describedby ws designed to solve problems not solved by longdesc, but it was to handle certain shortcomings not a full replacement ... point that describedby is for in page references rich: describedby exists because visible descriptions usually accompany figures ... in these circumstances authors don't want to create another page with that content cyns: navigation still jumps jn: so describedby goes on more elements than just image mc: the earlier discussion was that describedby becomes overloaded if we try to have it accept both internal and external references <Zakim> MichaelC, you wanted to say we can start ARIA 1.1 now, we just have to consider impact on the 1.0 timeline <clown> brb We're regathering ... <richardschwerdtfe> scribe: Rich <richardschwerdtfe> Rich: Response text to 6 of 9 as to why longdesc was not covered by aria-describedy - We originally defined aria-describedby with the assumption that off-page content was handled elsewhere. <richardschwerdtfe> Rich: leaf blower says hi <clown> http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_remaining_description <richardschwerdtfe> Rich: This is the response? <richardschwerdtfe> Michael: yes <richardschwerdtfe> Rich: we should remove this text: "This is unlike longdesc which typically requires the author to create a separate file to describe a picture. It is preferable to have the descriptive text in prose as well so that it is readily available to all users. Yet, like longdesc, descriptive text is treated separately from the short name provided by the title or alt attributes in HTML. " <richardschwerdtfe> jonG: In jaws they concatenate the description with the label <richardschwerdtfe> cynthia: for an image though? <richardschwerdtfe> jonG: I am not sure about an image <richardschwerdtfe> janina: what foliot had been saying is accedescription is auto read <richardschwerdtfe> cynthia: he does say "why this is preferable?" <richardschwerdtfe> Rich: We can say we like aria-describedby for visible descriptions as web developers did not like having to create another page for the description and because cognitively impaired users could often get confused when having to switch context to go to another page to get the description. <richardschwerdtfe> Rich: Hidden text is not readily available to all users. It is not available to visual users. Hidden text was only supported because Freedom Scientfic was directing developers to supply special JAWS attributes to provide help text that could be applied to individual form elements. We allowed for hidden content to be used for accessible descriptions to aid blind users and standardize the feature. <richardschwerdtfe> Rich: With respect to alt and longdesc, it is not the responsibility of the ARIA Authoring Practices Guide to document how to use the accessibility features of HTML. So, if we did not document fully either ALT or longdesc that is acceptable. Perhaps an Authoring Practices Guide should be created for HTML 5. <clown> 7 of 9 http://www.w3.org/WAI/PF/aria/states_and_properties#aria-describedby <richardschwerdtfe> jon: for aria-describedby on an image the JAWS key+alt+r reads the description upon user request. It also tells you that a description is present. <clown> 8 of 9: <clown> http://www.w3.org/WAI/PF/aria/roles#textalternativecomputation <clown> Skip hidden elements unless the author specifies to use them <clown> > via an aria-labelledby or aria-describedby being used in the current <clown> > computation. <richardschwerdtfe> jon: in this version of NVDA there is not a command for getting the description but I don't know that I have the latest version <richardschwerdtfe> cynthia: the text alternative computation talks about how to compute the text string. It is clear. There is a difference between accessible objects in the tree an the string <richardschwerdtfe> janina: is there any objection to extracting this portion of the minutes and exposing it to wai-xtech? <richardschwerdtfe> RESOLUTION: no objection <richardschwerdtfe> *ACTION:* Janina: Respond to wai-xtech discussion on the use aria-describedby for longdesc [recorded in http://www.w3.org/2012/03/05-pf-minutes.html#action05] <trackbot> Created ACTION-970 - Respond to wai-xtech discussion on the use aria-describedby for longdesc [on Janina Sajka - due 2012-03-12]. -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Chair, Open Accessibility janina@a11y.org Linux Foundation http://a11y.org Chair, Protocols & Formats Web Accessibility Initiative http://www.w3.org/wai/pf World Wide Web Consortium (W3C)
Received on Tuesday, 6 March 2012 19:11:36 UTC