WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Testing SC 1.4.12 in multiple browsers

for

From: Steve Green
Date: Sep 23, 2021 10:00AM

While agreeing with Glen, I would take a slightly harder line. The WCAG success criteria do not mention the behaviour with screen readers or any other assistive technology. You do not need to use any assistive technologies at all when doing a WCAG audit. In just about every case, your pass / fail decision MUST be based on manual inspection of the code and user interface. Tools and assistive technologies can provide useful support, but they are often wrong or misleading.

Some time ago, I went through all the WCAG success criteria to determine which ones need to be tested with more than one browser. Glen has already mentioned some for which that would not be necessary. I reckon that of the 50 level AA success criteria, only these 7 need to be tested with multiple browsers as a matter of routine:

SC 2.1.1: Keyboard Navigation (level A)
SC 2.1.2: No Keyboard Trap (level A)
SC 2.4.1: Bypass Blocks (level A)
SC 2.4.3: Focus Order (level A)
SC 1.4.4: Resize Text (level AA)
SC 1.4.10: Reflow (level AA)
SC 1.4.11: Non-text Contrast (level AA)

Depending on how the website is coded, it may be necessary to test other success criteria with multiple browsers. That's usually an indication that the code is pretty horrid.

It might even be safe to drop SC 2.4.1 (Bypass Blocks) from that list. Some browsers used to scroll the page but not move the focus position when in-page links were operated, but I don't know if that is still true.

I don't recall getting different results from different browsers with any of the other 43 success criteria, so I would be very interested to hear if anyone else has. Even if there are a few more, anyone who is testing all 50 in multiple browsers is wasting an awful lot of time.

Note that I am not arguing against testing with assistive technologies. It's just that doing so constitutes an "accessibility test", which can be anything you want it to be, not an audit for WCAG conformance, which has a defined scope.

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen walker
Sent: 23 September 2021 16:06
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers

In theory, your application should work in every browser (firefox, safari, chrome, edge, ie, opera) on every platform (mac, pc, mobile) with every assistive technology (nvda, jaws, narrator, dragon, switch, talkback) at every CSS breakpoint.

With unlimited budget and time, you could test every combination. But for practical reasons, the testing is usually "limited" to a few combinations (or even one combination in extreme cases). I say "limited" but that's with respect to the various combinations. It's not limited in how extensive the testing is regarding testing every element on the page.

More often than not, an accessibility issue that occurs with one combination will also appear in a different combination. An image missing alt text is going to be a problem no matter what browser you're testing on. A list that is not semantic will be a problem no matter what browser you're testing on. A table without headers is going to be a problem no matter what browser you're testing on.

There are, of course, minor differences between the various combinations so sometimes you can find a problem with one that doesn't exist on another.
For example, having something like "first name <input>" will show up as a problem when testing with NVDA on both chrome and firefox but if you test with JAWS, it reads ok on chrome (but not firefox). So if you were only testing JAWS on chrome, you might miss the problem. (This is why I usually look at the code too and not rely solely on a screen reader to find issues. Even if a form reads ok, I typically look at the html to see if the label is really associated with the field.)

Another difference between browsers is if you have a scrollable container (overflow). When a container has a scrollbar, firefox makes that container a tab stop but chrome does not. So now you have a tab stop that potentially does not have a name or role. It could be confusing for a screen reader user on firefox.

I know this is all digressing a bit from your original question, asking if you needed to test 1.4.12 in all browsers. The short answer is "yes" - test everywhere, or at least as much as possible.

In your particular case, I have not seen a problem with the Stylus plugin
*not* applying to iframes. I *do* see the problem with the bookmarklet not applying to iframes. So Stylus should work if you want to test for 1.4.12. I edited my style and added the same code that the bookmarklet
uses:

* {
line-height: 1.5 !important;
letter-spacing: 0.12em !important;
word-spacing: 0.16em !important;
}
p{ margin-bottom: 2em !important;}

When I viewed a page with an <iframe>, the styles were applied to the iframe. You can test it with https://www.w3schools.com/html/tryit.asp?filename=tryhtml_iframe_height_width.
It has 2 nested iframes.