PWFG group suggested two new methods for DOM Element interface. These methods reflect role and name accessibility concepts, and corresponding methods were named as computedRole and computedLabel.
I have bunch of issues with the approach I wanted to outline here. Just to keep things in one place.
I've been told that primary reason is a testing propose, but having role and name only is not enough to run UAIG tests or any accessibility automation tool since it would require other accessibility properties.
Also they say that it might be used for non accessibility proposes. I realize that semantics, the ARIA adds, can be used by non assistive technologies. In Firefox we have a large number of non AT consumers but we don't have a good idea in most of cases what they are for. So I don't really have the use case, and thus it's hard to say whether accessible role and name only works well for non a11y proposes.
Concerning to assistive technologies I think they also need a much larger API.
Anything useful should require extra accessible properties as I said above. These are accessible description, states, relations, ability to navigate the hierarchy etc. That means sooner or later the Element interface has to be changed to a great extent. Check out AtkObject to get an idea about possible changes.
In beginning of times accessibility interfaces was built on top of DOM and later they were turned into full APIs. Now we are faced to backward process, accessibility APIs are getting back to DOM. I'm not sure if that's a good idea because accessibility tasks are something very specific, and accessibility API might be not suitable for common needs of web apps.
Not every semantically meaningful piece on the screen has a DOM node, for example, list bullets don't necessary have DOM elements associated with them. So Element based accessibility API is too restrictive to fit the requirements of the assistive technologies.
Last but not least is performance issue. In most of browsers the accessibility engine is kept separately and it gets running on demand. If accessibility is merged with the DOM then nothing tells the user this method may trigger heavy accessibility computations and make his app slower. Surely the browsers will learn how to get smarter but the approach will have a perf hit either way.
The idea is to provide a separate accessibility interface. If you like it then it can be done by parts, for example, introduce role and name only for the first round same as the original proposal says. Later you can think of adding all other properties.
This idea was welcomed initially, then later it was rejected as being too complex and accessibility centric. But - and that's most important thing - it doesn't have disadvantages the Element approach has.
I have bunch of issues with the approach I wanted to outline here. Just to keep things in one place.
The purpose
I've been told that primary reason is a testing propose, but having role and name only is not enough to run UAIG tests or any accessibility automation tool since it would require other accessibility properties.
Also they say that it might be used for non accessibility proposes. I realize that semantics, the ARIA adds, can be used by non assistive technologies. In Firefox we have a large number of non AT consumers but we don't have a good idea in most of cases what they are for. So I don't really have the use case, and thus it's hard to say whether accessible role and name only works well for non a11y proposes.
Concerning to assistive technologies I think they also need a much larger API.
Blowing the DOM
Anything useful should require extra accessible properties as I said above. These are accessible description, states, relations, ability to navigate the hierarchy etc. That means sooner or later the Element interface has to be changed to a great extent. Check out AtkObject to get an idea about possible changes.
In beginning of times accessibility interfaces was built on top of DOM and later they were turned into full APIs. Now we are faced to backward process, accessibility APIs are getting back to DOM. I'm not sure if that's a good idea because accessibility tasks are something very specific, and accessibility API might be not suitable for common needs of web apps.
Restrictions
Not every semantically meaningful piece on the screen has a DOM node, for example, list bullets don't necessary have DOM elements associated with them. So Element based accessibility API is too restrictive to fit the requirements of the assistive technologies.
Performance
Last but not least is performance issue. In most of browsers the accessibility engine is kept separately and it gets running on demand. If accessibility is merged with the DOM then nothing tells the user this method may trigger heavy accessibility computations and make his app slower. Surely the browsers will learn how to get smarter but the approach will have a perf hit either way.
What's it going to be then, eh?
The idea is to provide a separate accessibility interface. If you like it then it can be done by parts, for example, introduce role and name only for the first round same as the original proposal says. Later you can think of adding all other properties.
This idea was welcomed initially, then later it was rejected as being too complex and accessibility centric. But - and that's most important thing - it doesn't have disadvantages the Element approach has.
My suspicion is that if you don't want accessibility to be an afterthought for library and page authors then you need a DOM traversal / manipulation API that they can use first instead of last.
ReplyDeleteThis probably refects my a11y ignorance, but how about:
1. promote using aria-attributes for styling (aria-selected, aria-expanded, etc)
2. provide aria-attribute methods on elements:
ariaGet('controls')
ariaSet('activedescendant')
ariaToggle('selected')
ariaCan('expanded')
3. provide role-based DOM traversal methods on elements
ariaFind(role) // first matching descendant
ariaFindAll(role) // all matching descendants
ariaClosest(role) // first match out of element and its ancestors
The methods suggested by PFWG are not about ARIA, they are about accessibility stuff. For example, computedRole on HTML input@type="button" is supposed to return "button".
ReplyDeleteIf I read you correctly then you suggest a bunch of ARIA-oriented methods that are intended to make a web developer life easier. They are probably nice but sort of different from PFWG initiatives.
The `aria` prefix in these names doesn't mean they are restricted to physical aria attributes - the prefix is just for illustration (could be `a11y` or anything).
DeleteBut if the DOM only provides `element.computedRole` then library and page authors need to implement the DOM traversal methods manually as a wrapper around `element.computedRole`. Either that, or no-one will use `computedRole` at all.
I also suspect methods like these will be the easiest way to lure front-end devs into prioritizing accessibility more, since they're probably similar to library APIs they already use.
That makes sense.
DeleteI guess those methods are introduced as the first step. I heard about idea to add a11y CSS selectors, so you can query elements with certain a11y properties from the document. That'd be similar to what your suggest.
However my concern was that a11y props shouldn't reside on DOM Element interface.