Add the ARIA spec about html5-overview

[dret]

so far the goal is to collect specs that define the HTML5 platform, on a technical level. afaict, ARIA is more about how to use that platform in a good way, right? not that this is not important, but to my mind, it's a different issue.

[sideshowbarker]

Since ARIA is essentially focused most directly on making Web applications (as opposed to just simple Web documents) accessible/usable to AT/screen-reader users, IMHO ARIA fits very appropriately into any overview like this of browser-as-a-programming platform Web-app-building technologies.

[dret]

i see your point, but it's a slippery slope, right? next you end up listing JS frameworks because of course those help with building web apps as well. i am not saying that ARIA is not relevant, but so far i have tried to be as limited in scope as i can get away with ;-)

[sideshowbarker]

i see your point, but it's a slippery slope, right? next you end up listing JS frameworks because of course those help with building web apps as well.

JS frameworks don't have specs and don't have native support built into web browsers. I don't see any slippery slope here at all. Support for ARIA is a standard piece of the Web platform. The ARIA spec defines a key piece of HTML5 platform, on a technical level. Specifically, it essentially defines the API that Web developers need for controlling how the UI for their Web applications is exposed to AT/screen-readers. The Web platform provides no other imperative API for doing that; the declarative mechanism that ARIA provides is the only API which provides that control.

So again I'm not suggesting ARIA be included because it's some technology/spec for “how to use the platform in a good way”; instead I’m suggesting it because it’s a standard core programming mechanism for the platform that’s implemented natively in all browser engines.

[dret]

7b458c0 addresses this issue. i may have some fundamental misunderstanding about WAI-ARIA, though. could you please point me to a specific feature/API in a browser that's there because of WAI-ARIA? i am really just trying to better understand it. thanks!

[sideshowbarker]

could you please point me to a specific feature/API in a browser that's there because of WAI-ARIA

Sure—you can look at a patch I contributed to for implementing support for the main element in WebKit, which also includes related tests.

If you scroll down to the change to the Source/WebCore/accessibility/AccessibilityRenderObject.cpp file, you'll see this:

     if (node && node->hasTagName(articleTag))
         return DocumentArticleRole;

+    if (node && node->hasTagName(mainTag))
+        return LandmarkMainRole;
+
     if (node && node->hasTagName(navTag))
         return LandmarkNavigationRole;

That's code which tells the browser engine to map the main element to the ARIA main landmark, which causes it to then be exposed to platform accessibility APIs as such a landmark. For the associated tests, search that diff for This tests that the HTML5 main element correctly maps to AXLandmarkMain.

So the ARIA spec defines implementable/observable/testing processing requirements for browsers.

If you look through the source of the Source/WebCore/accessibility/AccessibilityRenderObject.cpp file for roleValue() (e.g., the switch (roleValue()) { ... } blocks), you'll find places in the code that get exercised by the presence of ARIA role=foo markup in the HTML document source.

And if you look at it from that perspective, the ARIA spec essentially provides language bindings to control that (C++) browser code. The language that the ARIA spec provides the bindings for happens to be HTML but it's easy to imagine a spec that defined similar bindings for JS (through using WebIDL to define an interface, and by the fact that the WebIDL spec defines WebIDL bindings to JS)—and such a spec would look much more like a natural fit among the other WebIDL/JS API specs in this overview.

The current ARIA spec just doesn’t look superficially like a natural fit due to the fact that unlike most of the other specs included in the overview, it doesn’t happen to use WebIDL to define the API.

[dret]

very helpful, and thanks a lot! would you say it's fair to say that in ARIA the roles are reversed? instead of defining an API which the app code then uses (which is the case in all the HTML5 specs that provide access to specific client capabilities), it tells app authors which APIs to implement so that the client's accessibility features can find and use the right hooks?

[sideshowbarker]

would you say it's fair to say that in ARIA the roles are reversed? instead of defining an API which the app code then uses (which is the case in all the HTML5 specs that provide access to specific client capabilities), it tells app authors which APIs to implement so that the client's accessibility features can find and use the right hooks?

IMHO that wouldn’t be a wholly accurate way to describe ARIA. In particular, while my earlier comments here were limited to how things function in UAs just with respect to use of the role attribute—and the UA mappings of that to platform APIs—ARIA is actually a lot more complicated in that it also allows Web applications to provide transient state information about changes in particular UI controls in a Web app, as well as other properties for such controls beyond just what UI roles they map to.

Because those ARIA states and properties naturally need to change as users interact with a Web app, the only way to manage those ARIA states and properties in practice is through JavaScript.

So the API and programming mechanism for working with ARIA is really not fundamentally very different from that of most all the other specs in this overview. It’s just that instead of manipulating an HTMLFooElement interface through JavaScript to control what's exposed to users, you instead just directly manipulate actual markup attributes through JavaScript.

The effects are basically the same but with the essential difference being that, by design, none of the information you change via ARIA is exposed to users who are just interacting with the Web app through a normal (visual) Web browser but instead, by design, the information only ends up being exposed to users who are interacting with the Web app through separate AT/screen-reader software.

That’s my understanding of it all, at least. I think @stevefaulkner could describe it a lot better than I have.