Bug 12132

Summary: Implement ARIA to enable dynamic web appliations
Product: WebKit Reporter: Aaron Leventhal <aaronlevbugs@gmail.com>
Component: AccessibilityAssignee: Nobody <webkit-unassigned@lists.webkit.org>
Status: RESOLVED FIXED    
Severity: Enhancement CC: alice.barraclough@webkit.org, alp@nuanti.com, ap@webkit.org, ASquared21@gmail.com, bdakin@apple.com, bhawkeslewis@googlemail.com, david.bolter@utoronto.ca, dtrebbien@gmail.com, emacemac7@mac.com, ian@hixie.ch, ismail@donmez.ws, jcraig@apple.com, marcus@better.se, nickshanks@nickshanks.com, patrys@pld-linux.org, rboucher@gmail.com, sam@webkit.org, schwer@austin.rr.com, sekundes@gmail.com, surkov.alexander@gmail.com, syoichi@outlook.com, uws+webkit@xs4all.nl, vtsaran@yahoo.com, walker.willie@gmail.com, webkit@blaut.biz
Priority: P4 Keywords: InRadar, ReviewedForRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
URL: http://www.w3.org/WAI/intro/aria
Bug Depends on: 7138    
Bug Blocks: 13846    

Description From 2007-01-05 13:28:02 PST
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.
------- Comment #1 From 2007-09-02 06:38:22 PST -------
Other major vendors … starting with Opera:

http://my.opera.com/desktopteam/blog/2007/08/31/focus-areas-during-kestrel-development
------- Comment #2 From 2007-09-25 18:40:01 PST -------
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
------- Comment #3 From 2008-02-13 23:09:40 PST -------
Confirmed the bug as an enhancement request.  Personally, I would like to see it implemented.
------- Comment #4 From 2008-03-05 12:54:57 PST -------
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
------- Comment #5 From 2008-03-06 06:40:11 PST -------
How can we move this up the chain so that it gets addressed?
------- Comment #6 From 2008-03-06 11:24:44 PST -------
<rdar://problem/5785134>
------- Comment #7 From 2008-03-19 11:12:05 PST -------
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.
------- Comment #8 From 2008-03-19 17:24:52 PST -------
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.
------- Comment #9 From 2008-12-28 17:48:02 PST -------
*** Bug 23018 has been marked as a duplicate of this bug. ***
------- Comment #10 From 2009-02-24 10:50:53 PST -------
Safari 4 says it has ARIA support: http://www.apple.com/safari/features.html

So wouldn't that means WebKit does too?
------- Comment #11 From 2009-02-24 23:24:42 PST -------
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.
------- Comment #12 From 2009-02-25 13:12:55 PST -------
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.
------- Comment #13 From 2009-03-12 01:22:53 PST -------
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.
------- Comment #14 From 2009-03-12 02:58:47 PST -------
(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.
------- Comment #15 From 2009-03-12 03:21:43 PST -------
"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. 
------- Comment #16 From 2009-03-12 05:31:44 PST -------
(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.
------- Comment #17 From 2013-04-05 11:10:58 PST -------
ARIA support has been in for several years now. Please close.