Limitations of the WAI-ARIA
As a follow up to my previous post, I wanted to learn more about the WAI-ARIA spec, so I went ahead and read it. I won’t claim to be an expert, or to have anything more than a basic understanding of the spec at this point, but I was not impressed with what I saw.
Unfortunately, the spec doesn’t seem particularly forward thinking. There are two main issues I have with the spec: first is that it’s a very limited extension of the DOM and of what we already have on the web; second is that there is no programmatic interface to the accessibility system.
The most obvious downside of assuming that the DOM will be the basic building block of future web applications is that it presumes all web apps will always be structured with DOM trees. But this already isn’t true today. Look at Mozilla’s Bespin editor, which renders text inside a canvas element, or SUN’s Lively Kernel, which implements an entire widget set in SVG. Because there is no underlying DOM structure, these two programs can not be made accessible under the WAI-ARIA spec without substantial hacks.
What about elements that aren’t part of the visual structure at all? For example, in Cappuccino, every application has a CPApplication object. This object contains information that would undoubtedly be useful to the accessibility system, but because it’s an abstract object and isn’t part of the render tree in any way, it will never be visible to WAI-ARIA compliant browsers.
This leads us to the second problem, not having programmatic access to the accessibility system. This spec is designed to target web applications, but it has taken the same document based approach as HTML. Applications are defined by requiring a programming language, which in the case of the browser is usually JavaScript. It seems short sighted to develop a standard for applications that uses a fundamentally different technology than the application does.
Even beyond the fact that elements in your program that don’t exist in the DOM tree can’t become part of the accessibility system, not having a programmatic interface means that you can’t dynamically compute accessibility values. Imagine some user interface element that changes frequently, or perhaps is a composite of several other objects. Under the current WAI-ARIA spec, every change to this user interface element needs to be immediately reflected in the DOM. This means a potentially substantial performance hit that is unnecessary for the vast majority of users, and even for people requiring the accessibility feature if they aren’t focused on that element.
Lack of an actual API also limits the potential uses of ARIA. I can’t, for example, implement my own accessibility tool within the browser. It also causes issues with the event system, and doesn’t add any enhanced functionality for simulating events using accessibility APIs, which could have enabled a lot of advanced automated testing.
These thoughts are a result of my very brief research into ARIA so far, and if anything is technically incorrect, I’d appreciate that feedback. At this point, I’m not sure where to go with ARIA and accessibility. As far as Cappuccino implementation is concerned, there is enough in ARIA that we can significantly enhance the accessibility of Cappuccino, if not 100%. I suspect the performance implications will be minimal for most UI elements (though I am concerned about text fields), but it’s impossible to say until we actually have ARIA implemented.
I’m interested to hear other opinions on ARIA, especially from those who are developing modern web applications. It would be interesting to know if anyone shares my concerns, and if there is any way to actually address some of them within the current framework of ARIA or perhaps another active project I’m not aware of. I don’t claim to have any answers, just a lot of questions, so please share your thoughts.
Ross at 11:51 am | Posted in Technology, Web | Comments (16)
