Storing html attributes in Chromium accessibility tree

[Dominic Mazzoni]

Hi Chromium-accessibility team,

Julie raised an interesting issue with this code review: https://codereview.chromium.org/1162263008/

Julie noticed that some ARIA attributes are never really interpreted by Chrome, they're just passed through as-is to assistive technology. The question is, why should we do extra work to parse them and have attributes for them, when we could just get them directly from the list of all html attributes on each node?

A couple of examples from this change are aria-grabbed, aria-dropeffect, and the "type" attribute in an <input> element, but there are potentially a lot more of these.

The current code is a mix of both approaches, but it'd probably better if we picked one approach and tried to be consistent. Here are the two alternatives:

1. Make everything an accessibility attribute and deprecate the use of HTML attributes in the accessibility tree.

2. Get rid of accessibility attributes we don't actually parse or interpret and have the platform-specific code get these attributes directly from the HTML attributes.

Here are some thoughts on these.

Arguments for #1:

* Right now we're storing all of the HTML of every node in the accessibility tree, but probably 90% of that is ignored by screen readers. We could save memory by stripping out attributes that are never used.

* The automation API should have full access to ARIA but we want it to be a "clean" API where it's clear exactly what attributes it has.

* We could add an optional flag to chrome://accessibility to add back the HTML attributes for developer debugging - i.e. AViewer and NVDA have options to dump the HTML of each node.

* If an attribute is initially just passed through but later becomes something we interpret or map to a new native API on one platform, it's more flexible.

Arguments for #2:

* Firefox just maps all aria- attributes directly to the IAccessible2 attributes, which is pretty simple and makes support for new ARIA attributes automatic. For example, adding aria-foo to an element automatically exposes it in Firefox.

* It requires too much code to implement support for something like aria-grabbed now (or aria-modal, something we should add soon) when all we're going to do is pass it through as-is on many platforms. We could simplify our code.

There are other approaches we could consider, like keeping a single master list somewhere of ARIA attributes to pass through. That could be a compromise between #1 and #2, so adding support for a new trivial ARIA attribute could be just adding one line of code.

To help answer the question, it might be worth looking into how much memory we're wasting storing the html_attributes in the AX tree now. Perhaps someone could do a before/after measurement by opening a large page with lots of elements and attributes but relatively little use of ARIA.

Thoughts?

[Nektarios Paisios]

Does ISimpleDom require access to the HTML node? If it does we can't get
rid of all the HTML attributes. However, I don't think that having them
on chrome:accessibility is so important. Chrome has so many other ways
to view the HTML that are much superior. We should simply link each
accessibility object to the HTML node in the HTML Inspector in Developer
Tools, the same way that the right-click menu in Chrome does from any
location on an HTML page. How do the Developer Tools get the HTML
information? I don't think they copy all the HTML attributes from Blink
and store them on the Chromium side? In any case, chrome:accessibility
should go away after we upgrade the Developer Tools with ax tree info.
In my little experience when implementing new aria attributes, it was
never enough to simply pass through the HTML attribute in the native
APIs. There were always corner cases on different platforms. I don't
think that what Firefox does is healthy from a code hygiene standpoint.
It would encourage exposing attributes without much thought.
I think we should go with a hybrid approach: Get rid of HTML attributes
but allow exposing new "aria-..." attributes in a simpler way via a
master list.
This will get rid of some of the repetitive plumbing code between
Chromium and Blink, e.g., no need to create a new accessibility-specific
public API in Blink that simply returns an HTML attribute. But at the
platform API level, the attributes should still be implemented by hand
to avoid carelessness.
Nektarios.

[Dominic Mazzoni]

ISimpleDOM has an interface to iterate over all of the attributes, yes - but that doesn't mean we need to implement it. If we decide to remove attributes from our internal tree, I'd support adding a develoepr switch or checkbox in chrome://accessibility to add back all html attributes only for developer debugging purposes.

As for the developer tools, they do copy the whole DOM tree via an IPC.

Right now there's no plan to deprecate chrome://accessibility because the developer tools shows you a cross-platform view of accessibility, from the perspective of one frame, whereas chrome://accessibility shows you the platform-specific tree, composed across all frames.

That said, the vote for a hybrid approach sounds good.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-accessib...@chromium.org.