WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test

for

From: tim.harshbarger@deque.com
Date: Oct 12, 2023 11:11AM

So I am curious about something.

My understanding is that if you are using a screen reader, like Voiceover on iOS, there is a screen reader focus rectangle that does appear when you turn the screen reader on. However, there is absolutely no way a site can control how that screen reader focus indicator appears. That is completely determined by the screen reader alone. The keyboard focus indicator (which a site could control) is a separate thing from the screen reader focus indicator. That focus indicator is only going to appear if the keyboard focus moves to that element--which is not how swiping with a screen reader like Voiceover works.

If you want to see the focus indicator on a mobile device, you either need to use a keyboard or an assistive technology that more closely emulates the keyboard experience (like a switch).

Skip links can be invisible when the page loads, but they should become visible as soon as keyboard focus is moved to that link. So again, you would need to test with a keyboard or similar on a mobile device because swiping through the interface with a screen reader won't trigger a keyboard focus event.

At least, the above is my current understanding of how it works.

Thanks,
Tim
-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Jeremy Echols
Sent: Thursday, October 12, 2023 9:34 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test

Got cut off there, was going to add: anything that can receive focus must be visible to sighted users, so this isn't just about skip-to links. I don't know which SC it relates to offhand, and I'm mid-migration on a project so I need to stay focused, but there is a pretty clear rule somewhere that if anything can receive focus, a sighted user needs to be able to see it, even if it seems like it's just for screen readers. Otherwise sighted keyboard-only users (and there are in fact quite a few of us!) have no idea where focus has gone or what will happen when activating a "thing".

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Jeremy Echols
Sent: Thursday, October 12, 2023 07:30
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test

Skip-to links have to be visible when focused. They can be hidden when they're not focused, but once they receive focus, sighted users must see them as well.

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of <EMAIL REMOVED>
Sent: Thursday, October 12, 2023 05:19
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test

Bob,

As a non-visual user and tester, I've observed that "skip to links" are typically not visible to sighted users, although exceptions may exist. These links are intentionally hidden from sighted users but should be readily accessible to screen readers and function as intended.

It's been my experience that many websites include "skip to links," but their functionality can be inconsistent. In some cases, they only activate when you "tab" into them. Therefore, it is imperative that websites containing these links ensure they consistently and reliably perform their intended function.
Hope this helps.
Dino
-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of bobby accessibility
Sent: Thursday, October 12, 2023 3:39 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test

Thanks, Dean for these informative details, appreciate it.

As of now what is happening while navigating a page on Chrome or Safari using Talkback or VoiceOver respectively? Though it's reading the "Skip to main Content" but same not visible on the screen. I couldn't find a reason to not show "Skip to main content" while it's visible on the desktop.

Is there any way to showcase this visible on a mobile screen while navigating through Talkback/VoicOver or is it acceptable?

Thanks



On Wed, Oct 11, 2023 at 3:51 PM <EMAIL REMOVED> < <EMAIL REMOVED> > wrote:

