Welcome to our series on the ICT Symposium’s Mobile Site and Native App Accessibility Testing. For the next couple of months we will be posting a couple of times a week! We will be posting a series of articles to help testers and developers determine and improve the accessibility of their mobile websites and apps. All this information is already online in Word format, so if you can’t wait check out our page on Mobile testing. Our previous article was Mobile Site and Native App Accessibility Testing, Step 1: Identifying devices – Day Two, or check out our page with links to all the published Mobile Site and Native App Methodology articles.
Step 2: Identify site type and variations
When testing mobile sites, it’s important to determine the site type before conducting testing. Is the site:
Desktop web sites have only one display, whether viewed on desktop, phone or tablet device
m.dot sites have a separate display specifically for mobile and tablet sites. The m.dot site must also be tested against the entirety of WCAG2, in addition to the standard www version of the site.
Responsive web sites change depending on the screen size or other feature as determined by the developer.
If the site is responsive, are there variations of the page? If so, you must test each variation against with WCAG2 and the mobile guidelines, and all functionality must be available on all variations of the page. Functionality can be hidden behind expandable menus, on a different page, etc., but it must still be available on every variation. The testing methods for responsive web site testing are dependent on whether there are variations of the page.
Why do people provide variations of a page?
Page variations are often used to highlight particular content on mobile devices, such as phone details, or to hide particular content on mobile, such as image galleries. Additionally, variations are used to hide functionality that doesn’t work on mobiles, such as a drag and drop. In that case, an alternative equivalent functionality must be provided.
There’s four main triggers for variations of a device. Developers will be able to identify one or more of the following features:
- The device (e.g. iPhone, desktop, Android, etc.);
- The operating system (e.g. Windows, iOS, OS, etc.);
- The browser (e.g. Safari, IE 11, Chrome, etc.); and
- The screen size (e.g. 280 by 720, 1920 by 1080, 320 by 480, etc.).
However in most cases, the trigger is the screen size. In this methodology we require that only screen size is used as a trigger to display different variations of the page – this allows users to access different variations of the page on desktop so they can choose the one that best suits their needs (for example, some people with cognitive disabilities prefer the mobile variation of a site as it often is less cluttered).
An example of a responsive website with page variations is the AccessibilityOz website. Notice how the indicated display elements, but not functionality, change depending on whether the site is being accessed via desktop or mobile. When determining the mobile accessibility of the AccessibilityOz website, both variations will need to be tested.
This document was developed by the ICT Accessibility Testing Symposium Mobile Sub-Committee. Members include: Gian Wild (Co-Chair), Peter McNally (Co-Chair), Brent Davis, Corbb O’Connor, Karen Herr, Kathryn Weber-Hottleman, Kathy Eng, Laura Renfro, Megha Rajopadhye, Mona Rekhi, Morgan Lee Kestner, Rafal Charlampowicz, Ryan Pugh, Steve Sawczyn, Sunish Gupta, Tom Lawton and Chris Law This document was developed by the ICT Accessibility Testing Symposium Native App Sub-Committee. Members include: Gian Wild (Co-Chair), Jennifer Chadwick (Co-Chair), Kathy Eng, Ryan Pugh, Kathryn Weber-Hottleman, Brent Davis, Laura Renfro, Peter McNally, Karen Herr, Steve Sawczyn, Sunish Gupta, Tom Lawton, Sam Bouchat, Rafal Charlampowicz, Damon Wandke, Morgan Lee Kester, Mona Rekhi, Corbb O’Connor and Chris Law.