Feedback on WCAG 2.1 Draft

Overview

The following is feedback on the First Public Working Draft of WCAG 2.1. WebAIM currently supports adoption of 5 of these success criteria as drafted (with some recommended improvements). A few others would be supported (with clarifications and improvements), but not at the conformance level currently proposed. WebAIM does not support, opposes, or strongly opposes adoption of the majority of the proposed success criteria as drafted.

Our lack of support of a success criterion does not mean that we are opposed to the principles or recommendations provided, but instead simply indicates that we believe it is not currently viable for inclusion in WCAG.

We applaud the efforts of the working group on the progress they’ve made, but serious consideration of the current state and future direction of WCAG 2.1 is warranted if it is to become a successful and widely adopted W3C Recommendation.

Many of the draft success criteria are very difficult to understand, some bordering on unintelligible. This is especially (and ironically) applicable to the success criteria intended to address cognitive accessibility issues. There is little chance that most of these success criteria would be understood or accepted by a broader audience as currently proposed.

Additionally, many of the success criteria are not testable, conflict with existing success criteria, do not meet WCAG’s own requirements for inclusion, or simply would not possibly be adopted by web authors in general. 17 of the proposed success criteria are A, 11 are AA, and none are AAA. The severity of many of these success criteria are proposed at too high a level to likely be supported by authors or standards bodies.

Foundational WCAG 2.0 issues are not addressed

A premise of the 2.1 updates is that the existing 2.0 success criteria finalized in 2008 would not be modified. While we understand the desire for backwards-compatibility, it is disappointing that a more substantive update has not been attempted. None of the WCAG 2.0 issues WebAIM documented 5 years ago have been addressed in this draft. We strongly recommend that the working group reconsider addressing gaps and deficiencies of existing success criteria. We believe such changes will be necessary to resolve many of the concerns documented below.

Another primary concern is that some WCAG 2.1 success criteria would essentially invalidate existing success criteria by introducing more extensive requirements for conformance (and often at higher levels) than are present at 2.0. This is certain to cause much confusion unless the invalidated 2.0 success criteria are removed or updated to reflect the 2.1 requirements. As an example, by requiring 400% text sizing at Level A, the current 200% text sizing success criteria at AA would become moot, so therefore must be removed to avoid confusion.

SC 1.3.4 – Support Personalization (Minimum)

While the premise of this Success Criteria (SC) is to ensure that visual presentation is identified via underlying semantics (something already required under 1.3.1, etc.) to allow customization, it additionally requires author inclusion of specific customization via author-settable properties and attributes that do not yet fully exist. Because WCAG techniques ought not be normative, and because these techniques are not yet available in ARIA or other standardized, accessibility-supported ways, this would thus require significant author modifications or customization options to bring otherwise conformant content into WCAG 2.1 Level A conformance.

WebAIM does not support the adoption of this SC as drafted.

SC 1.4.10 – Linearization

Reflowing content into a single column provides numerous benefits. This SC should, however, be clarified to refer to not inhibiting reflow based on user customization of your content rather than suggesting that authors must provide “a mechanism” for reflowing content, such as a “Linearize page” control on each web page.

Additionally, this SC should be scoped to primarily apply to text content, and generally longer blocks of text at that. If applied to other types of content, such as horizontally oriented toolbars, tree widgets, etc., this would require significant author effort and would result in non-standard presentations that would most often be less accessible.

Some clarification of the overlaps of Linearization and text sizing may be necessary. Is single-column reflow also required at 400% text sizing without horizontal scrolling?

WebAIM supports the premise of this SC, but does not support adoption of this SC as drafted.

SC 1.4.11 – Resize content

A primary concern is that this Level A success criterion requires 400% text sizing which would invalidate the existing 1.4.4 Level AA success criterion which requires 200% text sizing. This would cause confusion as to why a Level AA SC requires a lower threshold for sizing than a new Level A SC.

Meeting this SC will require significant effort by many web authors. Few popular sites tested come close to meeting the 400% sizing threshold.

