WCAG 2.1 Review: Introduction
As I'm developing software to test sites for accessibility, I'm reviewing the 28 new proposed criteria for WCAG 2.1, primarily to determine how testable the criteria are using either automated or manual methods.
This post concerns a specific criterion: 3.1.7 Plain Language (Minimum).
To view my feedback on other criteria and more background info, go to my listing of feedback.
- 3.1.7 Plain Language (Minimum)
- Suggested Priority Level: A
- Simple tense: Use present tense and active voice.
- Simple, clear, and common words:Use the most common 1500 words or phrases or, provide words, phrases or abbreviations that are the most-common form to refer to the concept in the identified context.
- Double negatives: double negatives are not used.
- Concrete language: Non-literal language is not used, or can be automatically replaced, via an easy-to-set user setting. All meaning must be retained when non-literal text is replaced.
- Instructions: Each step in instructions is identified.
- When a passive voice or a tense (other than present tense) is clearer. Other voices or tenses may be used when it has been shown to be easier to understand, friendlier, or appropriate.
- In languages where present tense and active voice do not exist, or are not clearer in the language of the content, use the tense and the voice that are clearest for the content.
- When describing or discussing past or future events, the present tense is not required.
- If the writing style is an essential part of the main function of the site, such as a game, a literary work, or teaching new terms.
- Where less common words are easier to understand for the audience.
- The content will be penalized for not conforming to a given writing style (such as a CV, dissertation, or Ph.D. proposal).
- If there are no tools available in the language of the content that identify uncommon words, instructions that are longer then 400 words are exempt unless they directly relate to a critical service.
Provide clear and simple language in instructions, labels, navigational elements, and error messages which require a response to continue, so that all of the following are true:
I feel that this may be interpreted at first glance as covering all website content, but as it only relates to "instructions, labels, navigational elements, and error messages which require a response to continue", this makes it easier to handle as a Level A criterion.
The main challenge will be "Use the most common 1500 words or phrases", what should the source be for that? Especially as it includes phrases, it leaves it pretty open to interpretation as to where we would get the data from. It does make it the kind of task that is best verified by automated means with manual intervention, which isn't a bad thing in itself. It would be pretty tedious and time consuming to verify this one entirely manually.
I also prefer @mbgower's wording on the Concrete language point, it's much clearer:
Concrete language: Words are used according to their proper meanings or definitions. Metaphors and figurative language are not used unless they can be automatically replaced with literal text based on user settings.
I'm concerned that developers/testers may not have the skills necessary to identify present tense and active voice, though this can be remedied with good supporting documentation that includes many examples.
It does seem that this would be better addressed as a revision to 3.3.2 Labels or Instructions and/or 2.4.6 Headings and Labels, though I understand that WCAG 2.1 are not revising any existing criteria. However, I feel that there is a huge amount of overlap between this and the other similar criteria. It is much better for developers, testers and automated testing tools if the criteria are very defined so that it is clear where a failure lies. As proposed, if I were to find instruction text unclear, that would fail both 3.3.2 and this new criterion. I feel that it is confusing for developers and testers when this occurs, and adds to the overwhelm felt when a huge number of new criteria are introduced.
In summary, I don't feel it's clear enough how this differs from existing criteria, causing confusion for developers and testers. If the existing criteria cannot be revised with 2.1, I'd advise waiting until the next WCAG revision where they could be revised.