Responsive web design is crucial for both accessibility and usability. There are multiple ways of making websites responsive, but using CSS media queries are still one of the most used. Sometimes it’s enough to use just a couple of media queries (for example “mobile” and “desktop” views), but often we need more (consider also “tablet”, “landscape”, “portrait” and so on).
With “mobile” or “tablet” I also mean smaller screens, but also screens that are zoomed in, that’s the crucial accessibility aspect of responsive designs. In this post I will target mainly media queries related to size and orientation, but we need to remember that other media queries are also relevant.
Accessibility testing needs to cover all media queries
Media queries are often used to collapse things on smaller resolutions, like for example navigation. This can be a giant change in terms of accessibility and usability. Another example is changing positions (for example image on the left of the title versus image under the title, visually).
All these changes impact user experience and may introduce accessibility barriers.
We can not claim conformance before we are certain that we checked each variation of the page that is “automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page)”.
Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.
Web Content Accessibility Guidelines on conformance (opens in new window).
A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.
WCAG Note 3 on conformance (opens in new window).
That’s why it is so important to test in all of them. Which also means that we need to collect information about media queries before we can estimate how long will it take to test for accessibility.
Media queries have a direct impact on time needed to test for accessibility.
Make sure you check media queries before you estimate the time needed.
Time is money and we are often in situations when we need to estimate how long will a task take. I have seen pages with dozens of media queries and I have seen pages that didn’t have a single one. If we don’t consider media queries we may produce invalid time estimates for accessibility testing. Please make sure you get the information about media queries before you provide any time estimates.
Ways of checking for media queries
Are third parties in scope?
Users usually doesn’t mind about first, second or third parties – they are a part of their experience. Before we test for accessibility, we need to check what is in the scope. Sometimes stakeholders don’t want us to test third parties and ask them directly for their accessibility conformance.
In my experience third parties like cookie consent, video players, chat solutions often don’t provide accessibility information and in such cases I advise to check them for accessibility issues as well. This can then mean additional CSS media queries that we need to consider…
Ask designers and developers
My suggestion is to ask the people that introduced media queries. Chances are those will be documented somewhere. Often design mock-ups include also general breakpoints and often they have information about media queries.
Often those are not enough and we need to check with developers to get the rest. Chances are that they have documented them somewhere, perhaps they use a design system or style-guide and perhaps they have documented them there.
That’s a good start, but only if we have the possibility to communicate with them (sometimes we can’t).
Always check by yourself
Even if we get all media queries from designers and developers, we need to make sure that there are no others. Sometimes documentation gets out of sync, so we need to make sure what is the reality anyway.
Checking manually in files
We can start with using our browser to quickly get an idea about media queries on a page. The downside is that this is only relevant for that exact page, but it will help us to test different dimensions
We can manually search for media queries in all CSS files that are used on the page. This in itself can take quite some time, but will provide a good background for mapping the situation.
Using browser’s developer tools
All browsers include usable developer tools. As an example, I like to use Google Chrome’s device toolbar and it comes with “Show media queries” feature (opens in new window). Unfortunately such features are not very accessible and they also use color alone to provide key information (blue bars mean max-width
breakpoints and orange bars mean min-width
breakpoints).
As mentioned in the beginning – there are media queries beyond viewport sizes and orientations and you can also check how to emulate other CSS media features (opens in new window).
Automatic possibilities for media query extraction
I’ve tried to find a programmatic way of getting all media queries on a page with JavaScript. It’s possible to get all media queries by using document.styleSheets
and then check cssRules
, but if website includes an external stylesheet this method will fail due to security restrictions (violation of a Cross-Origin Resource Sharing (CORS)).
This means that we can at least get some parts automatically. And it also means that we can get all of them if we disable browsers web security (please be careful with that!).
We can also use an automatic tool to crawl the URLs in the scope and extract media query information for reference. I made some proof of concepts that I sometimes use, but as they need manual re-visioning they are not very useful. I’ve done some experiments to automate accessibility testing on different screen-sizes, based on extracted media queries, but it was not very effective for webpages with complex media queries (and we also need to test manually, so it was not worth the effort to improve the algorithms behind it).
Perhaps such automatic testing method will be possible with some future automatic accessibility testing tools that will use machine learning and other advanced techniques to find which media queries are actually used and which are relevant for tests. Either way we anyways have to check things manually…
Conclusion – reporting
When we test with relevant media queries we also need to report them in our findings. There are different WCAG success criteria that can have different results in different situations, so it’s critical to provide the information on how to reproduce the failures. Obviously – when media queries are directly or indirectly behind the reasons for the failures – we need to explicitly document them.
In my experience I have not seen a lot of accessibility statements and accessibility conformance reports stating media queries beyond “mobile” / “tablet” / “desktop”, but I recommend being as specific as possible, so that at least users that are familiar with their subjective situation can get better understanding.
And if our report is used to provide input for the backlog – we need to provide as many as possible relevant data, so that designers, developers and testers can quickly re-produce the problem.