by Helen Burge
Responsive Web Design (or RWD) is not a recent concept. It was introduced in 2001. Around the same time, ideas of accessibility and testing on mobile devices were emerging. As the world becomes more accustomed to mobile devices the need to serve a wide audience with mobile versions of accessibility features came light. It’s more important than ever to understand and implement responsive web design in relationship to mobile accessibility.
Identifying Differences Between Static & Responsive Sites On A Mobile Device
Most of you have probably noticed, when you are looking at a website, there is a difference when you switch to your smartphone to view it. If a site isn’t using a responsive design, it’s likely you will have to adjust your view while using a smartphone.
Size Matters For Accessibility
Responsive design websites are ones that respond to how they are displayed according to the resolution and the screen size. These sites won’t redirect to a new mobile URL, but will have a different look and feel as the browser changes its size. You can imitate the change in views by resizing your browser on a desktop.
Check Compatibility Across Devices
When we relate responsive web design to web accessibility, it’s more important to check across different devices for accessibility. People who could have a limitation using a website will not always use the same devices to access the site. Limitations some users face are vision, hearing, and hand dexterity. These are addressed by making sure a website meets or exceeds WCAG 2.0 level A, AA, or AAA compliance.
Site Compliance For Accessibility On Mobile
Most auditors check the desktop version of a site for compliance. It’s important that responsive web design accessibility testing is repeated across different devices because of the adaptability of responsive design. Testers should test, at minimum, a desktop and a mobile version of their product. If possible, add breakpoint tests by including a tablet or small screen laptop. This could account for possible resizing on some devices which might change the accessibility, look and feel of the site experience.
Issues With Operating Systems And Screen Readers
Specific issues relating to operating systems have been found in regards to accessibility. Issues like reserved keyboard shortcuts, or how the supported screen readers will work with applications. An example of a variety of support per screen reader look at how they vary with reading out the title attribute. Test built-in screen readers and voice recognition software provided by the OS to ensure your site and the provided accessibility software works. For desktop you have VoiceOver for macOS, and Narrator for Windows 10.
Mobile Screen Readers
For mobiles, use the screen readers TalkBack or Voice Assistant (Android), VoiceOver (iOS), or Narrator (Windows Phones). If you are doing a basic accessibility test, such as a unit or an integrated test, then use a HTML validator, but these can report false negatives and vice versa.
Common Pitfalls Of A Responsive Site
There are a few issues commonly seen across responsive web design sites to watch out for when testing for accessibility.
The Assumption That The Users Will Switch To A Native Application
Most of us have seen a notification on a website suggesting you switch to the native app version instead of using the mobile version. These companies could have overlooked the mobile web version, or do not focus on it too much and would rather drive users to the native application. The company might think the use of the responsive web design version is mostly targeting users of tablets or larger devices, and/or it is easier to create a basic mobile web version without too much overhead. Testing the smaller resolutions becomes less of a priority.
Not all companies have native applications which often contribute to a gap in testing the responsive design on a mobile device. Being aware of a possible oversight when a company has both a native application and a responsive design web application could point to areas of the responsive website that need more coverage.
The Assumption That Screen Reader Users Will Not Use Mobile Websites
As shown in this survey of screen reader users, blind people do use a mobile with a screen reader. When a user has difficulties with vision, they may use a screen reader to hear page content rather than resizing the page to see the page content. Not all screen reader users are blind, and will see items they should be able to use but can’t due to incompatibility with the screen reading software.
The Guidance For Mobile Testing Is Still Reasonably New
It has only been since 2015, that the W3C completed a way to map the WCAG 2.0 checkpoints to mobile testing. The release of the mobile testing guidelines should help to further correct assumptions about accessibility options for mobile. They should be used in conjunction with the guidelines already laid out for web applications.
Translating Site Usage From A Keyboard To Gestures With A Screen Reader
A screen reader on a mobile device will change mobile interactions as it assumes the user cannot see the content. Gestures are used to identify the content, and then the user must double tap an item like a link or button to activate it. A double tap gesture is used to keep a user from accidently opening an unwanted item. The user must select the link to hear what it is, then double tap it to activate the link.
Sometimes a desktop screen reader or normal keyboard options are given as instructions to activating website elements. If the user is not using a bluetooth keyboard, then it could give descriptions that are misleading like “press space to activate” for a link that might only require a double tap action. This issue can break the WCAG 2.0 checkpoints of 2.1.1 (although described as a keyboard checkpoint, it also can apply to the gestures used for a mobile) or 2.4.4.
If you provide information on how to activate a control, verify the context is correct for the control. If a user hears they must use space, they may try to open the keyboard to use space, or may leave the site in the belief they can only open a link or activate a button by using a keyboard. This is an extreme example but should help show the type of gaps which could there between responsive and mobile versions of applications..
Notoriously Hard Feature To Make Accessible: Carousels
An example of a feature which is hard to make accessible are carousels. These can be notorious in the issues they can present for users trying to use accessibility features.
Items that carousel features include which could cause issues for accessibility and responsive design are:
A rotating content in a section.
Content highlighting different areas in the web site or products the company sells.
It could include links to segments or other sites and will often change the shown panel after a fixed amount of time.
It could include automatically playing content or videos.
It could include alerts which interrupt mobile screen readers.
Accessibility controls which are not compatible for a mobile responsive site or app.
Alerts in carousels tend to cause apps to fail the WCAG 2.0 checkpoints 2.1.1, 2.2.2, and 2.4.3. The alerts will interrupt a mobile screen reader wherever it is on the page and shift focus back to the start of the page or to the carousel. The screen reader will not pause the alerts and they override anything the user is trying to do. This can make it almost impossible for a user to navigate the page.
When a carousel has automatically playing content, this also can break the WCAG 2.0 checkpoint 2.2.2 as there should be an easy way to pause videos or triggered content. In some cases, the changing or rotating panels will not allow a user to pause the rotation. This means even sighted users cannot read each panel in the time they have. Screen readers often run out of time with panel content which contains more than a few links. If a carousel has implemented, automatically playing content, or rotating items, the users needs an option to pause or stop them.
Navigation issues with a carousel feature can fail checkpoints 1.3.1, 1.3.3, and 4.1.2. The mobile screen reader user might be able to navigate to each item in a carousel, including the hidden items which should only show on a visible content change. Items normally missed on the desktop, like page two of the carousel, are read out by the mobile screen reader causing the focus to move making it seem like the page is blank.
The left to right swipe gestures will gives focus to everything not selectable on a desktop with a tab key. Text, images, and graphics all obtain focus with swipe gestures. There could be controls like the page indicator buttons. Indicator button mentions are generally omitted by the desktop screen reader but are usually heard by a mobile screen reader user.It’s important for items like this to have meaningful labels for mobile as well as desktop. These indicator buttons usually have labels of “button or “1” instead of a descriptive label of what the buttons are or how a person could use them on their mobile device.
Accessibility Gains Using RWD For Apps & Websites
The mobile version of the website will often be in its own entity and people navigating to your website are often redirected to the mobile version. The number of versions a website or codebase has, the higher risk in having items updated in one place and not others, especially where accessibility needed to be addressed. Here are some of the reasons using RWD and accessibility together decrease maintenance for a website or app:
Reduce the application to one, maintainable code base.
Reduce the risk of missing updates to multiple versions of the application.
Reduce complexity of the code base by using RWD, which is understood and recognized by most browsers and mobile devices.
Maintain one set of rules for accessibility in one code base.
Content is easier to maintain and make accessible.
Fixes for Desktops Can Apply To Mobiles
While most elements for an application can be accessible, apart from the listed pitfalls, most items that are marked with the best accessibility practices for the desktop do translate to the mobile version. Using the correct method for labelling form fields works well for most screen readers. The work required to become accessible, in most cases, will only need to be applied once to a site, or as updates to the regulations are created. Other items to include for accessibility are:
The structure of pages
Links containing the correct context
Use of colours which meet standards for colour blindness or colour contrast
Use of required ratios for those with poor eyesight
Best Practice For RWD
Utilizing responsive design to give users better accessibility features is an ideal goal websites and applications should strive towards. Avoiding common design pitfalls can keep accessibility standards high and reduce the need for future rework towards industry standards. Educate development teams about the accessibility level the application is targeting, and how it can be applied to mobile. This will lead to increased use for targeted demographics which accessibility standards were designed for, and should increase the usability of your app or website. When accessibility and responsive design team up, everybody wins.
PowerMapper findings for the Title attribute support per screen reader.
Webaim screen reader survey results
W3C recommended mappings of WCAG 2.0 to mobile usage
Jared Smith interview with Creative Blog about carousels
W3C tutorial on labeling controls
Helen Burge has a Business Information Technology degree from Bournemouth University, and graduated in 2003. After leaving university she worked in testing and part of all her roles involved accessibility testing due to her fascination at how unappreciated the need is to make web sites and applications accessible. Helen worked closely with developers to help learn the most effective way to find and report issues. From this she built a unique test methodology to make sure accessibility bugs are not subjective but makes sure any issues raised are reproducible with actionable items. This approach has ensured the team can resolve issues and understand the impact on the end users.