-1

Hello to everyone.

This is my first question ever, and I know it could be a little tricky, but I'll try.

I'm currently working on an accessible web app, and I wanted to build a "Direct touch area", just like some native apps for iOS, in which the accessibility assistant is disabled, when the user is focused on it. I'm using HTML, Javascript and CSS in frontend developing.

When the accessibility tools (TalkBack for Android, VoiceOver for iOS) are switched on, if you touch the screen with one finger, you cannot interact with the DOM, because you are into an "explore by touch" mode. I'd need to bypass this particular behaviour, but just for a precise area.

I struggled a lot with various ARIA attributes, roles, etc, but didn't find a way yet. For istance, there's an HTML attribute named aria-disabled (true|false), which makes the screen reader simply ignore the area content, so it's not useful in my case. Something similar happens with "aria-hidden" attribute.

Perhaps someone has already encountered this problem and solved it, somehow?

Any help would be veeeery appreciated!

  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking. – Community Sep 14 '21 at 12:21

3 Answers3

0

I don't quite understand what is meant by the question, but maybe "Aria-Disabled" will help?

Aria-Disabled Reference

  • I'm sorry, I was editing the question while you were answering. Yes, I've tried with "Aria-Disabled": it disables the portion of DOM , but still I cannot direct touch the area to make an interaction. ARIA-Hidden, instead, hides the content to the screen reader, but it is still visible. What I'm looking for is to be able to touch that particular
    with one finger just like TalkBack/VoiceOver were switched off. Currently, when I touch the area, I have to put two fingers instead of one. Thank you for you help!
    – moreno gregori Sep 09 '21 at 08:15
0

role="application" is how you get events passed directly to an element without the screen reader capturing the event first. But be very careful with this role. It should be used sparingly.

Note that this role will not turn off VoiceOver for that element. The user still needs to be able to explore the screen. You could implement double-tap-and-hold to go into a mode where the user interacts directly with your object then implement the two-finger 'Z' swipe to escape out of that mode.

slugolicious
  • 15,824
  • 2
  • 29
  • 43
0

first of all bypassing the explore by touch mode won't be possible since it is handled by voiceover or talkback. More important: doing so would make harm since that behaviour would catch the user and he or she won't be able to swipe through the elements. Being a born blind and daily user of such screen readers myself: a blocked swiping through the controls of an app makes me wipe it immediately and leaving me frustrated. Keep in mind that a screen reader user will not be able to touch your input area before he or she found it by swiping. He or she could leaarn the exact position and size but thats more like spinning wheels of fortune.

ARIA 1.1 at https://www.w3.org/TR/wai-aria-practices states in the chapter on mobile and touch support that there is currently no standard on this and there is no ARIA role for that.

You could switch to aria-disabled after your user activates the area after locating it by "explore by touch", but I don't know how the user will get back to the other controls.

Using the application element seems to be the best way, but users have to remember a special key for their screenreaders to leave the application since e.g. NVDA or JAWS will box their reading the apllication until this magic key is pressed. This way I have been trapped in office documents when using office365 many times!

  • Thank you for your precise explaination. Ok, I find it very hard to implement the application role, and I cannot obtain what I was looking for. I omitted to tell you that it is for an accessible game, in which there's an area intended to be accessed via direct touch. That area would be recognized by exploring with screen reader, and the user would know that he could operate as if VO/TalkBack were switched off. Anyway, I really appreciate your kind help and the links you shared to me. I'll let you know if I'll be able to find a workaround! Best regards! – moreno gregori Sep 10 '21 at 17:22
  • Ah, OK, that's an important part. While this works fine on mobile like in the app thumbjam I don't know any similar user experience on a desktop system. Maybe using the API from the screen reader could help, but there is no single one for all readers. – Heiko Folkerts home Sep 12 '21 at 04:59