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 10:15PM

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

On Thu, Oct 12, 2023 at 4:19 PM <EMAIL REMOVED> <
<EMAIL 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
> -----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
> > > >
> > > at http://webaim.org/discussion/archives
> > > > > >