search

WICG / aom

Accessibility Object Model
http://wicg.github.io/aom/
Other
575 stars 59 forks source link

AOM and controlling screen reader #186

Open khsbory opened 2 years ago

khsbory commented 2 years ago

Hello.

I found AOM project about two years ago, and very excited.

My expectations for the AOM project are high because there are many limitations in the current communication method between the existing DOM and Assistive Technology.

Also last year's CSUN, google revealed some AOM such as reflection and aria-description.

I hope that more AOM-related attributes will be applied to real as soon as possible.

By the way, there are attributes such as increment and decrement.

If there is a custom slider, there is no way controlling screen reader's increment and decrement gesture now.

So these attribute also make me very excited. Because through script it can be possible to control increment or decrement gesture. However, I would like to add a few more attributes that control the screen reader along with the attribute of increment and decrement.

First is catch TalkBack focus in WebView.

In native android world, there is a way to catch TalkBack focus such as isAccessibilityFocused property.

So it is possible to stop or play carousel based on TalkBack focus is stayed on carousel view or not.

But in HTML, there is no way to catch TalkBack focus.

So through AOM, if there is a way to catch accessibility focused, it will be used to improve accessibility case by case.

Second is change accessibility hint message string.

In native, there is a way to change accessibility hint such as replaceAccessibilityAction method.

So default TalkBack hint is doubletap to activate, I can change it to such as doubletap to play.

But in HTML, there is no way to change hint message.

So if you add a way to control hint string, it will be very helpful.

How do you think so?

brennanyoung commented 2 years ago

I think the ARIA issues board may be a better place to get feedback on these suggestions. If either of these ideas made it to implementation, ARIA would certainly lead the way, with AOM following up.

But I'll offer some comments:

There are some (quite rational) security concerns about exposing the presence of an AT over the web. Not entirely sure why people don't have the same concerns about native apps, since they too can 'out' AT users over http. Certainly it would be useful to have something like document.activeElement for the virtual cursor, but I don't know how this could be done securely enough to be accepted by privacy-minded AT users and their allies.

The hint message string is an interesting idea, and I have needed something like that from time to time - it would carry a similar burden of responsibility that authors currently take on with aria-roledescription - which means the docs would require plenty of caveats. A poorly-authored hint could break things really badly. This is not intended as an argument against your suggestion, just that such a feature would need to be implemented with great care. Maybe the proposed ariaNotify will handle some of the use cases you have in mind?