HTML5 Accessibility Chops: hidden and aria-hidden support on the UP!

Steve Faulkner says:

Hi Stefan,

I think we just need a better method for “screen reader text” now, i.e. for text that is not visible but announced by screen reader.

We already have the beginnings of support for it with hidden/display:none + area-hidden=false. This combination is currently supported by By JAWS/IE, TalkBack/Chrome and Chromevox/Chrome OS

Steve Faulkner says:

hi Marie,

aria-hidden=true => nothing in styles/etc, relevant to screen readers but not sighted users

correct

hidden => is hidden (with or without styles, depending on browsers) from both sighted users and screen readers

The HTML5 hidden attribute hides content from display it also is semantic indicator that content is the hidden state, it is typically implemented in browser by a CSS display:none rule in the user agent style sheet. This does mean that authors can override the display effect of hidden by setting display:block on a &alt;element hidden>.

hidden + aria-hidden=false => As above

What this combination means is that content is hidden from visual display and has a state of hidden, but is not in the hidden state in the accessibility tree, so should be available to users of software that expose content to users based on whats in the accessibility tree (such as screen readers).

Stomme poes says:

quote: ” and if it’s relevant only to screen readers (say a label to something that’s obvious to a sighted user), I should set it to hidden + aria-hidden=false?”

Hm, even an obvious label is still something that you’d say “belongs” in the web content, so an off-screen positioning (unless you’ve got rtl stuff going on) is backwards-compatible, matches the semantics of “form fields have labels” and currently still works better than aria-hidden. I think I even see using aria-hidden as a replacement for off-screen positioning as a hack for rtl pages, because while it would work better, it would semantically be saying “there really shouldn’t even be a label here as far as all UAs are concerned”. Which isn’t usually true in this situation; it’s usually a design- and possibly usability-thing to hide the “obvious” label.

I think of using “hidden” the way we have input type=”hidden” for sending additional info to scripts… we wouldn’t actually give that input to any users, anywhere, no matter what, so now these inputs should have a default “hidden” attribute (?) and I assume an implicit aria-hidden attribute too.

There was also a mention on WebAIM comments of using aria-hidden in the cases of something like a dialog box, where once that dialog is open, that’s all that should be available to the user– any user, until they close it or do something with it. The (hacky-sounding) proposal was to set aria-hidden on the whole page, and the dialog, who’d be outside the page, would be the only default-nonhidden stuff left over.

Graham Armfield says:

Thanks for the interesting an timely post.

Coincidentally, an aria-hidden solution will be added into the WordPress admin screens very shortly. The aim is to provide meaningfully verbose links for screen reader users whilst keeping visible brief links for sighted users where context is supplied by surrounding text. Simply hiding portions of a link or label doesn’t really work grammatically in all languages.

One example of where this occurs is the Publish box when adding or updating a page or post. The links in this box are Edit, Edit, Browse, Edit – obviously not enough for screen reader users.

I’ve blogged more fully about the solution on my own site. Whilst investigating this solution I did some testing on a variety of screen readers – Jaws 14 + NVDA on Windows, VoiceOver on iOS7 iPad and Talkback on Android phone. My results were also heartening, with all the combinations except for Talkback behaving as hoped. On Talkback, both elements of the links were audible – Talkback obviously was not respecting aria-hidden. One other ‘feature’ on VoiceOver was that the visible focus box did not include the aria-hidden text.

For the screen reader portion, WordPress will be initially sticking to the ‘move it off screen’ approach – good support there, but I note your comments about aria-hidden="false" display:none.

I also tested the twin text approach with Dragon Naturally Speaking. Usefully, Dragon users can use either form of the link to action it. This is due (I guess) to the well documented lack of support for aria-hidden in Dragon.

mp says:

One thing I’ve always been curious about is how to balance between using a hidden/clipped element on the screen vs adding an "aria-label" attribute directly on an element. It seems like the use case would often be similar (adding some kind of a description string but hiding it visually) but at least with the label approach, you’re not introducing another element to the DOM and having to worry about hiding it. Any recommendations on when to use either technique?