WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

Number of posts in this thread: 8 (In chronological order)

From: bobby accessibility
Date: Wed, Oct 11 2023 12:10AM
Subject: Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test
No previous message | Next message →

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

From: Dean.Vasile
Date: Wed, Oct 11 2023 5:51AM
Subject: Re: Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test
← Previous message | Next message →

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 ADDRESS 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

From: bobby accessibility
Date: Thu, Oct 12 2023 1:38AM
Subject: Re: Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test
← Previous message | Next message →

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 ADDRESS REMOVED = <
= EMAIL ADDRESS 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 ADDRESS 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
> > > > > > > > >

From: Dean.Vasile
Date: Thu, Oct 12 2023 6:19AM
Subject: Re: Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test
← Previous message | Next message →

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

From: Jeremy Echols
Date: Thu, Oct 12 2023 8:30AM
Subject: Re: Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test
← Previous message | Next message →

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.

From: Jeremy Echols
Date: Thu, Oct 12 2023 8:33AM
Subject: Re: Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test
← Previous message | Next message →

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".

From: tim.harshbarger
Date: Thu, Oct 12 2023 11:11AM
Subject: Re: Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test
← Previous message | Next message →

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

From: bobby accessibility
Date: Thu, Oct 12 2023 10:15PM
Subject: Re: Mobile Accessibility: Visible focus on Mobile with screen reader "On" and Keyboard Test
← Previous message | No next message

Thanks, Dean, Tim, Kevin, and Jeremy for sharing your valuable knowledge.
Appreciate!

On Thu, Oct 12, 2023 at 4:19 PM = EMAIL ADDRESS REMOVED = <
= EMAIL ADDRESS REMOVED = > wrote:

> 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
>