> accessibility for screen reader users on mobile devices is crucial for
> web developers. Here are some guidelines to address your questions:
>
> Visual Focus: The visual focus behavior when navigating a webpage
> using a screen reader on mobile should ideally follow these principles:
>
> Prominent Focus: Interactive elements (buttons, links, form fields,
> etc.) should have a prominent visual focus, such as a clear border,
> shadow, or highlight. This helps users understand where they are on the page.
>
> Non-Interactive Elements: For non-interactive elements, like static
> text, visual focus may not be as prominent, but there should still be
> a subtle indication, like a light border or shading, to differentiate
> the focused element from the rest of the content. This is especially
> important for elements that convey information or meaning.
>
> Keyboard Focus: Ensure that the keyboard focus, as indicated visually,
> corresponds with the screen reader's current position. This means that
> when a screen reader user navigates through elements using swipe
> gestures (left to right or vice versa), the visual focus should follow
> the screen reader's position.
>
> Skip Focus: Avoid skipping visual focus for static text or other elements.
> Consistency in visual focus behavior is essential for an accessible
> experience.
>
> Behavior for Interactive vs. Non-Interactive Elements: The behavior
> should differ for interactive and non-interactive elements.
>
> Interactive Components (e.g., buttons, links, form fields): These
> should have clear and prominent visual focus, with a border or
> highlight to indicate their interactive nature.
>
> Non-Interactive Elements (e.g., static text): Visual focus for these
> elements may be less prominent but should still be present to help
> users understand where they are on the page.
>
> Checking Keyboard Accessibility on Mobile:
>
> Testing with Chrome DevTools: You can use the Chrome DevTools to
> emulate mobile devices and assess keyboard accessibility without an
> external keyboard. Here's how:
>
> Open your webpage in Google Chrome on a desktop computer.
> Open DevTools (F12 or Ctrl+Shift+I).
> Click the "Toggle device toolbar" button or press Ctrl+Shift+M to
> enable device emulation.
> Select a mobile device from the device dropdown menu.
> You can then use the Tab key to navigate through the page and assess
> keyboard accessibility as if you were on a mobile device.
> While this method can help you get a sense of the keyboard
> accessibility, it's essential to remember that the experience may not
> be entirely representative of actual mobile device behavior. For
> comprehensive testing, using a real mobile device with a screen reader is still recommended.
>
> Ensuring a seamless mobile web experience for screen reader users
> involves a combination of proper HTML markup, ARIA roles, and testing
> on real devices. The goal is to provide clear and consistent visual
> focus and a logical navigation order that matches the screen reader's interaction.
>
> Dean Vasile
>
>
> 617-799-1162
>
> On Oct 11, 2023, at 2:10 AM, bobby accessibility <
> <EMAIL REMOVED> > wrote:
>
> Hi Everyone,
>
> Greetings!
>
> While opening a website on Mobile (both platforms Android and iPhone)
> using a screen reader. While swapping left to right what would be the
> correct accessible behaviors as of now it highlights visual focus with
> swapping which does not look appropriate sometimes; it does not show a
> prominent visual border (focus). It makes a big visual box or
> sometimes skips showing visual focus borders for static text.
> Sometimes it reads some interactive element for instance Link but
> showing visual focus just above somewhere on the screen.
>
> 1. Will anybody guide me, on how the visual focus should shown while
> traversing the web page using swapping (left to right or vice versa)?
>
> 2. Does it behave the same for interactive components (buttons, tabs,
> forms, links, etc) and non-interactive elements (static text)?
>
> 3. Is there any other way to check the keyboard accessibility on mobile
> without using an external Bluetooth keyboard? What if we have a
> responsive page and we open this on Chrome change this to mobile view
> and check with the Tab key, will this work?
>
> Thanks,
> Bob
> > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!BIO5f
> M-qOpE6uoWpv7VmIBZxMyOdy-nGgP_hS5gr8VVKqVpXheA7-H5X0vgx-uIb7eoTTqpwTBC
> Ejzu91JShLUrm$ List archives at
> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!
> C5qS4YX3!BIO5fM-qOpE6uoWpv7VmIBZxMyOdy-nGgP_hS5gr8VVKqVpXheA7-H5X0vgx-
> uIb7eoTTqpwTBCEjzu91M8mSog_$ > <EMAIL REMOVED>
> > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!BIO5f
> M-qOpE6uoWpv7VmIBZxMyOdy-nGgP_hS5gr8VVKqVpXheA7-H5X0vgx-uIb7eoTTqpwTBC
> Ejzu91JShLUrm$ List archives at
> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!
> C5qS4YX3!BIO5fM-qOpE6uoWpv7VmIBZxMyOdy-nGgP_hS5gr8VVKqVpXheA7-H5X0vgx-
> uIb7eoTTqpwTBCEjzu91M8mSog_$ > <EMAIL REMOVED>
>