WebAIM suggests a more practical approach – perhaps 200% text sizing with minimal horizontal scrolling (perhaps double the viewport width) at Level A, 400% text sizing with minimal horizontal scrolling (perhaps double the viewport width) at Level AA, and the draft SC as proposed at Level AAA.

It is hoped that the working group will also address content loss for true text sizing (i.e., not zooming the page, but only increasing text size) to a reasonable level – perhaps 150%. This and the existing Resize Text SC generally neglect this audience which represents 38% of respondents to the WebAIM Survey of Users with Low Vision.

SC 1.4.12 – Graphics Contrast

We believe additional clarification and research is needed regarding the relevance of the current WCAG-defined contrast requirements to modern displays and users. These WCAG formulas and thresholds for contrast are primarily based on research conducted in 2001 on an Amiga 1000 display. Display technology and user adeptness has certainly changed significantly since then, yet few people question the applicability of this research to the modern web. WebAIM will soon be conducting research into human perception of contrasts and mapping this user data to the WCAG thresholds to provide some insight into these questions.

As with the existing text contrast success criteria, additional clarity is needed to define testability of contrast with gradient backgrounds, text (or, in this case, graphical element) borders/shadows, ‘busy’ backgrounds, etc. The 4.5:1 threshold would result in very limited color options in many designs.

WebAIM highly welcomes the addition of a contrast requirement for graphical content, but additional clarity and scope is needed for this success criterion to be viable.

SC 1.4.13 – Printing

The ability (or lack thereof) of user agents to properly apply user magnification to printed documents should not be the author’s responsibility. This success criterion falls well beyond the scope of WCAG. This SC would essentially require authors to become familiar with user agent print deficiencies and bugs, and force them to apply user agent specific @media print styles to address these.

WebAIM opposes the adoption of this SC as drafted.

SC 1.4.14 – User Interface Component Contrast (Minimum)

This SC is very difficult to understand as written. It simply is not clear which components need to be measured against which other components. Additional clarification is needed. Despite the current lack of clarity, addition of contrast requirements for indicating user interaction states for elements is very welcome.

SC 1.4.15 – Adapting Text

As the many GitHub comments indicate, this success criterion is very problematic as written, but notable improvements have been suggested. We generally agree with David’s suggested wording here, with two exceptions…

First, it should be clarified that “text styles of the page can be overridden by the user…”. Exclusion of this language or inclusion of the “a mechanism is provided…” text will invariably result in authors believing that this requires them to provide the functionality via an in-page widget or user preference when this is not (we believe) the intent.

Second, user overrides of “font family” opens up too many variables for testing and should thus be removed. What if the font characters in the user-specified font are significantly disproportionate to the author-supplied characters in size, shape, etc.? The variations introduced by font family customization are, we believe, adequately covered by the manipulation of line, letter, and word spacing. The only other possibility to ensure consistent testability is to define a specific font face (e.g., Verdana) which introduces other notable difficulties.

WebAIM supports the general concept of this success criterion, but additional clarification and consideration is needed in order for it to be viable.

SC 1.4.16 – Popup Interference

It’s difficult to comment on this success criterion because the descriptions and scenarios presented for it do not at all match the success criterion text. It is entirely unclear what the intention of this SC even is, but I’ll attempt to address some of the issues as we understand them.

The SC language clearly exempts user agent rendering of title text, yet the descriptions and examples refer specifically and almost exclusively to user agent rendering of title text. Because title text rendering is primarily controlled by the user agent, we believe title attribute presentation should not be covered by this SC.

The descriptions refer to enlarged mouse cursors obscuring ‘tooltip’ content and describe allowing multiple mechanisms for triggering the ‘tooltip’ content (this is already partially covered by keyboard guidelines), but the SC text addresses neither of these. There’s clearly an editorial disconnect here.

Presuming that the SC is actually regarding ‘tooltip’ content obscuring triggering content (e.g., a tooltip for a link obscures the link text), this is primarily handled by the user agent or does not seem to be a disability-specific issue, but a general usability and design consideration that does not have place in accessibility guidelines. If nobody can see the triggering content, then there is no disparate experience for users with disabilities. It also is unreasonable to require that authors provide a mechanism to turn off tooltip content when this interaction model may be necessary and is otherwise conformant.

