Publishing@W3C: September 2021 Seminar

I'm Jeanne Spellman and I co-lead the task force developing the proposals for WCAG 3.0 as part of the Accessibility Guidelines Working Group.

I worked on the Authoring Tool Accessibility Guidelines 2.0, User Agent Accessibility Guidelines 2.0, and how WCAG 2.0 applies to mobile as a W3C staff member.

And I am currently retired and sponsored by W3C member TetraLogical.

I'm talking to you very briefly today about developing the W3C Accessibility Guidelines 3.0.

The 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 websites, such as digital publishing.

It could include native mobile, applications, and developing technologies such as virtual reality and the 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 checklist 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 the needs of businesses, governments, and organizations.

In 2017 the Silver Task Force, a project to develop WCAG 3, started by identifying 31 stakeholder groups and writing jobs stories for them.

We formed the Silver Community Group so we could involve more people with disabilities, more stakeholder groups, and short term expertise.

We developed a list of research questions then spent 18 months partnering with academic and corporate researchers to seek answers and identify problems we wanted to address.

We held a two-day agile facilitated design sprint in 2018, where 27 industry leaders from our stakeholder groups met to suggest solutions to difficult problems that we identified in the research.

We then spent two and a half years developing and refining a requirements document, and building and testing prototypes.

We published our First Public Working Draft in January '21 and are publishing updated Working Drafts quarterly.

We published an update in June and are planning updates in September and December.

What are we currently proposing?

One issue we felt impelled to address is the equity between different disability groups.

There are many WCAG 2 success criteria for people who are visually impaired, but less than 10 success criteria for people with hearing disabilities.

There are disability groups that are not experiencing barriers with the technology of 2008, which is when WCAG 2 was originally published, that are today, for example people with speech disabilities, are encountering barriers that didn't exist before virtual assistants became ubiquitous.

To help us identify new barriers, we have a group working on expanding the list of functional needs.

We have currently identified 50 plus categories, many of which have not been addressed by accessibility guidelines in the past.

Our guideline development process starts with these functional categories and uses them to identify specific user needs for each topic.

The research also identified needs for the improved usability for the guidelines.

Stakeholders want simple, non-technical language and the ability to engage beginners in the accessibility development process as well as other members of the teams developing new products and content that have rarely been addressed with accessibility standards.

Each guideline we are proposing has a How To document with Get Started information as well as information for editors, designers, developers, testers, and the project managers who need to ensure they all work together to provide good accessibility.

Our research also identified needs of businesses, governments, and organizations to have a more nuanced evaluation of their own accessibility.

We've recognized that making it possible for more sites and products to meet WCAG 3 will improve accessibility for people with disabilities, not by making WCAG 3 easier to meet, but by acknowledging companies that are trying to do a good job with accessibility and removing the structural barriers that made it difficult to meet WCAG 2.

There are many differences between the WCAG 3 proposal and the WCAG 2 series.

So here are some of the most important.

WCAG 2 uses true/false success criteria.

This makes it difficult to add new guidance for disability needs that are more challenging to measure, as well as guidelines for industries like digital publishing that want to add guidelines that don't fit neatly into the success criteria.

We want to address this by creating plain language outcomes with unambiguous adjective ratings.

Unambiguous is hard; I'll get to that in a minute.

We are still working on refining this proposal.

Secondly, WCAG 2 is 100% pass or completely fail.

When a dynamic social website updates thousands of times per second, they cannot meet WCAG 2 as it is currently structured.

The point system we propose has a score to help sites or products know where they are on a spectrum of accessibility.

We also want to make it possible for some guidelines to have a small percentage of non-critical bugs and still pass.

This makes it possible for large, dynamic, and social media sites to claim to meet WCAG 3 when they have good accessibility.

We are looking at plain language versus the precision of language.

As one of the Accessibility Guidelines Working Group chairs frequently says, we can have standards that are concise, precise, or easy to understand, pick any two.

We are currently working on an approach that I hope you will see in the third quarter draft that will be precise and easy to understand.

We're planning to put the precise language in an accordion or tab so it won't be overwhelming and long to read for most of our stakeholders.

The developers of accessibility testing tools and a few other stakeholder groups need very precise language.

We're working on giving them precision without sacrificing plain language.

Stay tuned, thanks for listening.