WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Testing SC 1.4.12 in multiple browsers

for

From: Steve Green
Date: Sep 25, 2021 7:25AM


"So, if we're reviewing or auditing a site that uses this date input, what's the best approach?"

It all depends on what you mean by "reviewing or auditing a site". Are you testing for WCAG conformance or are you testing the user experience? They are not the same.

If you are doing a WCAG audit, my view is that it passes. The input type="date" element is accessibility supported as per the definition at
https://www.w3.org/WAI/WCAG21/Understanding/conformance#accessibility-supported-definition

The definition does not require that the Web content technology is supported by ALL user agents as long as it "is supported natively in widely-distributed user agents". In fact it goes further and says "The Accessibility Guidelines Working Group and the W3C do not specify which or how much support by assistive technologies there must be for a particular use of a Web technology in order for it to be classified as accessibility supported."

By contrast, if you are doing an "accessibility review" or "assistive technology testing", then you should indeed report that the input type="date" element is difficult or impossible to use with Voiceover and Dragon.

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Graham Armfield
Sent: 25 September 2021 11:12
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers

Wolfgang said...



*2. Can we blame problems resulting out of bad behavior of browser or
AT?a) If elements and attributes of HTML, CSS or ARIA are used according to the spec, can this ever be considered as failure in an *audit*?*

I think this is a very good question. And in some ways we do have to take some view on this when reviewing websites for accessibility.

One example would be the use of input type="date". This input type has been in the HTML5 spec for a good few years now, and in many browsers, with many ATs it can provide a fully accessible way of allowing users to select a date - including a date picker.

But I believe that it's still not really supported in Safari on macOS, and it can be a difficult control to interact with when using Dragon NaturallySpeaking.

There is an outstanding issue on Apple, but last time I looked there seemed to have been no movement. I also contacted Nuance about Dragon and they seemed less than interested.

So, if we're reviewing or auditing a site that uses this date input, what's the best approach?

Regards
Graham Armfield
Coolfields Consulting



On Fri, 24 Sep 2021, 15:31 , < <EMAIL REMOVED> > wrote:

> Thanks Glen, a good list for reflection!
>
> 1. I just thought of adding 4.1.1 to detect bad behavior of browsers
> and/or AT by testing with SR.
>
> E-g- I remember aria-errormessage to be hardly supported.
> Would the usage despite support touch 4.1.1?
>
> 2. Can we blame problems resulting out of bad behavior of browser or AT?
>
> a) If elements and attributes of HTML, CSS or ARIA are used according
> to the spec, can this ever be considered as failure in an *audit*?
>
> b) To which degree do we have to respect bad behavior in a
> *development process"?
>
> Wolfgang
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Steve Green
> Sent: Thursday, September 23, 2021 6:01 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Testing SC 1.4.12 in multiple browsers
>
> 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_heigh
> t_width
> .
> It has 2 nested iframes.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >