1 of 34

Developing WCAG 3.0

Jeanne Spellman

Slides: https://bit.ly/3kgOn82

2 of 34

What are W3C Accessibility Guidelines (WCAG) 3.0?

Next major version of the Web Content Accessibility Guidelines (WCAG) 2.2
Broader scope than WCAG 2.2 -- including digital publishing
Broader number of stakeholder groups
Guidance for more disability groups
Research informed and data driven
Moving the tradition of WCAG 2.0 forward
Starts from user needs of disability groups instead of technical solutions

W3C Accessibility Guidelines 3.0 are the next major version of the Web Content Accessibility Guidelines (WCAG) 2 series which is currently developing WCAG 2.2. WCAG 3 has a broader scope than the WCAG 2 series, which is why it required a new name. The scope includes W3C technologies beyond traditional web sites, such as digital publishing. It can include native mobile, applications and developing technologies such as virtual reality and Web of Things.

WCAG 3.0 serves a broader group of stakeholders and intends to include the needs of more disability groups. The project was started to be research informed and data driven, which has taken longer than we originally anticipated. Just as WCAG 2 improved the HTML-oriented checklists of WCAG 1 to be technology neutral success criteria, WCAG 3 is improving the success criteria of WCAG 2 to serve more disability groups and addressing needs of business, governments, and organizations.

3 of 34

Some Disclaimers

I do not represent the W3C. I am a volunteer on the WCAG3 project. I am retired and work on this project on my own time.
The existing WCAG 2 series is great!
If you are starting work on accessibility in your organization, use WCAG 2.
WCAG 3.0 is under development and is not finished and is not ready for use
Anything in the WCAG3 draft today is not ready for implementation. We have difficult structural problems to solve.

Some Disclaimers

I do not represent the W3C. I am a volunteer on the WCAG3 project. I am retired and work on this project on my own time.
The existing WCAG 2 series is great! WCAG 2.0 has had a tremendous impact with advancing the cause for accessibility of the web
If you are starting work on accessibility in your organization, use WCAG 2.
WCAG 3.0 is under development and is not finished and is not ready for use. It won’t be finished for years, probably three years.
Anything in the WCAG3 draft today is not ready for implementation. The accessibility advice included is being used to test the structure and process.
No matter what people on social media say, there is nothing in the current WCAG3 drafts that anyone should make accessibility implementation plans around today. It is all still exploratory as we try to find solutions to difficult problems. Maybe in a year.

4 of 34

Agenda

WCAG 3.0 Approach
Proposed for WCAG 3.0
What’s the latest?
Differences between WCAG 2.0 and proposed WCAG 3.0 approaches
How to Contribute

5 of 34

Difficulties with Current Approach

Who is the audience?

Developers? Management? End-Users? Regulators?

Accessibility is a continuum

Standards compliance tends to binary

yes/no — true/false — pass/fail

Testing and evaluation can be ambiguous

Different SME can reach different conclusions
Subject matter seems to have steep learning curve

A, AA, AAA structure

Most legal requirements combine A and AA
Why clutter the baseline requirement (A and AA) with advisory best practices (AAA)?
Why a requirement is at A or AA is not obvious (in many cases)
A, AA, AAA approach resulted in more A and AA for people with some disabilities than other disabilities

There are difficulties with the current approach of WCAG 2 series that were identified during the research phase of the WCAG3 project.

We started with a study of “Who is the audience”? WCAG2 is primarily written for developers and regulators

WCAG3 wants to have a broader audience that includes many stakeholders

Another difficulty is that we know accessibility is a continuum, but WCAG2 standards compliance tends toward a binary yes/no, true/false, pass/fail.

In WCAG3, we want a graded approach that informs site and product owners of how accessible their site or product is.

Testing and evaluation can be ambiguous. Different testers can reach different conclusions.

We want to have WCAG3 reduce ambiguity and improve the onboard process for new people learning about accessibility.

The A, AA, and AAA structure of WCAG2 has a number of issues

Most legal requirements combine A and AA
Why clutter the baseline requirement (A and AA) with advisory best practices (AAA)?
Some of the feedback that W3C has received about WCAG2 is that it is not obvious why a certain success criterion is an A and others AA.

