Intent to Experiment: Support ARIA Annotation roles in Automation API, ChromeVox screen reader
49 views
Skip to first unread message
Aaron Leventhal
Oct 22, 2019, 2:57:11 PM10/22/19
to blin...@chromium.org
aleve...@chromium.org
The draft spec does a good job of explaining:
https://w3c.github.io/annotation-aria/
Specification: https://w3c.github.io/annotation-aria
-
Accessibility team doesn't think this requires TAG review separately. Stuff going from ARIA Editor's draft to final will likely go through it anyway.
Support the new markup in the ARIA annotations editor’s draft (5 new roles): annotation-attribution, annotation-commentary, annotation-presence, annotation-revision, annotation-suggestion.
The new roles will be reflected in the ChromeOS Automation API, and a UX will be developed for them in ChromeVox.
The rest of the draft spec does not require additional core implementation as it simply reuses existing markup that is already implemented in browsers.
None
Start: m79, end: m85
None
DevTools will automatically support debugging of the feature through the Accessibility panel, which provides the computed role for all objects.
No
Fully meaningful support goes beyond API mappings to new screen reader navigation commands.
The goal is to roll out support in each major screen reader (usually 1 per platform, but Windows has several), either by directly coding the changes ourselves, or by requesting changes from the screen reader vendor.
No
This feature will be fully tested via the usual accessibility testing strategies, including web platform tests.
https://chromestatus.com/feature/4666935918723072
This intent message was generated by Chrome Platform Status.
Aaron Leventhal
Oct 22, 2019, 4:17:54 PM10/22/19
to blin...@chromium.org
Now that we're into 80, let's just start the origin trial in 80 and not bother with 79.
Aaron
Yoav Weiss
Oct 23, 2019, 8:15:45 PM10/23/19
to Aaron Leventhal, blink-dev
On Tue, Oct 22, 2019 at 4:57 PM Aaron Leventhal <aleve...@chromium.org> wrote:
aleve...@chromium.org The draft spec does a good job of explaining: https://w3c.github.io/annotation-aria/ Specification: https://w3c.github.io/annotation-aria - Accessibility team doesn't think this requires TAG review separately. Stuff going from ARIA Editor's draft to final will likely go through it anyway. Support the new markup in the ARIA annotations editor’s draft (5 new roles): annotation-attribution, annotation-commentary, annotation-presence, annotation-revision, annotation-suggestion. The new roles will be reflected in the ChromeOS Automation API, and a UX will be developed for them in ChromeVox. The rest of the draft spec does not require additional core implementation as it simply reuses existing markup that is already implemented in browsers. None
What are we expecting to learn from the experiment? Are there any partners ligned up to experiment?
Start: m79, end: m85
Why is such a long experimentation period needed?
None DevTools will automatically support debugging of the feature through the Accessibility panel, which provides the computed role for all objects. No Fully meaningful support goes beyond API mappings to new screen reader navigation commands. The goal is to roll out support in each major screen reader (usually 1 per platform, but Windows has several), either by directly coding the changes ourselves, or by requesting changes from the screen reader vendor. No This feature will be fully tested via the usual accessibility testing strategies, including web platform tests. https://chromestatus.com/feature/4666935918723072This intent message was generated by Chrome Platform Status.
--
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/CAC2P9WkYyckmau87XEt4Y9p4V9ec3Sw0yE-VJDJV%2B0U6xzo_hQ%40mail.gmail.com.
Aaron Leventhal
Oct 24, 2019, 12:04:32 AM10/24/19
to Yoav Weiss, blink-dev
Experimenting with accessibility APIs is tricky. There are 2 extra layer of technology that we have to deal with:
- Platform accessibility APIs, which are different for each OS
- Assistive technologies, which are different for each OS
We also have the ARIA WG. There are lots of stakeholders who can and will ask for tweaks or larger changes. It can take a while to get everything in the perfect place.
I need Google Docs to implement this in order to get any real meaningful feedback from Assistive Technology vendors and users. They have agreed to do it, but I don't know exactly when they will. I gave us enough time so that we won't be sorry we ran out of time before getting everyone on the same page.
Aaron
Yoav Weiss
Oct 24, 2019, 8:15:39 AM10/24/19
to Aaron Leventhal, blink-dev
On Thu, Oct 24, 2019 at 2:04 AM Aaron Leventhal <aleve...@chromium.org> wrote:
Experimenting with accessibility APIs is tricky. There are 2 extra layer of technology that we have to deal with:- Platform accessibility APIs, which are different for each OS- Assistive technologies, which are different for each OSWe also have the ARIA WG. There are lots of stakeholders who can and will ask for tweaks or larger changes. It can take a while to get everything in the perfect place.I need Google Docs to implement this in order to get any real meaningful feedback from Assistive Technology vendors and users. They have agreed to do it, but I don't know exactly when they will. I gave us enough time so that we won't be sorry we ran out of time before getting everyone on the same page.
OK, so it sounds like Docs is the experimentation partner and the goal of the experiment is feedback from AT vendors and users.
I think it would make sense to get a timeframe from them and only then start the experiment. We strongly discourage experiments from running too long (i.e. over 6 milestones), so would be good to "start the clock" only when it's actually useful.
Aaron Leventhal
Oct 24, 2019, 9:33:53 AM10/24/19
to Yoav Weiss, blink-dev
Ok. For now, we could just use the feature flag, and then start the origin trial / experiment once we need users to actually be able to play with it. That would work .
Aaron
Reply all
Reply to author
Forward
0 new messages