- From: Birkir Gunnarsson <birkir.gunnarsson@deque.com>
- Date: Thu, 4 Dec 2014 09:20:39 -0500
- To: "'White, Jason J'" <jjwhite@ets.org>, "'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com>, <janina@rednote.net>, "'W3C WAI Protocols & Formats'" <public-pfwg@w3.org>
There are certainly use cases for aria-hidden, yes. But what troubles me is 1. that aria-hidden="false" is not the same as removeing aria-hidden (as indicated in the text that I quoted). 2. That aria-hidden="false" when applied on a note overrides any hiding of that node's descendants. Consider again: <code> <div role="tabpanel" id="tab2" aria-hidden="false"> ... <input type="hidden" value="default value"> <a aria-expanded="false">account history</a> <div style="display: none;"> ... some info </div> -- end of account history tab that is hidden until expanded </div> -- end of tab </code> In this example,if you remove aria-hidden="false" from the tabpanel tag, you will see all info except the hidden input and the account info panel, which is hidden until user expands it. If you set aria-hidden="false" you will see the input panel and the account info content, because aria-hidden="false" on the parent container dictates that. I have already seen this cause bugs in webpages for large corporations and developers are mystified by this situation. It would be logical for me, as a web developer, to say "hey, this aria hidden attribute, cool, I will use it and just set it to false when content is visible, right", it is less work than removing it. The consequences are totally not obvious. If you want all descendants of an element to be visible to assistive technologies, no matter their display settings, that requires an attribute that is affirmative and clear, such as "aria-hiddn="offScreen". Or aria-visible="true". The beauty of ARIA is often that you can tie it with CSS via selectors and it makes it easier to control the display of dynamic content to all users. Obviously aria-hidden="false" and display: block in this case is not the same, one unhindes all the descendants, the other just makes the text visible and leaves display settings of descendants alone. If we get into a situation where ARIA has to be managed separately from CSS, developers will get confused, we will see a lot of errors creep into ARIA use, and ultimately it will become a problem rather than a solution. -----Original Message----- From: White, Jason J [mailto:jjwhite@ets.org] Sent: Wednesday, December 3, 2014 3:05 PM To: Birkir Gunnarsson; 'Bryan Garaventa'; janina@rednote.net; 'W3C WAI Protocols & Formats' Subject: aria-hidden (was RE: 48-Hour Call for Consensus (CfC); Publish 1 ARIA FPWD & 2 ARIA Heartbeats) >-----Original Message----- >From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com] >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. There is a very real need to be able to hide content from the visual presentation while making it available to assistive technologies. Currently, aria-hidden is the best available mechanism for this. I disagree with any suggestion that CSS properties should override aria-hidden. Rather, I think ARIA should be the final determinant of what does and does not appear in the accessibility tree corresponding to a document, irrespective of style properties. ________________________________ This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ________________________________
Received on Thursday, 4 December 2014 14:21:09 UTC