WebAIM does not support the adoption of this SC as drafted.

SC 2.1.4 – Speech Input

“All functionality of the content does not obstruct…” is difficult to understand and measure. Suggested rewording – “Commands that can be triggered via speech input are not obstructed by author-defined functionality.”

This success criterion presents two scenarios. The first is when a user speaks a word that matches a functional element on the page, and the speech control software triggers that functional element without user’s intending to do so. Assuming that speech control actually worked this way (my experience has been that triggering functionality requires additional speech activation, such as speaking “Click Products” rather than simply “Products”), the only way to avoid this conflict would be for authors to either not provide functional elements or not use words to define them. This clearly is untenable. This is an obscure user agent issue that should not be of concern to authors.

The other scenario presents a situation where a button that visually presents the text “Submit” is not identified with this text semantically, thus causing the voice control user to not know how to activate this control. This scenario is somewhat covered by other success criteria in 2.0, but is not covered at all by this proposed SC text. Restructuring this SC to address this issue would be a welcome improvement – perhaps “Interface controls have programmatically determined text that matches or is equivalent to the visually presented text or functionality of that control”… or similar.

WebAIM does not support the adoption of this SC as drafted.

SC 2.2.6 – Timeouts

This Level A success criterion is generally untestable. There’s no way to objectively measure “easily return”, “simple action”, or “simple, understandable language”. This also omits obvious exceptions where time limits are essential or unavoidable.

It is not reasonable or appropriate to ask authors to record all user actions and states (presumably even client-side ones), and then provide seamless loss of data for users that abandon and then return to an activity up to a week later. There are many instances where the user states cannot possibly be tracked. In many instances, such tracking would be unethical and illegal – the example scenario suggests that a travel site must store and then re-present a user’s credit card number after a week, even without user permission to do so.

The requirement to inform the user ahead of time would seemingly necessitate lengthy and confusing informative messages on all pages that have timed components – “Your session will time out in 20 minutes. You will have a five minute warning period before you are logged out and will have 120 seconds to respond to this warning message.” The complexity of such a warning may introduce more difficulty and overhead than the timeout itself.

The primary issues introduced by timeouts are already generally addressed via the existing 2.1.1 SC (Level A).

WebAIM does not support the adoption of this SC as drafted, but may support a clarified and improved version at Level AAA.

SC 2.2.7 – Animation from interactions

The impetus for this SC is to address vestibular issues (e.g., dizziness or nausea) associated with parallax scrolling (simultaneous foreground and background scrolling in different directions or at different speeds), but the language does not make it clear that scrolling is “a user action”. Clarity is needed.

This SC prescribes explicit thresholds (1/3 of the viewport and 3 seconds) with no clear data to back up the impacts of these particular values. While triggering vestibular disorders is certainly impactful to users, quality user research is needed to provide justifications for a Level A SC that would have notable impact on web/mobile design and user interaction.

This success criterion would render many common and often useful interaction models non-conformant – such as swipe animations on mobile, pop-up menu animation, focus scrolling, etc.

WebAIM would support the adoption of a clarified/improved version of this SC, but likely at Level AA or AAA unless additional, definitive research suggests a clear mapping of the defined thresholds to significant user impact.

SC 2.2.8 – Interruptions (minimum)

This success criterion is at odds with 2.2.1 and 2.2.6 which prescribe pop-ups and notifications to inform of time-outs. It also conflicts with the new SC 3.2.8 (Change of Content) which requires that users be notified of content changes. How can authors inform users of a time-out or content change to meet one success criterion when such notifications are disallowed by another?

“Interruptions” is not clearly defined. Are dynamic form validation messages (such as slightly delayed indications of an unavailable username) “interruptions”? Auto-complete suggestions? Chat messages or new e-mail notifications that are a core function of an application? In cases where interruptions are important, but not an “emergency”, critical functionality could be lost, thus resulting in notable negative impact on the user experience.

