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: bobby accessibility
Date: Oct 12, 2023 1:38AM

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