Intent to Ship: Support ARIA Annotations from ARIA 1.3 draft

[Aaron Leventhal]

Contact emails aleve...@chromium.org Explainer https://github.com/aleventhal/aria-annotations Spec https://w3c.github.io/annotation-aria TAG review 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. Summary Support the new markup in the ARIA annotations editor’s draft (3 new roles, 1 new property): suggestion, mark, comment, aria-description This feature enables new semantics: - Comments - Text highlights with semantic meaning, just like <mark> - Suggestions for changes, e.g. by another author in a Google Doc - Additional related information to be semantically tied to an element, allowing descriptions, definitions, footnotes and comments to be tied to another element. Link to “Intent to Prototype” blink-dev discussion https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/intent$20annotation%7Csort:date/blink-dev/wdWtyA1gyvI/A_qiiT07DAAJ Risks

Interoperability and Compatibility These new roles, while very crucial for the accessibility of online word processing, will be used very rarely, so the risk is very small. The new markup has already been through thorough discussion and review by the ARIA WG. Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1608975) Mozilla team has reviewed the markup, and has triaged and accepted the enhancement at bugzilla.mozilla.org. Edge: Public support (https://github.com/w3c/core-aam/pull/63) LGTM for pull request on CORE-AAM Safari: No public signals Web developers: No signals Ergonomics Mapped to APIs (IAccessible2 and ATK) via roles, description property and object attributes. No significant impact on performance, memory, quality. Activation Same as risks for activating any new ARIA markup. ARIA is generally challenging for authors to use and get right, requiring testing with a variety of assistive technologies in order to polish the implementation. It's very specialized markup that requires good testing and coordination among implementors. Security No security risks.

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)? Yes 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. Orca and JAWS have already begun implementing support using the Chrome flag listed in the explainer. Is this feature fully tested by web-platform-tests? Yes This feature is fully tested via the usual accessibility testing strategies, including web platform tests. Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1006767 Demo links https://codepen.io/aleventhal/full/VxByVK/ Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/4666935918723072

This intent message was generated by Chrome Platform Status.

[masatak...@gmail.com]

On Saturday, February 15, 2020 at 4:25:04 AM UTC+9, Aaron Leventhal wrote:

Contact emails aleve...@chromium.org Explainer https://github.com/aleventhal/aria-annotations Spec https://w3c.github.io/annotation-aria TAG review 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. Summary Support the new markup in the ARIA annotations editor’s draft (3 new roles, 1 new property): suggestion, mark, comment, aria-description This feature enables new semantics: - Comments - Text highlights with semantic meaning, just like <mark> - Suggestions for changes, e.g. by another author in a Google Doc - Additional related information to be semantically tied to an element, allowing descriptions, definitions, footnotes and comments to be tied to another element. Link to “Intent to Prototype” blink-dev discussion https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/intent$20annotation%7Csort:date/blink-dev/wdWtyA1gyvI/A_qiiT07DAAJ Risks

Interoperability and Compatibility These new roles, while very crucial for the accessibility of online word processing, will be used very rarely, so the risk is very small. The new markup has already been through thorough discussion and review by the ARIA WG. Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1608975) Mozilla team has reviewed the markup, and has triaged and accepted the enhancement at bugzilla.mozilla.org.

You might want to refer to https://github.com/mozilla/standards-positions/issues/253 instead. According to Mozilla's guide on bug handling [1] marking as enhancement without priority is just counted as a feature request.

[1] https://firefox-bug-handling.mozilla.org/triage-bugzilla#this-bug-is-a-feature-request

[Yoav Weiss]

On Sun, Feb 16, 2020 at 10:43 AM <masatak...@gmail.com> wrote:

On Saturday, February 15, 2020 at 4:25:04 AM UTC+9, Aaron Leventhal wrote:

Contact emails aleve...@chromium.org Explainer https://github.com/aleventhal/aria-annotations Spec https://w3c.github.io/annotation-aria TAG review 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. Summary Support the new markup in the ARIA annotations editor’s draft (3 new roles, 1 new property): suggestion, mark, comment, aria-description This feature enables new semantics: - Comments - Text highlights with semantic meaning, just like <mark> - Suggestions for changes, e.g. by another author in a Google Doc - Additional related information to be semantically tied to an element, allowing descriptions, definitions, footnotes and comments to be tied to another element. Link to “Intent to Prototype” blink-dev discussion https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/intent$20annotation%7Csort:date/blink-dev/wdWtyA1gyvI/A_qiiT07DAAJ Risks

Interoperability and Compatibility These new roles, while very crucial for the accessibility of online word processing, will be used very rarely, so the risk is very small. The new markup has already been through thorough discussion and review by the ARIA WG. Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1608975) Mozilla team has reviewed the markup, and has triaged and accepted the enhancement at bugzilla.mozilla.org.

You might want to refer to https://github.com/mozilla/standards-positions/issues/253 instead. According to Mozilla's guide on bug handling [1] marking as enhancement without priority is just counted as a feature request.

Initial signals look encouraging. Let's give them a bit more time to reach a conclusion.

 

[1] https://firefox-bug-handling.mozilla.org/triage-bugzilla#this-bug-is-a-feature-request

 

Edge: Public support (https://github.com/w3c/core-aam/pull/63) LGTM for pull request on CORE-AAM Safari: No public signals Web developers: No signals Ergonomics Mapped to APIs (IAccessible2 and ATK) via roles, description property and object attributes. No significant impact on performance, memory, quality. Activation Same as risks for activating any new ARIA markup. ARIA is generally challenging for authors to use and get right, requiring testing with a variety of assistive technologies in order to polish the implementation. It's very specialized markup that requires good testing and coordination among implementors. Security No security risks.

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)? Yes 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. Orca and JAWS have already begun implementing support using the Chrome flag listed in the explainer. Is this feature fully tested by web-platform-tests? Yes This feature is fully tested via the usual accessibility testing strategies, including web platform tests. Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1006767 Demo links https://codepen.io/aleventhal/full/VxByVK/ Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/4666935918723072

This 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/82b8573c-99b4-427a-9e91-b47da97a2874%40chromium.org.

[Daniel Bratell]

LGTM1.

I think Mozilla's support is good enough, and while more is always better I don't think we should wait any longer.

/Daniel

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

[Chris Harrelson]

LGTM2

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/50a6969c-7b35-4c70-8c79-84adf197b4c3%40chromium.org.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_VAwK%2B3HwfBeDr9Tb6MSty8PnR8Vy6Bd4YCZ%2Bj-BgO%3Dw%40mail.gmail.com.