- From: James Craig <jcraig@apple.com>
- Date: Wed, 13 Oct 2010 15:01:18 -0700
- To: David Bolter <david.bolter@gmail.com>
- Cc: Andi Snow-Weaver <andisnow@us.ibm.com>, Steven Faulkner <faulkner.steve@gmail.com>, W3C WAI-XTECH <wai-xtech@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Oct 13, 2010, at 5:40 AM, David Bolter wrote: > On 12/10/10 4:18 PM, James Craig wrote: >> >> On Oct 12, 2010, at 12:19 PM, David Bolter wrote: >> >>> We have role="presentation". >> >> That's different than aria-hidden. Presentation still exposes text contents. > > Good point, however I don't like the idea of hiding text from AT only. Most of the time, I would agree with you. That said, there are plenty of cases where it's valid to use aria-hidden to hide visible text. We must not *prevent* web authors from using this technique correctly just because we're fearful that some authors might abuse it. If we prevent a valid technique, then we force *all* authors to hack around the issue in non-standard ways. For example, I recently helped someone fix code where the designer wanted a custom looking 'select' list and therefore needed a visible text element representing the value of the select. Instead of implementing a completely custom ARIA listbox, the native select was just hidden from view (but not hidden from AT), and the styled text value was visible at all times. Even though this text was visible, it was a duplicate label to screen readers and was therefore appropriate to hide from the accessibility tree. Sighted on not, each user perceived a single select list with a single value. Another example could be to hide content during modal interaction. For example, the 'rest' of a page's DOM may be hidden from the accessibility tree when a modal dialog is shown. This would result in similar behavior to modal dialogs in desktop applications, where the user is forced to interact with the dialog before proceeding.
Received on Wednesday, 13 October 2010 22:01:51 UTC