Silver Task Force & Community Group

09 April 2021


AngelaAccessForAll, Azlan, ChrisLoiselle, Fazio, jeanne, Jemma, jennifer_strickland, JF, johnkirkwood, KimD, Laura_Carlson, Lauriat, MichaelC, sajkaj, SuzanneTaylor, Wilco
Charles, Francis, Sarah, Todd
jeanne, Shawn

Meeting minutes

reminder of meeting with AGWG on 29 April 2021

jeanne: Rachael sending out a "save the date" email with three identified 2-hour blocks for telecon on conformance

jeanne: We will meet with AGWG and work out path forward; incl Bronze/Silver/Gold

jeanne: Asks whether anyone has the actual time of the 2-hour blocks--


jeanne: Look for email from Rachael

sh9-11; 1pm-3pm; 5-7 All Boston Time

sajkaj: Notes not optimal for many; California, Europe ...

updates to the Style Guide for people interested in participating

<Lauriat> WCAG3 Style Guide: https://docs.google.com/document/d/1sInhvjkvq5WASlOrEMfshAZSVQB8kM1clRWfGXfVEFI/

jeanne: Believe we have updates to the style guide to guide many more authoring volunteers

jeanne: Angela has been working on those updates

jeanne: Comments have been requested; Please contact Angela

<MichaelC> https://www.w3.org/WAI/GL/task-forces/silver/wiki/Silver_Style_Guide

MichaelC: The guide I know of is at the URI I posted; If incorrect, need to checkin

jeanne: At the moment a Google Doc for ease of working and includes Michael's sections; can go back into W3 space

MichaelC: Suggests should always be a known location

jeanne: We will move it back into the wiki

jeanne: Current draft is a merge of all the docs

MichaelC: OK

jeanne: Wanted it on the agenda to make everyone aware and get clarity of what we're doing

Bronze Silver Gold options

jeanne: Asks Shawn to facilitate this discussion

Lauriat: Notes this is a continuing conversation; we've been through option 8 previously

<Lauriat> https://docs.google.com/document/d/1BjH_9iEr_JL8d7sE7BoQckmkpaDksKZiH7Q-RdDide4/edit#heading=h.piv827yj658b

Lauriat: Notes that it works with option 7, really annotates 7

Lauriat: Bronze ...

<Chuck> Bronze

<Chuck> Guidelines that are not subjective with a margin of error provided through scoring (If a site with 500K pages can’t guarantee they won’t be missing heading markup on a few headings, or there is a lag in their cycle of checking user-added content, they still get officially credit; whereas, in WCAG this still existed but is handled more loosely and may encourage documentation/VPAT inaccuracies.)

<Chuck> Guidelines of the nature that previously were not included because of concerns about subjectivity with:

<Chuck> Required basic evidence, by guideline, of compliance that an individual could be expected to put together on their own

<Chuck> For example, for plain language: You might have a series of 3 drafts. You might have a statement as to why your plain language summary is sufficient

<Chuck> Additional care in the guideline design

<Chuck> Comparison during guideline design to existing Adjectivenal standards or requirements that are in legislation (I believe Bruce B mentioned he has some examples of this?) to ensure that these guidelines have the best chance possible

<Chuck> The WCAG 3 initiative should keep a record of the precedents used in helping to fine-tune these guidelines.

<Chuck> It is possible there should be a companion document that houses concerns and responses, so that anyone presenting on this down-the-road has the information on-hand (Presenter’s Companion to WCAG 3.0)

<Chuck> Would include plain language description of the Adjectivenal precedents used in helping to fine-tune these guidelines.

Jemma: Based on U.S. examples noted by Bruce

<Chuck> Would include plain language chart of likely arguments against subjective standards, and how to address these arguments

<Chuck> The WCAG 3 initiative should get permission now to publish quotations from representatives (particularly those less likely to support accessibility) who have advocated for better representation of the following: Low vision, Coga, Deaf/Blind

Jemma: Compare with what may already be in regs and subjective, but considered enforcable

<Jemma> s/jemma/suzanne

<sajkaj> s/jemma/Suzanne/

Bruce: Two examples not regulatory; relate to procurement review ratings

Bruce: the ratings tend to be adjectival

bruce: Also every Federal employee's annual review

bruce: note these are highly customized to the situation; unsure how to generalize from them

bruce: dhs (with Trusted Tester) is working on this

bruce: DHS is aspirational

Lauriat: Silver level ...

