Intent to Implement: ARIA Annotation roles

[Aaron Leventhal]

Intent to Implement: ARIA Annotation roles

Contact emails

aleve...@chromium.org

Explainer

This is a subset of ARIA annotations editor’s draft, which explains and specifies a set of semantics for annotations in documents, enabling better accessibility. While most of the draft simply reuses existing markup that is already implemented in browsers, there are 5 new annotation- prefixed roles which require mapping.

Note: the plain “annotation” role needs no implementation, as it as abstract, and the docs- prefixed roles are already implemented as part of the published DPUB-ARIA and DPUB-AAM specs.

Design doc/Spec

I don’t think a design doc is necessary for such a simple role mapping change, and we already have a specification.

Regarding TAG, the ARIA WG is following the correct process and will ensure all necessary reviews are complete before the spec moves to recommendation. However, any changes before recommendation is achieved are likely to be simple to implement and any risk from such changes is minimal, given the highly restricted applicability of these roles. On the other hand, getting these features in before the spec becomes a recommendation will allow experimentation as well as  immediate user accessibility benefit.

Summary

Map the 5 new annotation- prefixed roles to internal Chrome Blink and automation roles (ax_enums.mojom, automation.idl),

Motivation

To support screen reader accessibility of comments, suggestions and other annotations in published documents and online word processing scenarios such as Google Docs, iCloud Pages, and MS Office Online. This is not currently possible without resorting to live region hacks, which are not as reliable as semantics and do not work well with Braille displays. As a result, screen reader users have non-optimal support for collaboration features of online word processors.

Risks

Interoperability and Compatibility

Risk #1 is that Firefox and Safari will not implement.

Risk #2 is that the roles may still change before the spec is complete.

I would argue that these new roles, while very crucial for the accessibility of online word processing, will be used very rarely, so the risk is very small.

Edge: no official support, but positive signals during discussions

Firefox: No signals

Safari: no official support, but positive signals during discussions

Web / Framework developers: support from Google Docs team. A framework would be unlikely to need these roles.

Ergonomics

This will be mapped via IAccessible2 and ATK object attributes. For now, that’s enough. It’s possible that role enumerations will be developed for these roles in the future.

Will not affect performance.

Activation

Will be challenging to implement in the same way that ARIA is generally challenging to get right :)

Useful implementation will require direct collaboration with screen reader developers.

Polyfills will not likely be beneficial, as the number of websites that would likely use this will be rather small and specific.

Debuggability

DevTools will automatically support debugging of the feature through the Accessibility panel, which provides the computed role for all objects.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Support of platforms context really means 2 things:

1) Mapping through the platform accessibility API, and,

2) The development of additional navigation and presentation features within screen readers, roughly following assistive technology use cases that are also described in the spec, and learning from screen reader support for similar features in modern native word processors such as Microsoft Word.

The intention is to immediately map to the ChromeOS Automation API. Technically, some platform APIs IA2 already automatically map any unknown role as a string attribute. Additional platforms will get mappings over time.

Is this feature fully tested by web-platform-tests?

This feature will be fully tested via the usual accessibility testing strategies, including web platform tests.

Link to entry on the feature dashboard

Not sure if this is necessary for such a small change. The number of developers that would be interested in this feature will be tiny, and I’d suggest we should announce support once we are close to having across-the-board screen reader support. Happy to create one.

Requesting approval to ship?

Yes

[Aaron Leventhal]

Feature dashboard item with some better descriptive text (did not realize it would generate the above email for me).

Also, this should have been "Intent to Implement and Ship"

[Aaron Leventhal]

Was missing SHIP in the subject line :)

On Fri, Sep 20, 2019 at 5:05 PM Aaron Leventhal <aleve...@chromium.org> wrote:

[Daniel Bratell]

Hi Aaron!

We discussed this at the weekly API Owner meeting and it seems to me that this is a really good fit for an origin trial, but it's not a good fit for shipping. In particular we want an api to be stable and have wide browser vendor support when it's officially shipped.