In our research interviews with lawyers specializing in accessibility, several mentioned that judges sometimes wanted to know why a success criterion had a certain level. There is no explanation for why the success criteria were assigned to a certain level
When we in the WCAG3 project look at the unintended consequences of using the A, AA, AAA approach, we see that the levels are not evenly distributed through different disability categories. There are more success criteria at A and AA that benefit people with severe vision impairments. This is understandable, because the need is great. But overall, we see that people with hearing or cognitive disabilities are more likely to find their needs categorized as AAA - optional. Once we realized this, we knew we had to address it, and it would have to take a new major version of the accessibility guidelines.

6 of 34

WCAG 3.0 Approach

7 of 34

WCAG 3.0 Stakeholders

WCAG 2.0 did not develop a stakeholder list, but is primarily oriented for developers, testers and regulators
As a first step, the group developing WCAG 3.0 (code named “Silver”) identified 31 stakeholder groups that used accessibility standards.
They wrote usability-oriented “job stories” of how each stakeholder group used accessibility standards.

8 of 34

Research Completed

WCAG Use by UX Professionals (survey)
WCAG Success Criteria Usability Study (survey)
Internet of Things Accessibility (survey & interviews)
Interviews on Conformance
Interviews on Legacy of WCAG 2.0 Creation
Feedback from Reimagining Accessibility Guidelines Presentations
Web Accessibility Perceptions
Student research on Silver research questions (9 papers)

With the stakeholder job stories complete, we next wanted research to help guide the development of a new version of the accessibility guidelines. The project team made a list of questions that we wanted research to answer. A number of academic and corporate researchers volunteered to help us answer the questions. Some of the studies that resulted were:

WCAG Use by UX Professionals which was a survey on the usability of WCAG2 that formed a lot of our early thinking about gaps we wanted to address.
WCAG Success Criteria Usability Study (survey on the how easy each of the existing WCAG 2.0 success criteria was to learn, use, and teach)
Internet of Things Accessibility which was a survey & interviews on feasibility and importance of including Internet of Things in accessibility guidelines
Interviews on Conformance from representatives of legal and policymaker from US and internationally on how well the WCAG 2.0 structure worked.
Interviews on Legacy of WCAG 2.0 Creation that is, how the claim of what passes and what doesn’t was decided and how the structure of A, AA, and AAA were developed and the design decisions that were made.
Feedback from Reimagining Accessibility Guidelines Presentations - these were large group presentations and feedback - A11yTO was one of our feedback groups
Web Accessibility Perceptions was an honors group university project on how developers learn about accessibility.
Student research on Silver research questions from Scotland which the best 9 papers were given to the Silver project. They were small group studies and were not used to make decisions, but they were well done and interesting.

Not all the original research is publicly available. The Research Archive link in the speaker notes links to the research documents that are available.

9 of 34

Analysis: Structural Problem Statements

Usability

Too Difficult to Read (and translate)
Difficult to get started
Ambiguity in interpreting the success criteria
Persuading Others

Conformance Model

Strictly Testable Constraints
Human Testable
Accessibility Supported
Evolving Technology

Maintenance

Flexibility
Scaling
Governance

The research that was complete before the Silver Design Sprint was used to develop a list of Problem Statements. These problem statements were constrained to structure and not the actual guidelines. The problem statements were grouped into 3 areas: usability, conformance, and maintenance. Within each, we prioritized:

Usability

Too Difficult to Read (and translate)
Difficult to get started
Ambiguity in interpreting the success criteria
Hard to Persuade Others to implement accessibility guidelines

Conformance Model

Strictly Testable Constraints limited the disability needs that could be addressed.
Human Testable - the amount of manual testing required makes it very difficult for large complex sites to claim conformance
Accessibility Supported concept wasn’t well known or understood and was often misinterpreted to ignore standards a make a page worked for a particular screenreader.
It was difficult to apply the WCAG2 standards to new Evolving Technology

Maintenance

Flexibility - Strict document structure, workflow and approval processes can sometimes ensure efficiencies and predictable outcomes. However, they may also stifle innovation and inclusion. It takes too long to update accessibility standards.
Adding new guidelines becomes difficult to scale
Governance problem of getting the developing needs of disability groups encountering barriers from new technology take too long to be included in standards.

10 of 34

Kicking off the Solutions: Silver Design Sprint

27 Industry leaders representing parts of the accessibility community: CEOs, consultants, UX professionals, developers, legal, policy, and more
Participants came from the US, Canada, UK, Spain, India, Japan, Australia
An experienced Agile sprint leader guided participants to find solutions to the Problem Statements
People worked in 5 groups of 5-6 people for 2 days in San Diego, CA