<Chuck> Silver

<Chuck> For Guidelines that are not subjective

<Chuck> Lower margins of error compared with Bronze [Limited to Specific Widgets, etc] Additional Testing is required but is limited to particular guidelines and particular content types (such as a JavaScript-based widgets)

<Chuck> User testing that shows efficacy* OR AT testing that shows efficacy* (unlike when WCAG 2 was finalized there is enough free AT and AT provided by operating systems to make this practical even for small enterprises)

<Chuck> * “that shows efficacy” means that, for example:

<Chuck> One round of testing that shows the product does not work well would not be enough to claim Silver.

<Chuck> One round of testing that shows the product does work well would be enough to claim Silver.

Lauriat: So, Silver shaped like Bronze, but with stricter levels

<Chuck> Several rounds of testing with remediation in between, so that the last round shows the product works well would be enough to claim Silver.

<Chuck> For Guidelines of the nature that previously were not included because of concerns about subjectivity:

jeanne: note this would apply across all guidelines because the civil rights requirement is that we need to cover all needs

<Chuck> [By Guideline] Required basic evidence of compliance by guideline such as:

<Chuck> User testing/Remediation/Re-testing report OR User testimonies OR WCAG 3.0 could provide other examples as well OR Organizations could use types of evidence that are not listed but that they consider equivalent

Jemma: Still trying to grok the big picture ...

Jemma: Would this put ARIA in only beginning at Silver; based on annotating javascript?

Lauriat: My understanding would not be a technology distinction, but a margin of error and type of testing evidence

Jemma: Asks about Silver sentence that mentions javascript

<Jemma> [Limited to Specific Widgets, etc] Additional Testing is required but is limited to particular guidelines and particular content types (such as a JavaScript-based widgets)

<JF> +1 WCAG needs to be agnostic to specific technologies

SuzanneTaylor: Great point -- shouldn't be anything limited to specific widgets

SuzanneTaylor: I was trying to respond to requirement for accessibility supported

SuzanneTaylor: you would need to test a js widget with at; else how do you know?

SuzanneTaylor: But, maybe this is misleading

SuzanneTaylor: maybe question is are we allowing at testing

<jennifer_strickland> That would be great to document, because it may explain why so many widgets are not accessible. I find the devs I've worked with need to see it in writing.

<JF> 'allowing" or "requiring"?

Lauriat: Gold Leve

<Chuck> Gold

<Chuck> [The overall product] For all Guidelines: Successful user testing OR User testimonies OR A published schedule of testing by people with disabilities and publicly-available issue triage

<Jemma> Thanks for the clarification, Suzanne. For subscring purpose, my two points for silver citeria 1) most of moden web use js based widget, 2)it would exclude ARIA spec which deals with rich web application.

jf: Wonders ov deltas in tolerance levels; is it a panel; what mix of pwd? etc

Lauriat: No sure I understand

jf: I could bring in anyone off the street ...

Lauriat: But that wouldn't be successful, would bew pretty clear

jf: Maybe; shouldn't we specify who the right users are?

Lauriat: Don't believe it's a problem

jf: Invokes Jamie Knight's "Now you know the experience of exactly one user with autism"

SuzanneTaylor: Suggest JF's be added issues to work through; to more clearly define goals

jf: Not just goals; expect we need to identify what users and what success looks like for them; blind vs motor

jeanne: Understood--We agree; let's move on. It's in issues to work through

<KimD> Option 10

<KimD> The key idea behind this is to write WCAG 3 into multiple recommendations, where different “types” of testing are separated into their own documents. These documents are closely connected in the same way that CSS 3 has multiple recommendations that are inter-connected. Each of these documents has a bronze, silver, and gold conformance level. This could be done (for example) like this:

Option #10

<KimD> WCAG 3: Outcomes: This document describes universally expected outcomes for accessible content. It is applied to individual views. This document contains what WCAG 3 currently refers to as “atomic” tests.

<Lauriat> Direct link to option 10: https://docs.google.com/document/d/1BjH_9iEr_JL8d7sE7BoQckmkpaDksKZiH7Q-RdDide4/edit#heading=h.p6rrzu9pyjtw

<KimD> WCAG 3: Usability: This document is scoped to processes and tasks. It outlines how to work with users, with personas, and with assistive technologies to discover and address accessibility needs specific for the process/task under test. This document contains what WCAG 3 currently refers to as “holistic” tests.