Until standard mechanisms are available for client-side control over such interruptions, the only mechanism for meeting this success criterion is via a user control, which itself introduces cognitive load and comes at notable author effort. This would be at odds with important and critical messaging systems in modern web applications.

WebAIM would support adoption of this SC, but only at Level AAA.

SC 2.4.11 – Single-key Shortcuts

The explanation of the success criterion indicates that it is intended to stop conflicts with voice control software triggering single-key shortcuts in a page. This seems to clearly fall into the realm of the voice control user agent to distinguish dictation input from activations of user controls. If voice control software triggers an “A” shortcut anytime this letter or a word containing this letter is voiced (at least not without a qualifier – “Click A”), this clearly is a user agent deficiency, not an authoring issue.

However, the SC language (“Single-character shortcuts are not the only way activate a control, unless…”) does not generally help in this scenario at all – an author simply needs to provide an additional “way” for the user to get this functionality. For example, the presented scenario of “Y” triggering Gmail’s “archive message” functionality would never be a failure because additional interface options are available to perform this functionality (e.g., an “Archive Message” interface button). It would be relatively rare for authors to rely entirely on a shortcut key to trigger such functionality.

This SC should additionally be clarified to only apply to author-defined shortcuts, and not to user-agent shortcuts. And only to alpha-numeric shortcuts, not Esc (to close menus/dialogs) or Space (to trigger checkboxes), for example. Otherwise this would cause authors to override user-agent functionality, such as creating a custom select input because the browser otherwise provides single-key functionality (e.g., hitting “U” on a State select menu jumps to “Utah”). This could also be interpreted to prohibit auto-complete functionality (for example) which provides varying controls/options with each individual key press.

This SC also discourages the use of single-key shortcuts which can be extremely useful for many other users with disabilities, primarily users with visual or motor disabilities that rely on efficient keyboard interactions. It would be very atypical for a Level A SC to discourage a technique that provides long-standing, accessibility-supported functionality for many users in order to address the needs of a small audience of users in an extremely narrow scope of applicability – when users with voice control software (that is incapable of differentiating user input from activation of user controls) errantly voice a command that matches a single-key short defined in an application that doesn’t have an alternative for that functionality or an option to customize or disable that shortcut. This seems more suited for AAA or as an advisory technique.

WebAIM does not support the adoption of this SC as drafted, but may support a clarified and improved version at Level AAA.

SC 2.5.1 – Target Size

The term “target” should clarify that this applies to the interactive area of a user activated link or control. The term is currently rather nebulous. “Primary purpose or function” is also vague and difficult to measure.

An exception is defined for when the link/control “has an alternative link/control whose target does meet the minimum size requirements.” Consider a superscript single character link to a footnote section at the bottom of a page. This would be a very common failure for this SC. This footnote content is readily accessible by scrolling the browser. While not as easy as a suitably-sized target for the link, this would, we believe, be more useful than requiring the author to provide “an alternative link/control” on the same page that does meet this size requirement. Consideration should be made for in-page content that is already accessible without activating the control.

Because much existing conformant web content would become non-conformant upon adoption of this SC as written, WebAIM supports adoption of this SC at Level AA with additional clarifications as noted above.

SC 2.5.2 – Pointer inputs with additional sensors

An exception should be added for when additional pointer sensor information is critical to the functionality. WebAIM otherwise supports adoption of this SC as drafted.

SC 2.5.3 – Touch with Assistive Technology

This requires that authors not introduce functionality that conflicts with screen reader overrides of touch events (or that they provide an alternative mechanism, such as “a mobile menu button”). The primary difficulty is that there is a myriad of current and yet-to-be-defined screen reader touch events that would be impossible for an author to fully test or consider. This SC therefore seems to essentially require that touch events not be used or that alternative mechanisms always be provided. We don’t believe this is the intent.

It seems that this is primarily a user agent issue – they should allow users the ability to specify whether touch events are handled by the assistive technology or are passed to the platform (as is the case with key events in Windows screen readers).

