APA & ARIA at TPAC Tuesday/Wednesday

Tuesday 26 October at 1600 UTC; and/or
Wednesday 27 October at 000 (Midnight) UTC ...

Sign up here: https://eur.cvent.me/yGw02

APA and ARIA will meet jointly to discuss the following topics (among others
participants may raise).

The topics below proposed for this 2-hour session first reached expression
during early planning for the upcoming "Shape the Future" E.U.  sponsored and
W3C/WAI hosted Symposium:

https://www.w3.org/WAI/about/projects/wai-coop/symposium1/

We have both known "near-term," as well as more "in the future" challenges
identified for consideration. In approximate chronological order hese include:

1. The APA's Task Force developing a Spoken Presentation specification is
attempting to make TTS-based pronunciation correct and predictable for spans
of content identified by authors across all operating environments. However, a
gap has emerged between what browsers appear to require vis a vis what
assistive technologies require. This gap cannot be bridged by existing AAPIs. 

AT
https://github.com/w3c/pronunciation/issues?q=is%3Aopen+is%3Aissue+label%3AAT

Browsers
https://github.com/w3c/pronunciation/issues?q=is%3Aopen+is%3Aissue+label%3ABrowsers

We have a specific request to devise some way for screen readers (and other
AT) to consume the pronunciation hinting contemplated in this specification
wholesale, e.g. with some kind of added aapi functionality. Asking screen
readers to parse html is a nonstarter, so success of the spec's goals is very
much tied to solving this problem.

2. While the Module 1 specification about to reach CR in the APA
Personalization Task Force arguably does not raise significant design problems
for browsers or AT, it will complicate the authoring environment--as will the
above noted Pronunciation specification. Consult last week's TPAC
Personalization Breakout for more:

https://www.w3.org/2021/10/18-personalization-minutes.html

3. The accessibility of data, especially large and frequently updated data
sources typically visualized in interactive graphs or charts was raised as a
challenge in an ARIA teleconference this past summer.  The challenges apply
to current accessibility APIs, not only in this context but also in connection
with Web applications with complex interfaces (e.g., containing large numbers
of DOM nodes). It was argued that current accessibility APIs
+are rapidly reaching their limits for performance and extensibility reasons.

4. The accessibility of immersive environments, as discussed this summer at the
XR Access Symposium, where the applicability of the Accessibility Object
Model, and, more generally, the design of architectures capable of
+supporting assistive technologies in such applications were challenges noted. The
need for extensibility (beyond GUI widgets to the various objects supporting
direct manipulation in an XR environment) was clear, as was the
+potential problem of handling a large number of objects (including component
objects) maintained by an XR user interface. The difficulty of synthesizing
information for nonvisual users that is informative, but not
+overwhelming, given the complexity of XR environments has also been
acknowledged in the literature.

5. The Automotive WG has continued asking us for guidance on
building a11y into their specs.As they understand they need to support not
only vehicle owners, but also by the day and by the week renters, and also
taxi hires, they know they need to communicate and facilitate pwds. That
+means talking to any aapi the user may bring into the vehicle. 


-- 

Janina Sajka
https://linkedin.com/in/jsajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Co-Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa

Received on Monday, 25 October 2021 20:26:07 UTC