Silver Minutes from 9 April

Minutes from the Silver Task Force and Community Group teleconference of
Friday 9 April are provided here.

===========================================================
SUMMARY:
*            Reminder to block Thursday 9 April for 3 two-hour virtual Face to Face
              calls on conformance.
*            Status updates on updates to style guide
*            Continued discussion of Bronze/Silver/Gold options
===========================================================

Hypertext minutes available at:
https://www.w3.org/2021/04/09-silver-minutes.html

===========================================================
   W3C

                                                                                                            - DRAFT -
                                                                                               Silver Task Force & Community Group

09 April 2021
   IRC log.

Attendees

   Present
          AngelaAccessForAll, Azlan, ChrisLoiselle, Fazio, jeanne, Jemma, jennifer_strickland, JF, johnkirkwood, KimD, Laura_Carlson, Lauriat, MichaelC, sajkaj, SuzanneTaylor, Wilco

   Regrets
          Charles, Francis, Sarah, Todd

   Chair
          jeanne, Shawn

   Scribe
          sajkaj

Contents

    1. reminder of meeting with AGWG on 29 April 2021
    2. updates to the Style Guide for people interested in participating
    3. Bronze Silver Gold options
    4. Option #10
    5. Option #11

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--

   [crickets]

   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).

Diagnostics

   Failed: s/jemma/suzanne

   Failed: s/jemma/Suzanne/

   Succeeded: s/rich app/rich web

   Maybe present: Bruce



----------------------------------

Janina Sajka
Accessibility Standards Consultant
sajkaj@amazon.com<mailto:sajkaj@amazon.com>