View source for April Report to the Silver TF

April Report to the Silver Task Force

April Report to the Silver TF
Draft! --- Draft! --- Draft!

Report of the Conformance Options Subgroup
 29 April 2021

As set forth in our sub-team's [[Substantial_Conformance#Working_Timeline|timeline of work]], we are delivering Initial proposals for use cases not addressed by WCAG 3, for Silver to consider.  This report covers 2 Principles and 7 use cases we have developed which have yet to be addressed by WCAG 3.
A further report on uncovered use cases is due in May.


=Uncovered for WCAG 3=

We address two principles in this report:

* All software has bugs
* Third Party Content

NOTE: the precise wording for these principles is not yet final.

=All Software Has Bugs=

Note: See also [https://github.com/w3c/silver/issues/277] github issue 277

==Principle on Bugs==

All software (and likewise all dynamic websites) of large enough size or
complexity has bugs; this is unfortunately unavoidable.  Websites and
applications that claim conformance to WCAG 3 should have no greater
acceptance of accessibility bugs than the site or application has for bugs
generally, nor should accessibility bugs be disproportionately represented
among the number or severity of bugs found. "Everything has bugs. Some are
accessibility-related and some aren't. Accessibility-related bugs should
not be overrepresented in the bugs overall, tolerated more than other bugs, or
given a lower priority for fixing."

==Clearly communicated, unfinished/preliminary product==
Our 2 use cases illustrate a not-uncommon commercial practice of a broadly available, but clearly preliminary/unfinished website or product, where expectations are set there may be issues, rough edges, etc. - and those may include accessibility issues.  There are a variety of ways this is done, including "public beta", "early access", "invite only" (with invitations sent out to the public at large, but in limited numbers, etc.).

==Use Case A: ~6 month "public beta"==
A startup company comes out of "stealth mode", and unveils their first product - a web application - which they know isn't ready for broad adoption.  However, they feel they can best improve their offering by getting a much broader pool of feedback than possible with the small number of employees on their staff and their families.  They call what they've released a "public beta", and it has significant functionality issues affecting all website visitors.  These include that key aspects of the website don't work properly in popular web browsers - especially older versions of those browsers that are still in very common use - not handling non-English date formats, etc.  They also include serious accessibility bugs.

==Use Case B: Video game playtest==
An established game company that has released dozens of games, releases a public, free "playtest" of a new multiplayer game they are developing, months ahead of planned commercial launch.  This new game includes several new features that they are developing, including new accessibility features.  Throughout the playtest, they are rapidly iterating on new features, adding new levels, creating new monsters, modifying how weapons work, etc.  Throughout the playtest, new content is posted without always making it fully accessible (e.g. lacking captions and audio descriptions for the brief in-game videos).  Meanwhile, the accessibility features they are working on are also going through continuous revision, and like other parts of the game during the public playtest, are periodically breaking as they are developed "in public".

== Potential solutions / directions to address these use cases==

After wrestling with this principle, the only option we've found thus far is some form of attestation from the product or website owner that the organization is providing equal treatment of accessibility related bugs as compared to the product or website overall (e.g. with WHO data indicating a little less than 1% of the world population is blind, that roughly no more than 1% of bugs impact screen reader use). We also suggest considering whether this principle may be captured in the Maturity Model.

=Third Party Content=

NOTE: See also [https://github.com/w3c/silver/issues/450] github issue #450

==Principle on 3rd party content==

WCAG 3 should be designed with 3rd party content in mind; there shouldn’t be a notion of “partially meeting the solution” that only looks at 1st party content.  The language of an assessment of the solution might nonetheless call out any 3rd party distinctions.

===Categories of 3rd party content===

We have found thus far that third party content generally falls into three categories, with some further sub-categories/variants, though our use cases also demonstrate how a given site can combine content from two or all three of these individual categories:

* Content prepared or provided under contract 
** Static content or embeddable software
** Content where copyright is licensed under copyright restrictions vs. included without restrictions
* Freely submitted end user content
* Content previously published under copyright

It is important to recognize that WCAG will apply to all content regardless its providence. The distinctions are relevant to the extent that they impact the difficulty of making the 3rd party content accessible. Recognizing and apportioning responsibility appropriately given these distinctions may be an important factor in defining meaningful and appropriate conformance approaches.

Each use case below notes major categories of third party content illustrated by that use case which in turn points to potential solutions for consideration below. 

==Use Case C: Complex & highly dynamic site with a mixture of 1st party, 2nd party contracted/commercial, and 3rd party/end-user content - for example, a partially curated travel site==
This use case mixes together many of the different categories noted above, providing a real-world example of the richness and complexity that WCAG should be able to address. Specific potential solutions to address the distinct categories are described in the simplified use cases further in the document.

There is a very popular and active website that connects frequent travelers with each
other for discussing their travel, and contains pages that intermix
professional reviews of destinations developed by the site itself, with
professional reviews licensed from 3rd party reviewers, all alongside
contributions and comments from the traveler/members.  Content from all three
sources includes text, photos, videos, audioscapes, and even 3D models of
destinations. Licensed content is owned and under copyright of the owner, with
the site acting as a reseller of that content. Traveler/user content often
includes first person travelogues, which may make reference to sensory
information ("Down the street you can find the entrance to Benny's tavern,
clearly identifiable by its distinctive red awning"). Thanks to the popularity
and enthusiasm of the site, over 1 million page updates take place each and
every day.

==Use Case D: Contracted Third Party Functionality - for example, 3rd party offers commercial, embeddable web payment system==

A local scouting group has a website that includes a section for buying scouting merchandise. It uses the 3rd party PaymentFriend commercial payment service for processing payments (just as does our travel site in Use Case C above).  Unfortunately, PaymentFriend's embedded web payment interface contains a few accessibility failures, and the scouting group hasn't found an alternative that meets their needs and doesn't have any accessibility failures.

=== Potential solutions / directions to address this use case ===
The WCAG 3 conformance model might support the scouting group making a claim of conformance that clearly identifies the 3rd party accessibility issues with PaymentFriend, noting the steps they have taken to address them (e.g. that they have notified PaymentFriend of the issues and are awaiting resolution). 

The small organization has no leverage on a large organization, although sometimes if they call it out, other small organizations can step up and add leverage.

COMMENT :This potential solution/direction itself has challenges, as the embedded web payment system may be critical to the use of the site - in which case we could have a “conforming site” whose primary purpose isn’t accessible. Similarly, if the web payment system has a critical error (e.g. strobing which may trigger a photosensitive seizure), we again could have a “conforming site” that contains a horrible problem.

==Use Case E: 3rd party user generated content - for example, end-user comments on otherwise accessible content==

A site containing on-line journals of highly technical material allows user comments.  While authors of journal articles are required to include clear language summaries (in keeping with WCAG 3 Clear Words expectation), which are verified by paid editors, website visitors are not required to similarly make clear language summaries of the comments they submit on articles (just like website visitors to the travel site in Use Case C above).  

=== Potential solutions / directions to address this use case ===
The WCAG 3 conformance model might support the journal website making a claim of conformance that clearly identifies the accessibility issues with website visitor provided content (and where they can be found on the site), noting the steps they have taken to address them (e.g. that they prompt the user to create ALT text for their images before they are uploaded, that they don’t allow the use of text attributes except as they are part of semantic markup such as strong, headings, etc. - variants of the site has have added code to help encourage users to improve the accessibility.).

COMMENT: This potential solution/direction itself has challenges, as the user generated content may include text important to a visitor which is completely unusable to them - in which case we could have a “conforming site” that blocks something important to a group of site visitors.

==Use Case F: Copyright content where copyright holder doesn't give permission for accessibility - for example, aggregated videos from heterogeneous sources==

A website embeds a collection of videos from a large cross-section of authors/companies on a particular topic (e.g. woodworking).  Some of these videos lack audio descriptions, and are copyright by the 3rd party who refuses permission to have audio descriptions created for them (just like some copyright holders of content on the travel site in Use Case C above).

=== Potential solutions / directions to address this use case ===
The WCAG 3 conformance model might support the video website making a claim of conformance that clearly identifies the titles that come from copyright holders who have not provided audio descriptions & don't give permission for the addition of audio description tracks (e.g. list of these companies, or list of titles).  Additionally, all video titles are clearly marked as having audio descriptions or not, so the website visitor who needs audio descriptions could easily determine whether they are present before deciding to view a particular video title.

==Use Case G: Accessibility On Demand - for example, a Legal Evidence Service==

A web content provider, KD, Inc.,  is in the business of collecting and indexing laws and judicial decisions. Among its several subsidiary services is the collection, organization, and on demand publication of evidentiary exhibits for use in jury trials.

The source material comes to KD, Inc. in inaccessible formats.  When a court customer notifies KD, Inc. that it has impaneled a juror who is a person with a disability, expert KD staff are immediately able to provide the required additional content that makes those exhibits accessible and ready for use at trial, because the CMS used by KD, Inc already supports making content accessible according to the WCAG 3 specification. Courts benefit by receiving expertly annotated content when it's needed "on demand," while KD, Inc. avoids the steep cost of making every exhibit accessible in advance "just in case."

KD, Inc also provides its other customers who are persons with disabilities adapted content on demand, but with limitations on those adaptations.  They provide the content in braille, but lacking court permission, are unable to provide plain language summaries.

=== Potential solutions / directions to address this use case ===

The WCAG 3 conformance model might support special purpose websites & products, that have a "deliver upon demand" model for addressing accessibility failings in material they get from 3rd parties.