alice
commented
8 years ago (From Dominic)
While we're not done with the use cases, there seems to be large consensus that one of the most important use cases is to support the ability to change accessibility attributes of DOM elements programmatically, and to create virtual accessibility elements.
Let's dive right into the technical details of what that might look like.
Alex has proposed adding a new property to the Node interface:
partial interface Node {
readonly attribute AccessibleElement? accessibleElement;
};Ignoring for the moment what we call it (Alex called it a11ement, but I'm using accessibleElement just to be more clear for now), I think the general idea that every DOM node should have a single new property to give you access to the node's accessible element is good. I think it's definitely preferable to the idea that every Node would have separate properties reflecting all of the ARIA attributes like role, etc.
If there are any objections or alternative ideas (aside from the name of the property or the name of the class), stop here and speak up.
Otherwise, let's dive into what AccessibleElement should contain.
For the moment I do not want to worry about all of the possible properties an AccessibleElement must have. For now let's stick with role and name since those are pretty well-defined and hopefully not too controversial. So we may have something like this:
interface AccessibleElement {
attribute DOMString role;
attribute DOMString name;
};So if you wanted to log the role of the html body element, you could write:
console.log(document.body.accessibleElement.role);Again, if there are major objections so far, stop here and let me know!
But if this all seems reasonable so far, let's talk about how we'd change the role of an element, because there are several ways that could be done.
How to change the role of an existing DOM element
(1) Alex's idea is that an AccessibleElement would have a "source":
interface AccessibleElement {
attribute DOMString role;
attribute DOMString name;
attribute AccessibleSource? source;
};The idea is that AccessibleElement is not mutable, but AccessibleSource is an object that would let you specify accessibility attributes you want to modify. So you could do something like this:
var customButton = document.querySelector('#customButton');
var axCustomButton = element.accessibleElement;
console.log(axCustomButton.role); // prints "div"
axCustomButton.source = {'role': 'button'};
console.log(axCustomButton.role); // prints "button"One cool thing about this approach is that you could define the role using a getter instead, which could then compute the role dynamically if you want:
axCustomButton.source = {get role() { return 'button' }}Presumably you could also create a prototype and then set the accessible source for a whole bunch of elements to an instance of that:
for (var i = 0; i < listItems.length; i++)
listItems[i].accessibleElement.source = new AccessibleListItem(i);(2) Another idea to throw out would be to just allow accessibleElement itself to be mutable and replaceable directly. So to change the custom button's role, you'd just do this:
var customButton = document.querySelector('#customButton');
var axCustomButton = element.accessibleElement;
console.log(axCustomButton.role); // prints "div"
axCustomButton.role = 'button';
console.log(axCustomButton.role); // prints "button"You could replace role with a getter using this syntax:
Object.defineProperty(axCustomButton, 'role', {
get: function() {
return 'button';
}
});Finally if you wanted to replace all of the functionality of accessibleElement you could do that:
customButton.accessibleElement = {
get role() { return 'button' },
get name() { return 'name' },
}With this second proposal, it seems like it'd be harder to imagine providing an "incomplete" AccessibleElement - for example you'd break the hierarchy if you didn't implement something like parent / children. With Alex's idea, above, AccessibleElement could always implement more critical things like the tree structure, and AccessibleSource would override things you want to, while anything you choose not to override would be inferred from the underlying Node (if any) or from explicit tree structures.
I think Alex's idea (1) is a little harder to get your head around at first, but it's potentially more foolproof, it's more compatible with the idea of explicitly constructing virtual trees. My alternative idea (2) is simpler to understand but potentially requires the author to be more careful when implementing virtual accessible nodes.
Thoughts? Alternative ideas?
minorninth
cookiecrook
(Just copying stuff over from email as I find it easier to read in this format)