If I have construct with many ARIA-stuff inside, do you think that’s too much? It declares the whole box with the expandable content inside als aria-live:polite, gives the “Close”-Button a role:button and the expandable fulltext has a aria-expanded:true/false, if you click on the headline or close button.

Here is an example:

Headline
Close Box
Full text only visible if you click on the h2-element

I didn’t do anything special other than switch the editor when composing blog posts from the WYSIWYG to the HTML editor. WYSIWYG is built on TinyMCE, which is not accessible, the HTML editor is a simple text area. I did this once when writing my first post, and that was it. Nothing fancy.

But it looks like you’re using wordpress here. Is there anything special you’d recommend for her? Any advice or tools I could pass along to her as we get her set up to start blogging?

Please share your thoughts. I’d love to hear from you.

Thanks a bunch,
Cynthia

Thanx Marco for an interesting and informative blog, and thanx to the entire Mozilla community for continuing to actively support accessibility.
– Rich
.

I’m using the following versions of Firefox and Jaws:
Jaws 11.0.756
Firefox 3.6

First of all, I’ve noticed a loss of ability to navigate the lists in the addOn viewer in Firefox (tools -> Add Ons). Firefox 3.6 will not allow navigation of my list of currently loaded extensions or plugins via the
arrow keys.

This behavior occurs using Firefox 3.6 with Jaws 11 and 10, as well as nvda 2009.1.

The other issue is that every so often, seemingly at random, my entire virtual buffer will go away and all I’ll be able to do with Firefox is to tab among focusable items. It seems to happen on page load, and it seems to affect the entire browser: all tabs and windows.

Has anyone seen these two issues? Has anyone seen similar using a different screen reader / operating system?

– Rich

does aria-controls affect the behavior of any of the screen readers? Or can the screen reader user navigate to what it points to?

Theoretically, a screen reader can use the relational info provided by IAccessible2/ATK to provide a navigational means to navigate to that content. However, I am not aware than any screen readr actually uses that info yet. But perhaps this article inspires some creativity among the screen reader developers!

When the item is expanded, should the author make it next in the tab order so that users can navigate to it with a tab key when it’s expanded?

Yes, this is an excellent point, and I’ve updated the article to reflect that. Thanks! So far, I have seen mostly cases where the newly expanded content actually follows the item that expands the new chunk, directly in the source code. In this case, screen readers pick it up. The example I linked to, does this. The list of archive months appears in the source code directly below the “Archive” heading, which makes it easily navigable just by down arrowing.

Finally, I think some screen readers may automatically try to read live changes on a page when a user’s click or key press caused the change. Firefox has an object attribute to tell the AT when this has happened. I’m not sure if anyone has implemented that. If they have, it might be important to put aria-live=”off” on the expanding region.

I am not aware of any Windows screen reader trying to do automatic detection of non-marked up live regions. Orca on GNOME does that to some extent, but it didn’t do it for me in this example. I guess it depends on testing the web page with a screen reader (this should be done anyway), and set this attribute if necessary. I’ll put a note in the article update to that effect.