We took these problems that we didn’t know how to solve, and invited 27 industry leaders representing our stakeholder groups to a 2 day brainstorming session. They included: CEOs, consultants, UX professionals, developers, legal, policy, and more. We tried to include every one of the 31 stakeholder groups. Over one third of the participants disclosed that they had a disability. They came from all over the world: US, Canada, UK, Spain, India, Japan and Australia. An experienced Agile sprint leader guided participants to find solutions to the Problem Statements. People worked in 5 groups of 5-6 people for 2 days in San Diego, CA just before the 2018 CSUN conference in San Diego, California.

https://www.w3.org/community/silver/draft-final-report-of-silver/

https://www.w3.org/community/silver/2018/04/23/suggestions-of-silver-design-sprint/

11 of 34

Suggestions

From the Silver Design Sprint

Draft Final Report of the Silver Design Sprint

12 of 34

Suggestions�1/3

Usability

Simple language
Filtering – “database all the things” to target info
Easier to find info
Find info by role, by problem, by disability, and by platform
Provide a starting point for beginners

13 of 34

Suggestions�2/3

Conformance

From Pass/Fail tests to also include other forms of measurement
Rubric for testing task accomplishment
Point and ranking system
Accommodate dynamic or frequently updated content

14 of 34

Suggestions�3/3

Maintenance

Allow experts to contribute code, tests, design patterns
Improve spec tools to allow more people with disabilities to contribute
Allow more public participation

15 of 34

Silver Requirements

Design Principles
Requirements

16 of 34

Design Principles

Accessibility guidelines:

Wider range of people with disabilities
New measurement and conformance structure
Include emerging technologies.
Follow our own accessibility guidance
Be written in plain language

Guidelines process:

Include people with disabilities
Facilitate global participation and feedback
Data-informed and evidence-based

17 of 34

Requirements

Multiple ways to measure
Flexible structure
Multiple ways to display
Technology Neutral
Attention to Readability and Usability
Suitable for Regulatory Environment
Motivation to do more than minimum
Scoped for a diverse group of stakeholders

Requirements are measurable and we will need to show W3C management (and the world) that the requirements have been met before we can finalize WCAG 3.0.

3.1 Multiple ways to measure

Different guidance has potential for different measurement beyond a simple true false success criterion so that more needs of people with disabilities can be included.

3.2 Flexible structure

Create a structure for guidelines that can better meet the needs of people in unanticipated technologies and interactions.

3.3 Multiple ways to display

Make the guidelines available in different accessible and usable ways so the guidance can be customized by and for different audiences.

3.4 Technology Neutral

Core Guidelines are worded to apply across varied technologies and avoid being technology-specific. The intent of technology-neutral wording is to provide the opportunity to apply guidelines to current and emerging technology, even if the technical advice doesn't yet exist. Technical details are discoverable in the document structure but are not required to understand guidelines.

3.5 Readability/Usability

The guidelines are understandable by non-technical audience. Text and presentation are usable and understandable through the use of simple language, structure and design.

3.6 Regulatory Environment

The Guidelines provide broad support, including

Structure, methodology, and content that facilitates adoption into law, regulation, or policy, and
clear intent and transparency as to purpose and goals, to assist when there are questions or controversy.

3.7 Motivation

The use of the guidelines supports and motivates organizations to acknowledge gaps and strive to be more inclusive. The intent is to give organizations a path toward greater accessibility.

3.8 Scope

The guidelines provide guidance for content, authoring tools, user agents and browsers, and assistive technologies.

18 of 34

Proposed for WCAG 3.0

19 of 34

Improving equity between different disability groups

Developing a more comprehensive list of functional needs of disability groups

WCAG 3.0 currently references a list of 50+ disability categories

Example: WCAG 3.0 has a more granular inclusion of different cognitive disabilities

Developing guidelines starting with an evaluation of user needs

Instead of starting with the technical solutions
WCAG 3.0 identifies conflicting user needs

Example: high contrast is a barrier for some cognitive disabilities and visual impairments

Testing any scoring proposal with the impact on different disability groups

WCAG 3.0 has a group focused on testing and evaluating the different proposals

