Implement ARIA to enable dynamic web appliations

• Component: Accessibility
• Status: RESOLVED FIXED

[Aaron Leventhal]

The Protocols and Formats Working Group has been updateding Public Working 
Drafts of the Accessible Rich Internet Applications (WAI-ARIA) suite. The Roadmap describes accessibility of interactive Web content using rich technologies such as AJAX and DHTML. WAI-ARIA Roles provides a dictionary of kinds of page features that are important to user interaction, and WAI-ARIA States and Properties enables XML languages to express critical information about how these page features relate to one another. These are introduced in the WAI-ARIA Suite Overview:
    http://www.w3.org/WAI/intro/aria

Basically, in combination with the tabindex fixes recommended in bug 7138, this allows for rich web applications to be developed with accessible tree views, menubars, tab panels, grids, sliders and other advanced widgets.
This has been implemented in Mozilla since Firefox 1.5 See http://developer.mozilla.org/en/docs/Accessible_DHTML

Other major vendors will be supporting this technology.

[Benjamin Hawkes-Lewis]

Other major vendors … starting with Opera:

http://my.opera.com/desktopteam/blog/2007/08/31/focus-areas-during-kestrel-development

[Aaron Leventhal]

ARIA can now be used without namespaces in text/html.
For more info see the FAQ: http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ

[Robert Blaut]

Confirmed the bug as an enhancement request.  Personally, I would like to see it implemented.

[Aaron Leventhal]

Not just Mozilla and Opera.

IE 8 beta 1 now has ARIA support: http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=ie8whitepapers&ReleaseId=564

[David Bolter]

How can we move this up the chain so that it gets addressed?

[Mark Rowe (bdash)]

<rdar://problem/5785134>

[Dave Hyatt]

This work is dependent on refactoring our accessibility code to be cross-platform.  I don't think we should bake in more Mac-specific code to do ARIA before that refactoring is complete.  Our first goal should be to get the accessibility code from Objective-C to C++ so that GTK and Windows can get unblocked on adding their support (e.g., MSAA on Windows).

Once we've done that we should be able to add an ARIA implementation with mostly cross-platform code.

This would be an excellent Google Summer of Code project.

[Aaron Leventhal]

It's great this is getting attention. However, a Summer of Code project won't get you that far. Roughly 20% of the mappings to Universal Access and other APIs won't be straightforward.

This implementors guide helps provide some idea of what's involved:
http://developer.mozilla.org/en/docs/ARIA_User_Agent_Implementors_Guide
We don't have Universal Access mappings documented yet. Opera is partly down the road of implementing ARIA via Universal Access and Mozilla is thinkingg about it.
I hope we can work to define common UA mappings.

[Mark Rowe (bdash)]

*** Bug 23018 has been marked as a duplicate of this bug. ***

[Evan]

Safari 4 says it has ARIA support: http://www.apple.com/safari/features.html

So wouldn't that means WebKit does too?

[Alexey Proskuryakov]

Looks like there are some loose ends still. Namely, 'aria-required' attribute is not implemented, and some ARIA roles are not implemented, too. I don't know how much these loose ends are important in practice.

[Victor Tsaran]

Unfortunately, the latest beta of Safari4 supports a very limited set of ARIA roles and states. Such trivial roles as "alert" are not supported yet. Also, ARIA landmarks and live regions are not exposed by the engine yet.
So, this bug is far from being addressed.

[boucher]

Also worth noting that the aria role "presentational" and the aria state "aria-hidden" do not appear to be implemented or working. This makes hiding things from the screen reader impossible.

[Aaron Leventhal]

(In reply to comment #13)
> Also worth noting that the aria role "presentational" and the aria state
> "aria-hidden" do not appear to be implemented or working. This makes hiding
> things from the screen reader impossible.

Try role="presentation".

Also, do things not get hidden from the screen reader when display: none or visibility: hidden are used? If you look at the 4th question under http://www.w3.org/WAI/PF/aria-implementation/#error-handling_states-properties, it shows that aria-hidden is advisory, allowing DOM-based ATs to retrieve changes to whether something is hidden. However, it is preferred that ATs can use another API to determine visibility and changes to visibility. IOW, using display: none or visibility: hidden is the right way to hide something from a screen reader.

[boucher]

"presentational" was just a type in my comment, role="presentation" also doesn't work. 

Setting visibility to hidden or display to none isn't always an option. As I'm sure you are aware, doing either can change the behavior of many things in different browsers. Since the point of ARIA is to give application authors more control over what the intended purpose of an element is, its pretty important to allow the developer to hide something from screen readers. 

[Aaron Leventhal]

(In reply to comment #15)
> "presentational" was just a type in my comment, role="presentation" also
> doesn't work. 
> 
> Setting visibility to hidden or display to none isn't always an option. As I'm
> sure you are aware, doing either can change the behavior of many things in
> different browsers. Since the point of ARIA is to give application authors more
> control over what the intended purpose of an element is, its pretty important
> to allow the developer to hide something from screen readers. 

Since this is becoming a discussion unto itself, I suggest filing a separate bug and attaching a testcase with recommended behavior. We should take the specific issue and deal with it there. Feel free to CC me. There might not yet be a way in ARIA to do what you are asking.

[James Craig]

ARIA support has been in for several years now. Please close.