- From: Birkir Gunnarsson <birkir.gunnarsson@deque.com>
- Date: Wed, 3 Dec 2014 14:53:33 -0500
- To: "'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com>, <janina@rednote.net>, "'W3C WAI Protocols & Formats'" <public-pfwg@w3.org>
There is an additional problem related to the text and aria-hidden attribute. The text that Bryan quoted (problematic section of text marked with asterisks(: "If an element is only visible after some user action, authors MUST set the aria-hidden attribute to true. When the element is presented, *authors MUST set the aria-hidden attribute to false or remove the attribute, * indicating that the element is visible. Some assistive technologies access WAI-ARIA information directly through the DOM and not through platform accessibility supported by the browser. Authors MUST set aria-hidden ="true" on content that is not displayed, regardless of the mechanism used to hide it. This allows assistive technologies or user agents to properly skip hidden elements in the document." This text equates setting aria-hidden to false with removing the aria-hidden attribute. As indicated in recent discussions, it appears the new intent is that aria-hidden="false" overrides any CSS attribute, such as display: none, or type="hidden" for <input> elements. <div style="display: none;" aria-hidden="false" <input type="hidden" value="Default value"> </div> This is already causing confusion with Voiceover 8.1 testing where a lot of <input type="hidden"> fields are popping up inside containers with aria-hidden="false". If aria-hidden attribute is removed altogether, those would indisputably remain hidden. So this text definitely needs to be addressed. As a larger, and separate, problem, I think aria-hidden="false" should not override CSS display settings. If there is an absolute need for content to remain visible to assistive technologies whilst being removed with CSS, there should be a more explicit attribute for aria-hidden, such as aria-hidden="visible". But I will post that as a separate thread. Thanks -Birkir P.S. I still support the CFC, provided that the details will be fixed in subsequent drafts, Rome was not built in a day, neither was Florence, South Carolina. -----Original Message----- From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] Sent: Wednesday, December 3, 2014 2:37 PM To: Bryan Garaventa; janina@rednote.net; W3C WAI Protocols & Formats Subject: RE: 48-Hour Call for Consensus (CfC); Publish 1 ARIA FPWD & 2 ARIA Heartbeats Also, the statement "If an element is only visible after some user action, authors MUST set the aria-hidden attribute to true." This looks like the spec text is saying that you should put aria-hidden='true' on visually displayed elements? -----Original Message----- From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] Sent: Wednesday, December 03, 2014 11:28 AM To: janina@rednote.net; W3C WAI Protocols & Formats Subject: RE: 48-Hour Call for Consensus (CfC); Publish 1 ARIA FPWD & 2 ARIA Heartbeats There appears to be a conflict regarding the aria-hidden attribute spec text and what is actually recommended for its use. E.G at https://rawgit.com/w3c/aria/eaf032dc62e0dc3c25b76db0f2300f972eff6977/aria/ar ia.html#terms Under Terms > Hidden, it states the following in a note: "Note: Authors are reminded that visibility:hidden and display:none apply to all CSS media types ; therefore, use of either will hide the content from assistive technologies that access the DOM through a rendering engine. However, in order to support assistive technologies that access the DOM directly, or other authoring techniques to visibly hide content (for example, opacity or off-screen positioning), authors need to ensure the aria-hidden attribute is always updated accordingly when an element is shown or hidden, unless the intent of using off-screen positioning is to make the content visible only to screen reader users and not others." This makes sense, since it would ensure that aria-hidden is not needed on elements that already include display:none, but would be included within offscreen layers such as within carousels so that only the currently visible slide is shown at one time. It also provides instruction for when offscreen text should not include aria-hidden in order to provide screen reader accessible information when needed. However, within the spec text at https://rawgit.com/w3c/aria/eaf032dc62e0dc3c25b76db0f2300f972eff6977/aria/ar ia.html#aria-hidden It states the following: "If an element is only visible after some user action, authors MUST set the aria-hidden attribute to true. When the element is presented, authors MUST set the aria-hidden attribute to false or remove the attribute, indicating that the element is visible. Some assistive technologies access WAI-ARIA information directly through the DOM and not through platform accessibility supported by the browser. Authors MUST set aria-hidden ="true" on content that is not displayed, regardless of the mechanism used to hide it. This allows assistive technologies or user agents to properly skip hidden elements in the document." The spec text directly contradicts the guidance in the note, by saying that all hidden content, offscreen or otherwise, must include aria-hidden='true'. -----Original Message----- From: janina@rednote.net [mailto:janina@rednote.net] Sent: Wednesday, December 03, 2014 10:37 AM To: W3C WAI Protocols & Formats Subject: 48-Hour Call for Consensus (CfC); Publish 1 ARIA FPWD & 2 ARIA Heartbeats Colleagues: This is a Call for Consensus (CfC) to the Protocols and Formats Working Group to approve publication of the following three ARIA related documents: * A First Public Working Draft (FP:WD of the Accessible Name and Description: Computation and API Mappings https://rawgit.com/w3c/aria/6cd22e8b0a834c4a54b7c6e4496a5887cc43f7ea/accname -aam/accname-aam.html * Updated (heartbeat) drafts of the following 2 documents: Core Accessibility API Mappings 1.1 https://rawgit.com/w3c/aria/edfde333e76d19c4bf7a421978eaf89b7d9701e6/core-aa m/core-aam.html Accessible Rich Internet Applications (WAI-ARIA) 1.1 https://rawgit.com/w3c/aria/eaf032dc62e0dc3c25b76db0f2300f972eff6977/aria/ar ia.html ACTION TO TAKE According to our agreed Consensus Procedures, this CfC is now open for objection, comment, as well as statements of support via email. Silence will be interpreted as support, though messages of support are certainly welcome. If you object to this proposed action, or have comments concerning this proposal, please respond by replying on list to this message no later than 17:00 (5PM) Boston Time on Friday 5 December. Janina -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols & Formats http://www.w3.org/wai/pf Indie UI http://www.w3.org/WAI/IndieUI/ -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols & Formats http://www.w3.org/wai/pf Indie UI http://www.w3.org/WAI/IndieUI/
Received on Wednesday, 3 December 2014 19:54:03 UTC