An ongoing challenge is to improve the equity between categories of different disability groups so we don’t have the unintended consequence of making it harder for some disability groups to get their needs addressed. This is a moving target and we are actively working on three different ways of leveling the playing field of different disability groups that may have been underserved.

First is expanding a list of functional needs which is more comprehensive, including a more granular inclusion of different types cognitive disabilities than the functional performance criteria generally used in the US and Europe. For example, Section 508 includes nine “Functional Performance Criteria”

WCAG 3.0 currently references a list of 50+ disability categories including categories that have not been addressed before and multiple disability combinations. Main Functional & User Needs early draft

Second, instead of developing guidelines based on expert technical solutions, we start out development work on each guideline by evaluating the user needs. We also identify conflicting user needs, such as High contrast is needed for some visual disabilities, but high contrast is also a barrier for some cognitive disabilities and visual impairments

Third, we have a group of testers who evaluate all structural conformance proposals to test the impact on different disability groups.

20 of 34

Addressing Usability

Simple Language

Database – (still to be designed) with filtering and sorting by tags

How-To for each guideline with information for beginners and project team members

21 of 34

How-to Example

Get started
Plan
Design
Develop
Examples
Resources

22 of 34

Structure for the WCAG 3.0

Guidelines: high-level, plain-language version of the content for managers, policy makers, individuals who are new to accessibility

How-To sections describe the guideline

Outcomes: testable criteria that include information on how to score the outcome in an optional Conformance Claim

Outcomes are technology neutral

Methods: detailed information on how to meet the outcome, code samples, working examples, resources, as well as information about testing and scoring the method

Methods are technology specific

WCAG 2.0 is organized by Principle, Guidelines, Success Criteria, and Techniques. WCAG 3.0 is currently organized by Guidelines, Outcomes and Methods.

Guidelines: high-level, plain-language version of the content for managers, policy makers, individuals who are new to accessibility. How-To sections describe the guideline.
Outcomes: testable criteria that include information on how to score the outcome in an optional Conformance Claim.
Methods: detailed information on how to meet the outcome, code samples, working examples, resources, as well as information about testing and scoring the method.

Highest level: Guidelines

WCAG 3.0 guidelines organize the requirements and convey general expectation

Example: Headings Organize Content

Middle level: Outcomes

Outcomes are the core requirements in WCAG 3.0
Outcomes are technology neutral and are testable statements
Examples:

Present text in an appropriate natural language for assistive technologies.

Lowest (most detailed) level: Methods

Methods are specific to the technology
HTML examples (paraphrased, and simplified)

Alternative text for Images of Text

23 of 34

Proposed Conformance Approach

Point Scoring System
Option for adjectival ratings instead of only true false success criteria
Evaluating severity in context -- minor errors don’t fail, but critical errors do.

24 of 34

Critical Errors

A critical error is an an accessibility problem that will stop a user from being able to complete a process (or task).
Critical errors include:

Items that will stop a user from being able to complete the task if it exists anywhere on the view (examples: flashing, keyboard trap, audio with no pause)
Errors that when located within a process means the process cannot be completed (example: a submit button that is not in the keyboard tab order)
Errors that when aggregated within a view or across a process cause failure (example: a large amount of confusing, ambiguous language)

There were two big problems with A, AA, and AAA. First and most important, is that it introduced a structural bias where certain disability types were more likely to have success criteria in the A, where others were more served by AAA. Since AAA was optional from a regulatory viewpoint, it meant that disability needs were not being addressed in a balanced way. Second, by permanently assigning a level to a guideline it overlooked the context of how the guideline was being used. In order to address the equity and the context in which the guideline is being used, we are trying out the idea of critical errors.

A critical error is an accessibility issue that will stop a user from being able to complete a process or task. Critical errors include:

Items that will stop a user from being able to complete the task if it exists anywhere on the view (examples: flashing, keyboard trap, audio with no pause);
Errors that when located within a process means the process cannot be completed (example: submit button not in tab order);
Errors that when aggregated within a view or across a process cause failure (example: a large amount of confusing, ambiguous language).

We expect to add more types of critical errors as we develop more guidelines. What it gives us is flexibility to prioritize types of errors while addressing the inadvertent structural bias of WCAG 2.

Again, I want to emphasize that even though I like idea, this may change and may not be a part of the final guidelines. We appreciate your feedback about these ideas.

25 of 34

Bronze Silver Gold

