How to document “Sufficient” coverage?

[rachaelbradley]

One concept we are exploring for WCAG 3 is creating suggested methods for the User Stack (see background below) that, when met, would only require the person creating content (author) to avoid breaking the existing support.

The follow up question is: How will authors know when they can rely on the user stack to meet accessibility requirements and when they must do so themselves?

Currently, the AG implicitly decides and documents when coverage it believes the user stack is sufficient, either by:

• Not writing guidance for the authors (example: Pointer indicator visibility), or
• Deprecating success criteria when the environment has changed so that the user stack is sufficient (example: 4.1.1)

Who and how should this be documented in WCAG 3?

Some points for consideration

• Because sufficient accessibility will vary based on the User Stack available, it will vary based on language, technology type, and environment.
• The AG will likely not be able to deprecate requirements as a way of documenting sufficiency because new user stack technologies will need the requirements.
• At a previous meeting we discussed what could be considered sufficient and are leaning towards the user stack meeting the accessibility requirement in a way that is available in the top 3/5/? most popular user stack solutions or that the way is free or nearly free technology (after purchase of the technology and base operating system).

Background: Authoring Stack vs. User Stack

The authoring stack includes all technology that contributes to the content being presented to the user. This includes:

• Author (Person creating content)
• Content Management Systems
• Overlays
• HTML/CSS/Javascript
• 3rd party content
• iFrame content from other sites

The User Stack includes all technology the person with a disability uses to access the content. This includes:

• Browser
• Assistive Technology (AT)
• PlugIns

[mgifford]

So how does this map to ATAG?

How are we defining a CMS?

[alastc]

Basically the 'internet pipes' are the dividing line between user and author.

We aren't trying to define a CMS for this, just that any tool an author users before the content/interface goes over the pipes to the user would be author side. Anything the user has to interpret that content would be user-side.

[patrickhlauke]

• Browser
• Assistive Technology (AT)
• PlugIns

Also Operating System, and potentially (?) even hardware (i.e. if they have a particular input device, or even a particular output device - that latter could even include things like audio output)

[alastc]

Yep, as above, the dividing line is the 'pipes'. But the question is about how we know when support on the user-side is sufficient that authors don't have to meet the requirement (maybe just avoid breaking it). E.g. when is 'high contrast' mode available enough that authoring in high-contrast is not a basic requirement?

[rachaelbradley]

One possibility, would be following or building on the ARIA group's AT Interoperability.

We would then need rules for when enough support existed that we could declare an outcome sufficiently covered within a specified scope (example: English Language web content).

[u9000-Nine]

This might seem like an overly simple suggestion, but could we just put up a CanIUse-style wiki?

That would allow both us and the community to collectively reach consensus on support by different UAs/AT/etc

[alastc]

Well, say you have a page like this with some support but far from universal, how do we say whether that is sufficient for the author to rely on for conformance?

[patrickhlauke]

it will need to be somewhat authoritative, and constantly maintained ... which is usually where things like that fall down (thinking about lots of different documentation initiatives like that which, after some initial enthusiasm and interest, fade into non-maintained obscurity)

[u9000-Nine]

Well, say you have a page like this with some support but far from universal, how do we say whether that is sufficient for the author to rely on for conformance?

That page shows universal support among desktop browsers since at least 2018, and partial support among current mobile browsers. I'd say whether it's sufficient depends on the target environment. An internal, employees-only site, for example, can say "we only use these browsers and AT", but a general website cannot.

---

it will need to be somewhat authoritative, and constantly maintained ... which is usually where things like that fall down (thinking about lots of different documentation initiatives like that which, after some initial enthusiasm and interest, fade into non-maintained obscurity)

The AT vendors would have an incentive though to keep their data updated. Plus, since it'd be a wiki, anyone reading the page who notices something is outdated can just fix it. Do you have any wiki-based examples of documentation falling into nonmaintained obscurity?

[patrickhlauke]

The AT vendors would have an incentive though to keep their data updated.

the same AT vendors who have also, for decades, had an incentive to work closely and collaboratively with WAI and the wider community, and - with some exceptions - didn't.

anyone reading the page who notices something is outdated can just fix it

it's not usually a question of technology (there's lots of variants that involve "send a github PR", "email us", "fill out this form", etc), but of people actually caring enough to maintain something, even if they do spot outdated info (rather than just shrugging and moving on, mentally making a note that "well this is probably out of date then..."). and the problem is generally that there are many small competing places that try to document things, so attention/goodwill of contributors is spread thinly.

[GreggVan]

There is a big difference between working with WAI etc. when it is a lot of work -- and spending a few minutes to update a chart to increase the score for your product - and possibly increase sales.

But I agree that we should not throw rocks at vendors when we don't take the time ourselves to fix a mistake when we see them.

So my conclusion is that you should never expect that something will be maintained unless there is sufficient remuneration. Getting it set up through volunteers - yes. that sometimes works. But maintaining it has to either be funded - or it has to be something some one person is dedicated to (and then only as long as they are ) or it has to be tied to increased profit if done. (Oh, there is one other -- and that is if you are regulated to do it - and there are real financial implications if you don't)

Sound like an cynic? Not really. There are lots of wonderful people in the world -- but everyone wants to get home to their families or partner -- and has a pile of work they can't get through each day to get there. Just reality.

[wareid]

Several people have pointed to CanIUse and ARIA AT, but I'd also point to a project like a11ysupport.io, which falls into the same trap many places do of requiring constant support and maintenance, but the value is high. This is maybe something we should take up to W3C/WAI leadership as an example of a project worthy of funding for its value to the community (and we could drive fundraising for it).

The challenge with defining what "sufficient" support for an author is mainly lies with the highly variable combination of front-end and back-end technologies at play. I believe we could reach a point where we can identify and reliably reach a "CanIUse" level of confidence with the User Stack (browser/AT/OS) side, but the Author Stack remains complex.

We could create assertions that authors could refer to for confidence, if parts of the Author Stack were willing to adopt them. Just to provide an example, and please imagine a world where the User Stack is well-defined, so interop on the browser/OS/AT side is good:

Author is building a website using a popular website-builder/CMS tech stack. We can give the Author confidence on "sufficiency" IF:

• The website-building platform has documentation asserting that the themes/widgets are accessible to the standards of WCAG x.x,
• The platform provides the Author tools and assistance guiding them to ensure their input maintains the accessibility of the theme/platform,
• The platform provides some ability for the Author to validate their input,
• The Author follows the recommendations of the platform when building their website.

It's the interplay between the Author and the Stack they are using that makes Sufficient a challenge, because even if we do reach a place where platforms or tools within the Author Stack also meet accessibility requirements, the Author can still break accessibility with their own actions. I think it would be impossible/overly burdensome to enforce the Stack trying to prevent errors on the Author side, but if guardrails can be established, and the Author takes on the responsibility of following the guidance of the tools within the Stack, we can create some confidence around Sufficient support.

[rachaelbradley]

Summary of 27 August 2024 Discussion

Some notes:

• Providing a current status option has been tried before with limited success
• Any solution we create must be as simple as possible to maintain
• Ideally the maintenance would be funded in some way

Three options were proposed:

1. Maintaining a wiki where anyone can update the current status. A WAI resource would then review and validate the wiki and post an "official" version periodically.
2. Providing a way for companies that provide technology in the user stack to report on their current status. A WAI resource would then validate and maintain a site with the information.
3. The AG group could try to keep a relatively small set of AT that we test methods / techniques against, using tick-boxes in a content management system (CMS) to indicate support.