Overview

Plain Language

Adding Plain-Language Standards to the WCAG 3

Summary | We are part of a group that creates guidelines to make online content accessible to people with disabilities. We are working to add plain language rules to these guidelines, which are used by many countries around the world. Our work is not just about making text easier to read. We want to help people find, understand, and use information, applications, and web content.

An Interview with Julie Rawe and Lisa Seeman-Horwitz

Impact spoke with Julie Rawe and Lisa Seeman-Horwitz, co-facilitators of the Cognitive and Learning Disabilities (COGA) Task Force for the World Wide Web Consortium (W3C), a nonprofit organization whose members and staff work together with the public to develop global web standards. Rawe and Seeman-Horwitz are working to include plain-language standards in the next version of W3C Accessibility Guidelines (WCAG) 3. The following is an edited excerpt of their conversations with Janet Stewart, Impact managing editor. Rawe and Seeman-Horwitz noted at the outset that they were sharing their own opinions and not speaking for the entire task force or the W3C.

Lisa, you’ve been involved with this work since shortly after the first WCAG version was published, more than 25 years ago. How did this interest begin for you?

Seeman-Horwitz: I’ve been working in web accessibility and digital inclusion for a long time. For example, I drafted the first versions of ARIA (which stands for Accessible Rich Internet Applications). This is a base accessibility layer that makes dynamic web content accessible to people with disabilities, including those who use screen readers. In the early 2000s, I was making some online tools for people with ADHD and dyslexia, and a learning platform called StudyWeb wrote to me and asked how they could make homework materials more accessible to these students. I thought it was an interesting question. WCAG 1.0 had just come out, so I contacted the WCAG working group. They said they had just received some criticism that the guidelines didn’t have a broader scope, and would I like to come and give a position paper at their next workshop? So, I got involved and spent the next couple of years working on proposals for WCAG 2.0, although they were typically defeated in the consensus process.

A drawing features two speech bubbles meant to convey the plain-language process. The first shows a tangled bunch of scribbled lines, while the other has concentric blue circles in a neat stack.

After WCAG 2.0 was published, we formed COGA, a task force that focuses on cognitive and learning disabilities, to help the W3C address these topics. We researched different user groups and moved from focusing on the names of disabilities to looking at functional needs and functional impairments, like memory impairment. We also looked at web topics such as login authentication, personalization, and safety in the context of cognitive and learning disabilities. This background research and analysis were then used to form our guidance for web content creators.

Julie, how did you get involved with the COGA task force?

Rawe: In 2014, I was part of the team that launched Understood.org, which creates free resources for kids and adults with learning and thinking differences, like ADHD and dyslexia. Our content and product teams work really hard to make our resources engaging but not distracting. We work hard to make our information and interventions easy to understand. Some of the ways we do this include keeping paragraphs short, providing clear section headers, and choosing conversational words like “use” instead of “utilize.”