Bronze Silver Gold translates better than A, AA, AAA

Bronze Silver Gold refers to the overall product, not individual guidelines

There are several approaches being proposed:

Currently:

Bronze is generally WCAG2 AA equivalent. Required for higher levels
Silver is usability or a new idea - best practices (Protocols)
Gold is Maturity Model - organization best practices

Another proposal:

Bronze Silver Gold are just cutoffs on the score - for example: 80%-89% is bronze, 90%-95% is Silver, and 96% and higher is Gold level.
No final decisions have been made. There may be more proposals.

A more complex scoring system could result in better improvements for people with disabilities without putting a regulatory burden on organizations trying to make their products accessible.

There is a lot of confusion about Bronze Silver Gold and multiple proposals to address different aspects.

Most people like changing to Bronze Silver Gold because it translates more effectively than A AA AAA, especially for languages that don’t use the latin alphabet.
Unlike A, AA, and AAA - Bronze Silver Gold refers to the product as a whole, not individual guidelines.
In the current working draft:

Bronze is the guideline and outcome level. It is broadly equivalent to WCAG 2 AA -- although there will be changes. It will be required to meet Bronze level to go to higher levels.
Silver level is for usability. We are exploring changing usability to asserting that you are following certain best practices or protocols. It is NOT meant to be used for regulations. It’s a new idea and we are working on a protocols proposal for a 2022 draft.
Gold is for Maturity Model. Maturity Model is best practices for the entire organization to support WCAG

Alternatively, some people propose that Bronze Silver Gold are just cutoffs on the score - such as 80%-89% is bronze, 90%-95% is Silver, and 96% and higher is Gold level. It is more simple, but it doesn’t improve accessibility for people with disabilities. I think a more complex scoring system could result in better improvements for people with disabilities without putting a regulatory burden on organizations trying to make their products accessible.

26 of 34

Where’s the latest?

27 of 34

New Proposals in Q3 2021

Revised Methods template to reduce ambiguity

New proposal for User Generated Content

New Explainer document

Error Prevention guideline

New Methods for Text Alternatives

New Proposals from Third Quarter of 2021:

While we haven’t worked on the scoring yet, we have been working on structural issues that need to be solved. In many ways, the point scoring comes last after we have worked out the difficult problems.

First, we received a dozen or so comments that the testing was too ambiguous. That isn’t surprising, because we hadn’t worked on testing yet, just sketching it in so people could get an idea of how it could work. In Q2 and Q3 we worked with the Accessibility Conformance Testing Task Force to bring our proposals inline with the ACT Rules with the goal of reducing ambiguity in testing.

The Silver research identified User Generated Content as a big hole in WCAG2. You can claim partial conformance -- which is just a way of saying skip this part. Web sites didn’t have to do anything other than say it didn’t conform, and many did just that. Unfortunately, that was an invitation for lawsuits and many companies and organizations that are trying to provide good accessibility couldn’t claim conformance regardless of what they did. This new proposal encourages companies to make the best effort to provide the tools for users to generate accessible content and make the content as accessible as possible without failing them for what an individual user does or doesn’t do.

Many people commented that all the explanation sections in WCAG3 made it hard to find the guidelines. It was a good point. We have moved the explanations to a separate Explainer document.

WCAG3 is using a new approach to developing the guidelines. We start from user needs, then identify desired outcomes and methods for achieving them. Error prevention guideline is a migration from WCAG 2 success criterion using this process. It may not be in the working draft, but it is in the Editor’s draft, and I encourage you to read and comment on it.

The group working on Text Alternatives has developed more methods. They are currently in the Editor’s draft.

28 of 34

What’s Next?

Revise outcomes to reduce ambiguity
Determine the granularity of outcomes and outline how many there will be
Protocols - giving bonus credit for implementing other standards
Revising Paths and Processes
Scoring
Maturity Model
Error Notification guideline
Third Party Media Content
Updated formulas for visual contrast of text

29 of 34

Differences between WCAG 2.0 and proposed WCAG 3.0 approaches

30 of 34

True/False vs. Adjective ratings

WCAG 2.0

Clear measurement of what is passes or fails
Fits traditional regulatory model

WCAG 3.0

Allows inclusion of more guidance that helps more disability groups
Accessibility is rarely binary true false – accessibility generally is a continuum
Often accessibility features for one disability category can be a barrier for another category – different groups can benefit from different ratings
User need driven