<KimD> WCAG 3: Sites & Apps: This document is scoped to collections of views, and transitions between them. This document allows testing based on sampling. Thresholds are built in, so that sites and apps can conform, even if not all views in the sample are fully conformant. This threshold is used to handle the “spoons” issue.

Wilco: Suggesting breaking wcag3 into three related docs

<KimD> WCAG 3: Organisation Maturity: This document describes quality assurance measures an organisation should have in place to ensure the accessibility of digital products and services.

wilco: based on split around responsibility; scoping things differently

<KimD> Each of these documents has its own Bronze, Silver and Gold conformance levels. Unlike WCAG 2.x, for WCAG 3 it should be far more common for both the lowest, and the highest conformance level to be used by organizations. The levels attempt to each strike a different balance between on the one hand the required knowledge and effort of the content provider, and on the other hand the experience of people with disabilities.

wilco: usability would be scoped on processes

wilco: site and apps doc that focusses on the overall

wilco: or even above for all organization web presences

wilco: that allows flexibility inconformance models

<KimD> The goal for the conformance levels should be as such:

<KimD> Bronze conformance: Ensure content is free of issues that is likely to block people with disabilities. This level focuses on making good decisions with commonly available tools. Bronze is achievable by content providers without experience with web technologies, and with limited to no budget. Amateur blogs, self-employed businesses, etc. This should also serve both as an entry-level to accessibility.

wilco: allows each to focus on a key area with cost benefit basis

<KimD> Silver conformance: Ensure a good experience for people with disabilities when common solutions are readily available, and an acceptable experience when they are not (such as through alternatives). Silver is achievable for content providers with a professional understanding of web technologies, commonly available tools and training materials and occasional access to a digital accessibility specialist.

wilco: Consider Bronze3 basically what one can do with off the shelf tooling

<KimD> Gold conformance: Ensure an excellent experience for people with disabilities. Gold will require extensive understanding of web technologies and digital accessibility, and will involve creating research-driven solutions tailored to primary and secondary demographics of the software. Gold conformance should be used in combination with silver conformance to achieve excellent accessibility for the most important areas of an organisation’s software, an[CUT]

<KimD> ...everything else.

wilco: this model would also support more mix and match

wilco: believe we should learn from failure of AAA adoption

wilco: This model would allow some portion of site to be Gold, while others are Silver

<Fazio> well articulated Wilco

<Zakim> jeanne, you wanted to talk different documents after Wilco is finished presenting

jeanne: Very interested in this

jeanne: we need to explore the details

jeanne: Recalls a multiple doc suite was part of one of the proposal at our design sprint some years ago

jeanne: Believe it was Lainey Feingold; different kinds of components; social; web; apps

<KimD> This is an intriguing proposal. +1 to more exploration into this

jeanne: Intrigued this is coming around again; could solve problems

jeanne: Noticing diff between Bronze and Silver; a different approach from before

<Fazio> FYI We've made a lot of progress on the Maturity Model and will present soon

Wilco: In writing this up I thought 3 levels was perhaps a little short of what we would want

wilco: Think we may need 4

wilco: but didn't want to overcomplicate for now, so stuck with 3; but we should be open to 4

Jemma: Concerned about inequality in what tooling produces

Jemma: What would a small establishment do? Could never get to Gold

Jemma: how to avoid the rich/poor gap

Lauriat: agree we need to be mindful of that

jeanne: agree

<Zakim> Lauriat, you wanted to say that scoring could express a lower level than bronze

Lauriat: Wanted to speak to one more level below Bronze; believe scoring could essentially provide that

Lauriat: Would still show how close; and would still show progress

jeanne: Concerned another lower level would encourage a race to the bottom

wilco: Believe there is reason to consider, though

wilco: Recalls moving from wcag1 to wcag2 stopped many smaller orgs because it became too expensive to keep up

wilco: that's unfortunate

wilco: a11y testing isn't cheap, and you can't claim conformance without it

wilco: Also, it's not quite enough for large orgs

<JF> and when we leave small orgs behind, we leave users behind too

wilco: So I have concerns at the low end and the high end

jeanne: suggests WCAG3 for small business

wilco: Cool idea

jeanne: suggests this could also address the desire for supporting component libraries

<JF> needs another definition. What constitutes "small business"? What about a school board's web site be considered?

<AngelaAccessForAll> That could address Jemma's point about rich/poor gap.

Fazio: Hopefully we can address the cost problem in the maturity model

Fazio: by including pwd through all aspects of org work