I got involved with the COGA task force as it was preparing to publish a resource called Making Content Usable for People with Cognitive and Learning Disabilities (https://www.w3.org/TR/coga-usable/). We’re now updating that resource, which was originally published in 2021. We’re adding more mental health to the scope of this document. We’re also changing the format to make it easier to skim and adding more illustrations to help developers and designers understand what to do and what not to do. The next version is going to be much more user-friendly, which is exciting.

So, how will this inform the plain-language standards in WCAG 3?

Rawe: Making Content Usable has a big section on how to make content clear and understandable. We’re working on getting a lot of this information into WCAG 3, in a section called “Clear Language.” Overall, WCAG 3 is trying to expand to meet the needs of more users, including people who need more cognitive accessibility support and people with low vision. They are two of the core groups for whom WCAG 2 didn’t really advance things. WCAG 3 is trying to do a better job of meeting those users’ needs.

The scope of Making Content Usable and WCAG 3 goes way beyond things like word choice and sentence structure. For example, think about the design elements that help users understand what things are and how to use them. As a user, you may find yourself wondering, “Is this a button I’m supposed to press, and do I know where it’s going to take me?” From a cognitive perspective, if you select a button and it sends you somewhere you didn’t want to go, it can be very disorienting. Another problem area: websites are often designed in ways that make it hard to find what you need. We also need to do a better job of helping users avoid making mistakes and making sure our processes don’t rely heavily on user memory.

Because of my work with the COGA task force and with Understood, I was asked to be a WCAG 3 editor, leading the team that is focused on text and wording. There is a lot of detail on this in the 2021 COGA resource that we’re trying to get incorporated into WCAG 3, but it’s a challenge on several fronts. Testability is a big issue. Earlier WCAG versions were set up such that you have a test and the answer is yes or no, with no gray area. That can be hard to do with some aspects of language.

But for the first time, WCAG 3 is going to allow assertions in addition to requirements. If we can’t make something objectively and reliably testable, we can make it an assertion. For example, “I publicly assert that my organization trains its content creators to make paragraphs short and to use clear section headers.”

Seeman-Horwitz: It’s a new approach that’s worth trying.

What are the key things still left undone that we need to address?

Rawe: We’re also trying to make the guidelines work internationally, for different languages. For the initial publication of WCAG 3, we’re planning to test the guidelines in five languages: English, Arabic, Hindi, Mandarin, and Russian. How did we pick these five? We started with the six official languages of the United Nations (UN). Then we removed French and Spanish because they’re similar to English, and we added Hindi because it’s the most commonly spoken language that is not on the UN list. This group of five languages includes a wide variety of language features, including right-to-left text layout, vertical text layout, and tonal sounds that affect meaning. This list doesn’t include every language, but it helps keep the work manageable while making the guidance more useful for a wide audience.

Seeman-Horwitz: We need to acknowledge that the web has changed since we first began this work. One of COGA’s new research publications (www.w3.org/TR/coga-research-modules) talks about safety, including in artificial intelligence. The algorithms are often not good for people with mental health concerns. For example, aggravating an obsession. One solution is putting the right user needs into the design phase and using a broader user base for research groups and testing.

Part of the problem is people with different disabilities are often left out of the data because they’re not using the technology that is not accessible for them. So their actions are not in the data. They are then not in the analysis that is based on data collected from apps that they can not use. The result is that they are being marginalized. Another example: there are user surveys, but many people will find them inaccessible or hard to fill out. So, they become invisible. I think a good analysis of who’s missing from your data is critical.

Rawe: We also need to convince more people to use plain language. We can’t always avoid complex terms, but we can make sure people can access their definitions. Word choice is very important. If you’re writing a manual on how to fix a carburetor, you’ve got to use the word “carburetor,” but you don’t have to use “utilize” and “implement” and all the other unnecessarily complicated verbs that make writing less conversational.

Unfortunately, there is still a perception that clarity and ease of understanding are not essential for specialized audiences. Too many people still think that complicated writing sounds more sophisticated. We need to convince more people that even academic papers should be easy to read. A room full of astrophysicists can get through giant paragraphs full of jargon, but if you made it easier for them to skim and grab your points quickly, those astrophysicists would be really happy. Everybody benefits from clear language.

Seeman-Horwitz: It would also open up research to people who are great at astrophysics, which is math-based, but may be slower at reading, such as dyslexics, and those with other communication-related impairments.

Authors

Julie Rawe co-facilitates the Cognitive and Learning Disabilities Task Force for the World Wide Web Consortium. She is a WCAG 3 editor and is director of content strategy and accessibility at Understood.org in New York, New York. jrawe@understood.org

Lisa Seeman-Horwitz co-facilitates the Cognitive and Learning Disabilities Task Force for the World Wide Web Consortium and is an inclusion researcher and consultant based in Beit Shemish, Israel. lisa1seeman@gmail.com