Here’s my web compatibility checklist that includes comprehensive accessibility testing.
I’m testing with the following real devices:
- iPhone with a notch
- Pixel with a notch
That’s it! I’m able to use macOS Bootcamp to dual boot to native Windows 10.
You can, of course, emulate both iOS and Android. This is useful for inspecting layouts without the notch. But an emulator sometimes doesn’t behave quite the same way.
If you are on a Windows or Linux PC, there won’t be a way to test any proprietary Apple software. I’ll look at how to emulate Safari later — WebKit is open source.
You should look at your analytics to see what kind of coverage you want to support for older browsers.
In most cases, unless I want to charge more for the engineering time, the following list is my baseline.
I get to use ES6, CSS Grid, CSS variables, Web Components, and other modern features.
When testing across browsers, I usually like to have a common set of workflows using various amounts of data.
- Latest Chrome (79)
- N-10 Latest Chrome (69)
- Latest Firefox (71)
- Latest Firefox Enterprise (ESR 68)
- Latest Desktop Safari (13)
- N-1 Latest Desktop Safari (12)
- Latest Mobile Safari (13)
- N-1 Latest Mobile Safari (12)
What about Internet Explorer and Edge? IE is present but buried in Windows 10, and Edge Beta with Chromium is available for download. It will soon replace the existing Edge. If you have a high number of Edge users, add it to the browser support list, or consider providing a download link to Edge Beta.
If you want to emulate Safari on Windows, you’ll need to install Ubuntu from the Windows Store. You’ll need to install an xServer emulator and have it running. Then run
apt-get update && apt-get install epiphany-browser in the Ubuntu shell. Add
export DISPLAY =:0 to your bash profile. Then you can run
epiphany-browser to test WebKit on a PC.
Are you testing for accessibility? You should be! People with disabilities, such as blind people, need to be able to interact with every app and website. That’s done with semantic HTML and ARIA.
All operating systems now come with a screen reader that interacts with the underlying Accessibility API. You can use ARIA to modify the Accessibility API.
When using a screen reader, you use a keyboard to navigate between items using a virtual cursor (essentially the same as the focus cursor) and interact with the web page. There is usually a developer setting to show the text on screen as it would be spoken.
Here are the assistive technologies I test with:
- Windows Narrator (Windows 10)
- VoiceOver (macOS and iOS)
- TalkBack (Android)
- NVDA (Windows 10) is a free download
I test the markup at various stages (adding items to cart, deleting items from cart, etc) using three helpful developer tools:
- validator.nu HTML/ARIA Validator
- axe Chromium Extension
- Accessibility Insights Chromium Extension - This will walk you through many different accessibility scenarios
Of course, none of the time spent testing comes for free. Make sure you work with your client or project manager to integrate your inclusive testing plan into the overall project plan.
So, did I miss any? Or go overboard? Tell me about your testing plan!