Fazio: good resources provided to pwd makes the baseline; and if you have pwd employed; then you've got testers while you go along ...

<Wilco> Costs a lot is relative. 2% on a 2 million budget is a lot of money. On a 1k budget, it's two pizzas

<Zakim> JF, you wanted to respond to David F

jf: Understand, concerned ideation discrepency

jf: the neighborhood wonk built the website over the weekend; we should also capture those

jf: Also, we're not just expecting to impact sites

Fazio: No, addressing this in maturity model as well

Fazio: Having the model to follow helps anyone who wants to be a11y

<Jemma> can we set up a fund to help with "the poor"?

Fazio: need to know who to go to to get this started; we point to those things

Jemma: hoping for help for small tooling

Option #11

<KimD> Option 11: Agency for Developers and Decision Makers

Lauriat: notes we can get started in last 5 minutes

<KimD> Definition of Agency as Used Here: The ability of organizations that wish to be accessible to act independently. Empowerment. The ability to accomplish things or make decisions by yourself without needing help.

Lauriat: agency for devs and site makers

<KimD> WCAG 3.0 Automated* Foundation (inspired by Github 451) [Agency comes through automation]

SuzanneTaylor: wrote it based on some github issues and borrowed from idea of profiles in Option 7

<KimD> WCAG 3 would define a set of outcomes that have these characteristics:

SuzanneTaylor: Idea is to give more agency to devs and decision makers

<KimD> Provide a high level of benefit

<KimD> Can be tested with an automated evaluation tool

SuzanneTaylor: would be things that are automated and important enough to be in a first level

<KimD> WCAG 3 would provide specific requirements for the set of tests that a tool must include to be used for this

<KimD> *Just because a tool can test for something does not mean it is part of this level.

SuzanneTaylor: 2nd level would be wcag3 full foundation

<KimD> WCAG 3.0 Full Foundation [Agency comes through automation + Q&A testing support]

SuzanneTaylor: also focussing on empowering devs

<KimD> WCAG 3 would define a set of outcomes/scores to create the following high-level outcomes:

SuzanneTaylor: either automation or q&a script

<KimD> Users are not blocked from accomplishing tasks - All user profiles considered equally

SuzanneTaylor: Thereafter, badges a la user proviles

SuzanneTaylor: no badge until first two levels met

<KimD> Friction and frustration caused by a mismatch between user needs and sites/products is reduced

<KimD> All user profiles considered equally Goal is to significantly reduce the likelihood of friction becoming a blocker or a competitive disadvantage Goal is not perfect usability and much usability would fall into the higher-level Badge categories

<Fazio> Credly Acclaim is expensive

<KimD> Each outcome/score required can be tested through either: An automated evaluation tool

<Fazio> Badgr is free though

<KimD> Detailed work would be needed to decide if everything here is part of the Automated Foundation or if anything else is added here. There may be Outcomes that are testable with a tool, but where the user impact is not quite severe enough to be in the very first level, and those might be placed here.

<KimD> Or a Question-and-Answer (Q&A) Script / Wizard WCAG 3 would provide the Clear Words script Vendors would be likely to create Wizards, and related / built-in tutorials, etc

<KimD> Badges (inspired by Github #466) [Agency comes through high level decision makers’ ability to choose a badge]

SuzanneTaylor: Suggests a memory care facility currently needs lots of expensive help to meet a11y; this would mediate

<KimD> Much like the badges used for on consumer food packaging (https://hamacher.com/so-many-certifications-non-gmo-project-certified-gluten-free-certified-vegan-usda-organic-and-ewg-verified/ )

<Fazio> There is an Open Badge Standard too

<KimD> Once you meet Full Foundation, you can start claiming badges Badges are the only “levels” that allow you to use public-facing W3C-Designed icons. Badges can be available for a variety of different types of accomplishments:

<KimD> Completing (or reaching a very high score for) all universally applicable outcomes for a user profile

<KimD> Completing just one previously-Level-AAA guideline that is not part of the universally applicable set

<KimD> Completing a type of testing or evaluation that the Accessibility/UX Field generally agrees is advisable For example, there could be a Badge for “Improved through User Testing”

jeanne: Suggest we pick up next week

<KimD> Anything else that is discovered through work on WCAG 3 that should be encouraged

Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).


Failed: s/jemma/suzanne

Failed: s/jemma/Suzanne/

Succeeded: s/rich app/rich web

Maybe present: Bruce