RE: Updates to Understanding 1.4.11 part 2

  *   Or for Bypass Blocks, would you fail a skip link that didn’t work in Safari/Chrome because of their bugs?

Yes, we would have in situations outside of closed environments like the US government when the WebKit bug existed requiring skip links to also have focus set.    In public situations where we thought Chrome/Safari would have been used by the population and was generally accessibility supported with assistive technology we were actively bringing up this issue.

Jonathan


From: Alastair Campbell <acampbell@nomensa.com>
Sent: Wednesday, June 13, 2018 10:40 AM
To: David MacDonald <david100@sympatico.ca>
Cc: WCAG group <w3c-wai-gl@w3.org>; LVTF - low-vision-a11y <public-low-vision-a11y-tf@w3.org>
Subject: Re: Updates to Understanding 1.4.11 part 2

> The technology relied upon in WCAG is the tools that users are expected to use to get the benefits of the WCAG conformance.

That isn’t how it is defined in WCAG though, part 5 is “web content technologies”:
https://www.w3.org/TR/WCAG21/#conformance-required


The user-agent part is in the optional components, “A list of user agents, including assistive technologies that were used to test the content.”

From the thread on issue 298 you pointed to the combination of 1 (satisfying A & AA criteria) and 4 (accessibility supported ways).

However, I think this is a bit different, it is not like this:
> There was no assistive technology and no initiative by apple to do anything about that, and back then is was basically JAWS, Windows and IE ...

All the browsers have a default focus style, it is just that some of them don’t meet this new criteria.

Then as Patrick said:
> There's of course a slippery slope issue: user agents/ATs on certain platforms are quite limited or buggy - but normatively mandating that authors need to code workaround solutions to be able to pass WCAG shifts the onus purely on the developers, when really user agents/ATs should get their house in order under UAAG requirements. this makes developers responsible for browser bugs, screen reader bugs, etc

Currently we are shifting the onus onto developers, in fact the examples we found of people using the default focus-styles were accessibility-aware organisations trying to do it right!

If bugs are raised on those browsers and they fix it later, we’ve wasted a lot of people’s time.

And, as John said:
> most designers I've met want to control all aspects of the design, on all platforms…

Those people would not hit this issue, they would have over-ridden the outline anyway.

> We simply cannot require content to work on all or many combinations.

I’m trying to think of WCAG 2.0 SC that could have been in a similar position. All I can think of is 1.4.5, around “If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text”, did people account for browser support?

Or for Bypass Blocks, would you fail a skip link that didn’t work in Safari/Chrome because of their bugs?

Overall, I think the main options are:

  *   Treat default focus styles as a user-agent issue, if authors don’t set the outline / focus-style then don’t fail it.
  *   Highlight in the understanding that certain browsers default focus styles may not meet this SC, and that should be considered as part of accessibility-supported whether you deal with it.

Cheers,

-Alastair

PS.
> Hmmm.... when was the last lawsuit that had any effect in the UK?

There have been some, but they have all been settled out of court (we sometimes get asked to assess sites for these cases). As a complaint has to be started by someone with a disability, it is generally quite practical issues that get raised, WCAG is a fall-back method if the arguments get to the point of ‘what is reasonable’, or to give a more general assessment than what that person found.