It’s likely we are misinterpreting an aspect of this SC, but it does not seem viable for inclusion in WCAG.

SC 2.5.4 – Pointer Gestures

For touch interfaces, because 2.5.3 (above) seemingly requires alternative mechanisms (such as a “a mobile menu button”) for all simple pointer gestures (and, presumably, all complex ones too), this seems to be a moot requirement if 2.5.3 stands as is. Why would an author provide a simple gesture alternative for a complex gesture when both the simple and complex gestures require a standard button alternative? Or perhaps we’re misinterpreting all of this.

This would have a notable impact on many standard and (potentially) otherwise conformant interfaces, such as Google Maps, many mobile interfaces, etc. WebAIM supports the general intent of this success criterion, but it seems best aligned with Level AA.

SC 2.6.1 – Device Sensors

WebAIM supports adoption of this SC as drafted.

SC 2.6.2 – Orientation

This success criterion also seems to be primarily focused on user agent flexibility, not on authoring practices. It is not generally possible for users to fully restrict the device orientation of web content. And if this is or were made possible, would it not be incumbent on the user agent to allow end user override or customization of this (just as they should allow resizing of pixel-defined text, pinch-to-zoom functionality, etc.)?

The problem that is being addressed by this success criteria is either generally non-existent for web content, or needs to be clarified so authors understand what techniques to avoid.

SC 3.1.7 – Plain Language

This success criterion has the following issues:

• It is nearly impossible to test due to high levels of subjectivity and an inability to measure to the vague terms and definitions provided.
• It is confusing and (ironically) does not meet its own requirements for plain or concrete language
• It is not applicable to a wide array of web content
• Many of the requirements seem arbitrarily defined and lacking in research-based evidence (e.g., why 1500 most common words as a maximum?)
• How would the 1500 most common words be defined in a way that is accurately testable? Would these be defined in normative WCAG for all languages? If not, the changes to external lists of common words would cause the conformance of content to be subject to changes in language usage over time. This would require significant and frequent testing to determine if all words used are still on the “common” list.
• It relies on mechanisms for user-defined content customization (such as automatically replacing non-literal text with a literal alternative) that do not yet exist. In absence of such techniques, authors must then provide very onerous mechanisms to provide such alternatives programmatically (and these controls would themselves be inherently complex for users to parse).
• It imposes editorial and content restrictions that extend well beyond the scope of WCAG, particularly for Level A conformance

While clearly well-intentioned (many of these best practices would certainly do much to improve understandability for many users), this success criterion is too rigid, too restrictive, and too subjective to be reasonably applied by authors to the majority of web content.

WebAIM does not support the adoption of this SC as drafted.

SC 3.1.8 – Manageable Blocks

Like 3.1.7, this success criterion may not be applicable to many instances of content. It seems much too restrictive and difficult to understand and test. Additional research is warranted into these defined thresholds. Does this apply to verbal/auditory “statements” as well as text “statements”?

WebAIM supports adoption of this SC, but only at Level AAA.

SC 3.1.9 – Extra Symbols

While adding symbols at the beginning of critical controls may be helpful for some users, it would certainly increase cognitive load and difficulty for many other users, particularly in areas where related or generally understood symbols are not available for that critical functionality.

Terms such as “which relates to the topic”, “significant financial loss”, “deterioration in a patient’s condition or effective loss of rights”, “safety, risks, privacy, health or opportunities”, etc. are very subjective and unmeasurable.

WebAIM does not support the adoption of this SC as drafted, but may support an alternative at Level AAA that adequately addresses these concerns.

SC 3.2.6 – Accidental Activation

Additional clarification of “single-pointer activation” is warranted, otherwise WebAIM supports adoption of this success criterion, though it seems best aligned with Level AA.

SC 3.2.7 – Familiar Design (Minimum)

It’s difficult to comment on this success criterion because it is mostly unintelligible and untestable.

How does one measure “easily identifiable and available”? This is not defined.

Why were only “help, navigation to help, and search forms” identified for this design requirement? Is this based on research?

