Turning off CSS For Accessibility-Focused E2E Tests?

Question

I am in the process of receiving training in a11y accessibility WCAG 2.0/2.1 standards, and I saw some testing recommendations involve testing the page with CSS turned off to ensure elements are rendered in an order friendly to screen readers.

Is there a way to configure an e2e test pass to turn off css styling for this purpose? Either within cypress or through some external configuration?

Answer 1

That recommendation is not actually a good idea and perhaps may be out-dated.

You see if you use something like flexbox and change the order of elements of the page using flex-direction: row-reverse (for example) your site would probably fail WCAG 2.4.3 Focus Order.

Now if you turned CSS off, you would not be aware of the problem (assuming your DOM order is correct).

DOM order is important for accessibility (especially as some browsers are text only), I am not saying it isn't, but what the end user actually has to interact with is more important.

As screen readers take their information from the accessibility tree the browser exposes (which is influenced by the CSS if it changes the order of DOM elements) you need to test with CSS turned on.

What should I do?

By all means turn CSS off, you can use something like Web Developer plugin for that.

It is a useful sanity check that you aren't reordering things with CSS to counteract the fact that your DOM order is incorrect.

However yet again if you look at raw DOM order you may find that you think something is in the wrong order, correct it and then miss the fact that it had it's order swapped by CSS.

For 99% of testing leave CSS turned on.

A better test is to look for any classes in your CSS that may change order (float: right, flex-direction: row-reverse etc.) Then identify elements that use those classes and just see if everything looks correct.

A great tool for testing your site tab / focus order is Accessibility Insights. This will often pick up incorrect ordering of the page, whether by CSS or by DOM order.

One of the tests is for "Tab Stops" and all you do is start the test and tab around the page.

It gives you a visual indication of what was focused, as well as numbers on each item so you can review them later (which is great for large teams when you need to highlight specific issues).

The test takes all of 2 minutes to perform manually, so far I have yet to see a good automated solution so manual checking is the way to go.

The best test

Forget automated tests, just fire up a screen reader and use the page.

Obviously you should only do this at key points in the development cycle but within 30 seconds you can find most errors once you get proficient with a screen reader. This is also really handy for picking up weird issues such as paragraphs reading in the wrong order.

Cover your screen, switch on your screen reader of choice and set yourself a task, e.g. "fill in the contact form".

It will give you waaaay more feedback than automated testing.