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: Dean.Vasile@outlook.com
Date: Oct 12, 2023 6:19AM

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
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >