Back in 2005 when I attended my first (and only) face-to-face WCAG Working Group event in Seattle we couldn’t even comprehend where technology would be today; with the array of smartphones, tablets, laptops and smartwatches to come.
Nevertheless, we were very focused on making the second version of the Web Content Accessibility Guidelines ‘technology neutral’; so that it would still be applicable to any of the myriad of future technologies available now.
In some cases, we were successful, but when it comes to mobile accessibility, unfortunately, we were not.
The W3C has released a discussion paper on Mobile and accessibility and how it relates to WCAG2. It is a good read, but it doesn’t provide any implementation criteria. It does list WCAG2 Techniques that apply to mobile, but there is no information on how they apply to mobile, and there aren’t any additional techniques that are specific only to mobile.
[author_more]
The Unbearable Inaccessibility of Slideshows
8 Steps to Creating Accessible Video
The Final Nail in the Icon Fonts Coffin?
[/author_more]
At AccessibilityOz, we started testing mobile-only sites early last year. Initially, we used the BBC Mobile Accessibility Guidelines and merged them with WCAG2 to conduct our testing.
However, we quickly realised that this wasn’t enough; we found a number of things that were not covered in WCAG2 or the BBC Mobile Accessibility Guidelines and considered many of them quite serious accessibility issues.
This resulted in us developing our own unique AccessibilityOz Mobile Testing Methodology which we have since used in our testing of many mobile-only and responsive websites.
There are a number of ways that viewing a website (whether it is optimized for mobile or not) on a mobile device can be problematic. Here I am going to focus on hover inaccessibility.
Firstly we know that on a mobile device there is no continual access to a keyboard (unless someone is using it as an add-on to the device – or using a Blackberry Classic). WCAG2 requires that all content be accessible to the keyboard interface, but it does not require that all content be accessible to a mouse or to a touchscreen user. The definition of a ‘keyboard interface’ in WCAG2 makes this very clear:
WCAG definition of keyboard interface – interface used by software to obtain keystroke input (link1)
Note 1: A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard.
Example: A touchscreen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from an external keyboard or from other applications that provide simulated keyboard output, such as handwriting interpreters or speech-to-text applications with "keyboard emulation" functionality.
Note 2: Operation of the application (or parts of the application) through a keyboard-operated mouse emulator, such as MouseKeys2, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface, not through its keyboard interface.
That means that a UI component that is accessible to an external keyboard on a mobile device can actually comply with WCAG2; even if it is not accessible via a mouse or via touch. WCAG2 was written this way as back in the 2000s it was incomprehensible that a website would be created that was not mouse-accessible. Keyboard accessibility had to be included in WCAG2 though as it was (and still is) quite common to find keyboard-inaccessible websites. And of course, we didn't even think of touch accessibility.
However, instead of a pointing device, users only have the ability to activate components on the mobile. There is no equivalent ability to ‘hover’ over a component, as you can with the mouse or ‘focus’ on a component, as you can with the keyboard. This can cause a range of functionality problems.
Activating Menu Items
Dropdown or flyout menus are very popular at the moment. In many cases, you hover over the top-most menu item to reveal its sub-menu items.
If that main menu item is actually a link to another page, then this hover feature can’t be replicated on a mobile device. Tapping on the main menu item will just take users to that page; there is no way to replicate the mouse hover effect on a mobile (well some mobile devices have the ability to replicate the hover effect but it certainly isn't a well-known technique). This is one reason that in order to activate the flyout menus on the AccessibilityOz website, you need to actually click on the top-most menu item.
For sites that make this top menu item a link, mobile users have only one option: to activate that top menu item. This means they cannot access the dropdown or flyout menu, as touching the top menu item will activate the link – taking the user to that particular page.
We can see this scenario on LinkedIn.
Continue reading %Mobile Accessibility Fails: Do we need a WCAG3?%
Source: SitePoint