Does this require that all pages provide these three items? Or does this only apply in cases where these are already present?

How can a “platform specific user interface design” apply to web content which is, by its nature, not platform specific? How would an author know what these design patterns are (short of defining them all in normative content)? When platform specific design patterns change, does content that was previous conformant suddenly become non-conformant?

Measuring whether a “design was used successfully by users in a prior version” may not be possible to authors lacking access to a time machine. Why would success in a prior version be relevant to success in the current version? How would an author know that a user needs the fall-back to the prior version short of the user indicating this? Or must the fall-back always be provided (thus making it the primary version, not a fall-back)? Providing a fall-back to a prior “successful” version for only these critical elements would likely violate 3.2.4 which requires consistent identification of such items.

If understood correctly, this would prescribe very specific and rigid design constraints for what are often (by nature of usability) the most prevalent and important items within web content and applications.

WebAIM strongly opposes the adoption of this SC as drafted.

SC 3.2.8 – Change of Content

This SC is generally supported by WebAIM. It is, however, unclear how the “5 notifications per minute” exemption applies. Because these notifications would generally be triggered by user activation, if the interface allows more than 5 activations per minute, does this success criterion no longer apply? Because one can’t generally control the number of user activations, how is this testable?

Or is this suggesting that after 5 notifications in a minute that the author can disable the notification and still be conformant? In this case, can the notifications be disabled from thenceforth, or must they be re-enabled as soon as the “5 per minute” threshold no longer is applicable (e.g., no longer than 1 minute after the last activation)?

Or is this only intended for notifications that are not user activated, such as an interface that updates content automatically more than 5 times per minute? Clarification on this exemption is needed.

As an editorial note, the definition of “Programmatic notification” is not linked from the success criterion.

Assuming clarification of the above, WebAIM supports adoption of this success criterion.

SC 3.3.7 – Minimize user errors

This necessitates manipulation of user-entered data in ways that could violate data integrity and usability (e.g., a potential failure of 3.2.2 On Input – Level A).

As stated in the Editor’s Note, “common input error” needs additional clarity without relying on non-normative content.

Errors “that have been reported or documented more then [sic] one time” is unmeasurable. This would also create a scenario whereby conformant content could be immediately rendered non-conformant simply by a user reporting an error. How is a “report” defined or measured?

“…and there is a known way to identify them”. Known to whom and in what ways?

Interpretations of “where the corrections can be reliably made” would vary greatly and would certainly be contextually, culturally, and technologically dependent.

WebAIM opposes the adoption of this SC as drafted.

SC 3.3.8 – Undo

“Users are provided with the ability…” Does this require author-supplied mechanisms? Is the Back button sufficient?

“Clearly labeled” is subjective and unmeasurable. “… get back to the place they were at” is ambiguous. Which place? For how long after the action must the user be able to undo and be returned to “the place”? Must a vendor allow a user to “undo” a financial transaction?

“… unwanted loss of data” is subjective to the user, not to the author, and is thus unmeasurable.

This proposed Level A SC would generally render existing 3.3.4 (Level AA) and 3.3.6 (Level AAA) regarding Error Prevention moot because this would require a significantly higher level of error recovery.

Barring significant changes and clarifications, WebAIM strongly opposes the adoption of this SC as drafted.

SC 3.3.9 – Provide Support

“Content is provided that helps users understand…”. This alone makes this SC untestable. What types of content? How is this content provided? How can one measure whether content helps or does not help user understanding? How much must it help? Which users?

Are there examples of types of “content” that should be provided to help users understand “forms”?

Is there some research-based metric for defining “long documents” as over 300 words? How would providing additional content always aid in understanding content that is already “too long”?

Requiring additional content would increase cognitive load and could decrease understandability for some users with cognitive or learning disabilities. WCAG success criteria that pose such potential conflicts are typically defined at Level AAA.

While well-intentioned and intended to provide best practice guidance, this success criterion is confusing, untestable, and untenable for most web content. WebAIM opposes the adoption of this SC as drafted.