On the other hand, this seems like something that can be done really well as an origin trial ( https://www.chromium.org/blink/origin-trials ) as long as you can make at least one site interested in experimenting together with you. Then, once the origin trial has ended, and the spec has stabilized, it should be a solid feature ready to ship.

Best regards

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC2P9WmC1%3DtZNg6gN8UC9GDdM-_hAkjX6U%3DxsfOq%3DDV_pcTEtA%40mail.gmail.com.

[Daniel Bratell]

Friendly ping in case you missed our response.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e0c52b77-7867-4817-a808-83dbcdf4cb50%40gmail.com.

[Aaron Leventhal]

Hi Daniel. Thanks, I got this. I'm working on setting up the origin trial.

What I'm planning to do is to remove the annotation-foo from being mapped to internal roles when the trial is not on.

However, while I am working on this, I don't 100% agree with the decision, because it's picking on some accessibility APIs but not others. There are at least 3 accessibility APIs that will expose unknown roles as a string of how those APIs work. The CORE-AAM spec which governs the exposure of ARIA to accessibility APIs says to send the value of the role attribute, including unknown role names. In fact, some ATs already process the role string as a matter of necessity, as platform APIs use enums for roles, and are generally not updated with every new role added by ARIA WG. So the decision to remove these roles is really mostly going to affect ChomeVox and VoiceOver, but not JAWS, NVDA or Orca. Both Firefox and Chrome expose the entire role string via platform APIs that support it, for this reason.

Relevant text in 6.2 here:

"If a WAI-ARIA property contains an unknown or disallowed value, the user agent SHOULD expose to platform accessibility APIs as follows:

• When exposing as an object attribute, expose the unknown value — do not vet it against possible values."

Also here:

6. User agents MUST expose the WAI-ARIA role string if the API supports a mechanism to do so. This allows assistive technologies to do their own additional processing of roles.

• MSAA: not supported. User agents SHOULD NOT expose a custom role in MSAA's accRole property.
• IAccessible2: expose as an object attribute pair (xml-roles:"string")
• UIA: expose as AriaRole property. The AriaRole property can also support secondary roles using a space as a separator.
• ATK/AT-SPI: expose as an object attribute pair (xml-roles:"string")

Aaron

[Aaron Leventhal]

CL to put it behind a feature flag here:

https://chromium-review.googlesource.com/c/chromium/src/+/1841616

[Daniel Bratell]

Yes, I can see how that can seem inconsistent if there are other APIs shipping without wide vendor support and before they are robustly in a specification/standard, but I think that is just another sign that accessibility APIs are not given the attention they deserve. Since relatively few think about them or use them, taking shortcuts become acceptable, or leaving things under-specified as in the spec text you included.

Are you in contact with your peers at WebKit and Mozilla? Maybe you can agree on some way to move faster in unison?

/Daniel

[Aaron Leventhal]

Yes, I'm in contact. Most accessibility teams are under-resourced. That's the reality everyone struggles with.

What would you like to see in the spec text for ARIA annotations? It is a draft spec.

Keep in mind we purposely don't try to specify anything about the presentation, as that would be stepping on the assistive technology's role.

[Daniel Bratell]

I don't know the topic well enough to have specific comments, but the shipping process exists to reduce the risk for breaking the web. That can happen by different implementations diverging (for instance if some vendor elects to not ship a feature), or by a single implementation changing over time (because the first implementation was flawed).

This change is exposed to both of those risks, and it seemed like it would be possible to avoid at least part of the problems with an origin trial. Some features are hard to test in origin trials but this seemed to be a good fit and then we would be able to ship something that is proven to work. That would also help spec writing and in effect, make it easier for other vendors to implement the same thing at about the same time.

That is at least the theory behind origin trials. :)

I'm not sure about the risks for accessibility APIs in particular but I assume breaking screen readers is the main risk when doing changes?

/Daniel

[Aaron Leventhal]

It's fine, I'm glad to get the experience implementing an origin trial so that our team knows what's involved. I agree it's a really good system.

Breaking screen readers is possible in some cases. 

In this particular case, it's not a big concern for a few reasons.

- For ChromeVox everything is all built together -- if we make a change to the internal mapping, we change ChromeVox at the same time.

- Other screen readers rely on platform API mappings. They either access the role attribute directly, or there is a specific enums/strings assigned for each role in CORE-AAM. There aren't any such new platform API mappings at this point for ARIA annotations, and it's too early to try to get them assigned. JAWS uses the direct role attribute access. Breaking them is possible, but then we'd be back to the current state of nothing working anyway ... aka nothing really lost.

- There are only one or two initial users of this markup, the main one is Google Docs. Once it's working with Docs and a variety of screen readers, it will be a lot to get adoption by other browsers and web apps. I don't expect any more than a handful of web apps to be interested in the next couple of years, but they are important web apps that people need for their jobs. 

- The easier we make it to get feedback and to play with the new markup, the faster we can make improvements to it.

An example of where I see an origin trial being really helpful for accessibility might be if we implement a big new change to how accessibility APIs work, or implement some markup that is expected to be used by a lot of websites.

But again, I'm ok with this so we probably don't need to go back and forth. I get that origin trials are very cool.

Aaron