31 of 34

100% Pass Fail vs Point Scoring

WCAG 2.0

Page-based conformance model

Websites (i.e., a collection of pages) is passes at 100%, or it fails
100% conformance is rarely realistic

Large dynamic sites cannot claim conformance, even if they have good accessibility

WCAG 3.0

Point scoring gives a more nuanced view of the accessibility of a site or product
Helps businesses to realistically claim accessibility, even if there are minor issues
Recognizes that all software has bugs, while encouraging owners to prioritize accessibility issues over other defects

100% Pass / Fail vs Point Scoring

One of the themes that came up in the research phase of WCAG3 is that in WCAG2, you either pass at 100% perfection or you fail. There are no nuances, there is nothing in between. 100% conformance is rarely realistic, especially for large dynamic sites. So a large site with good accessibility cannot claim conformance, even if they have good accessibility.

IF (and there is not consensus in the working group) WCAG3 uses a point scoring system, this will allow a more nuanced view of the accessibility of the site or product and gives regulators more flexibility. For example, today, if any image is missing alt text, it fails. We think that if the most of the images have an accessible name, and the image that doesn’t isn’t critical to performing a task, it should pass. So any site that has 80% (that’s a number I made up) of the images with an accessible name is a good site and should pass. If it has 95% of the images, that’s excellent. We are working on how to capture this concept. We have a lot of disagreement right now, but hope to have it settled in 1st quarter of 2022.

We want businesses to realistically claim accessibility even if there are minor issues.

We recognize that all software has bugs. We want to encourage owners of web sites and digital products to prioritize accessibility bugs as they do other software defects.

32 of 34

Precision vs Plain Language

WCAG 2.0

Precise wording of success criteria
Can be difficult to interpret or learn
Has some ambiguity and has some inconsistent interpretation

WCAG 3.0

Written in plain language where possible, and uses simple language summaries where technical language is needed
Develops tests early in the guideline development cycle so ambiguity can be identified and corrected before the guideline is finalized
Uses longer descriptions and bullet lists to describe edge cases and exemptions, instead of trying to fit requirements into one statement

Precision vs Plain Language

WCAG2 attempts to have precise wording of success criteria that includes all known edge cases. This results in language that is difficult to interpret and learn, even for native English speakers. Judges in US courts have complained to W3C that the success criteria are difficult to understand and interpret. It still has some ambiguity and inconsistent interpretation.

WCAG3 strives to be written in plain language where possible and uses simple language summaries. WCAG3 process develops tests early in the guideline development cycle so ambiguity can be identified and corrected before the guideline is finalizes. It uses longer descriptions and bullet lists to describe edge cases and exemptions instead of trying to fit requirements into one statement.

Side note on WCAG3 ambiguity: The First Public Working Draft was focused on structure and the guidelines were just sketched in to illustrate the structure. That was a mistake, because many of the comments we received were that the guidelines were too ambiguous. We are working on improving that in future drafts.

33 of 34

How to Contribute

34 of 34

How to contribute to WCAG 3.0

Review

Review the W3C WCAG 3 landing page: www.w3.org/wai/wcag3
Provide email or Github feedback

Join the discussion

Join the Silver Community Group

www.w3.org/community/silver
Start a Korean group working on an issue

Join the Accessibility Guidelines Working Group (AG WG)

Requires being affiliated with W3C member organization or Invited Expert status
www.w3.org/groups/wg/ag

Contact Jeanne Spellman

jspellman@spellmanconsulting.com, @jspellman on twitter and github, or LinkedIn

We would love your help!

Please review and comment on our documents. Start at the WCAG 3 introduction page at www.w3.org/wai/wcag3

Join the Silver Community Group. You can search for the W3C Silver Community Group. Our meetings run subtitles and a transcript. Our email and surveys can be answered at your convenience.

We have small groups forming to work on new guidelines and conformance issues. You could form a small Korean group working on an issue of particular importance to Koreans.

See the Sub Groups listed on the wiki:

www.w3.org/WAI/GL/task-forces/silver/wiki (case sensitive)

You can also join the Accessibility Guidelines Working Group, which requires being affiliated with a W3C Member organization or to have Invited Expert status. You can find more information at www.w3.org/groups/wg/ag.

You can also contact me directly by email at jspellman@spellmanconsulting.com, @jspellman on twitter and github, or LinkedIn