What’s The Void In WCAG 2.0 That The Proposed "Change in Content" Success Criterion 3.2.6 Attempts To Bridge?

Introduction

I strongly believe that the proposed success criterion 3.2.6 in WCAG 2.1 that deals with changes in content is unnecessary as WCAG 2.0 addresses all the contemplated situations very effectively. All that is really needed is to provide additional guidance via the Understanding WCAG 2.0 and Techniques for WCAG 2.0 documentation.

Proposed SC 3.2.6 Change of Content (Level AA) states:

Programmatic notification is provided for each change of content that indicates a user action was taken or that conveys information, unless one or more of the following is true:

  • There is a programmatically determined relationship between the new content and the control that triggers it;
  • The user has been advised of the change of content before or as a result of using the control;
  • The change of content both is not a result of a user action and is not related to the primary purpose of the page.

Note:
The Working Group is including this proposed Success Criteria for comment, but has not reached consensus on how to best handle web pages and applications
with continual changes of content such as games and simulations and seeks additional input from reviewers on this point.

A newly inserted definition for "change of content" reads, "changes made to a web page after it has been delivered to the user agent, whether or not initiated by the user ".

The above is per the latest editor's draft of the proposed WCAG 2.1[ Oct. 4, 2017].

My reasoning is grouped by the two categories of content changes the SC deals with:

  • Change in content triggered by user action, and
  • Continual change in content that conveys information

Change in content triggered by user action

As I understand these cover situations of change in a page's content like:

  1. Content based on filter / sort selections of data already displayed on page
  2. Addition(+/-) to cart
  3. A notification that "support by chat" is available for this task at hand
  4. Results of form submission when they are displayed on same page
  5. A global error message placed above the form saying “form submission failed etc.” or a thank you message after completion of a multi-step process,
  6. Error messages displayed instantly as one tabs off a field
  7. An update as one is typing, to the count of characters that may be typed into a textbox when it has a limit
  8. Data table content refreshed when sort column is changed,
  9. Change in content presentation on switching from list view to table view
  10. on selecting a different pagination link, and so forth.

Reason #1

The definition of "change of context" in WCAG 2.0 includes a change in focus or content that changes the meaning of the Web page. The drafters of WCAG 2.0 have included "major changes if made without user awareness, can disorient users who are not able to view the entire page simultaneously" within the normative definition of the term. Obviously this situation is something that was contemplated and is within the scope of WCAG 2.0, else they would have crafted an SC to address this.

The definition further notes, "A change of content is not always a change of context". Only a change in content that causes a change of context is an accessibility problem. When content added to or altered on a page does not cause a major change in the meaning of the Web page, there is no change in context and consequently no accessibility problem. It only implies that the manner in which the change is presented is deficient in terms of markup (i.e. for instance, an absent role or attribute) resulting in "unannounced changes" -the reason for the proposed success criterion as suggested in the description section of Github Issue 2.

Furthermore, in the context of SC 3.2.2, right from the beginning the Understanding WCAG 2.0 documentation has had a statement, "Clicking on links or tabs in a tab control is activating the control, not changing the setting of that control". This validates the above interpretation that the authors of WCAG 2.0 debated extensively about what types of changes in content cause an accessibility problem and expressly decided to exclude changes in content caused as a result of activating UI elements such as links and controls.

Reason #2:

Few accessibility consultants will fail to call an accessibility violation if a button causes a popup to be displayed on the page that goes undetected by a screen reader. Maybe it is just a list of "products you may also like" displayed in the popup with an ok button. Obviously the popup was not exposed as a dialog, it lacked a name and focus was not managed right.

Now consider what would happen if the same content that is in the popup sans the OK button , is placed somewhere on the page: this could be done in one of two ways:

  • The content is presented inconspicuously in a manner that it does not interfere with the user's current task-focus and is quite likely to be missed by most users unless one looks closely / pays careful attention, or
  • The content is presented very distinctively in a manner that it arrests a sighted user's attention.

In the first instance, the website's goal for displaying "Products you may also like" is not being achieved. It is also poor usability as most users do not notice this section of content or are unaware that this has been added to the page. This needs fixing at the design / usability level.

The second scenario wherein the content is styled distinctly and is eye-catching is a situation where the markup is deficient. This content needs to be within a container with a proper role and name. It is not unlike an image that conveys information to a sighted user but is not perceivable by a non-sighted user because the image lacks an assistive technology-interpretable text alternative. Likewise, the container for "Products you may also like" lacks a name and a suitable role (e.g. alert) or aria-live property with an appropriate degree of politeness. This can be done with an ARIA technique already defined for WCAG 2.0, namely, ARIA4 whose stated objective is, "define the role of an element using the role attribute with one of the non-abstract values defined in the WAI-ARIA Definition of Roles".

Look at it another way: Again accessibility testers are quick to flag some text that appears and functions like a semantic heading on a page but is not suitably marked up with an <h> tag (or role=heading) as a violation. Why not then flag this content that is presented to function like an eye catcher with an informational content with a suitable role? Some 15 years ago, a JavaScript alert was the norm for highlighting something for the user's attention. Coding techniques now permit less intrusive and more user-friendly methods but that is no reason for not exposing the element's role or making the information relationships and structure available via presentation programmatically determinable. By not considering WAI-ARIA roles, one may overlook semantics and information-relationships that can be marked up and exposed to assistive technology users too when the same information is available via presentation.

Reason #3:

Dr. Greg Vanderheiden suggested during a discussion on this topic in May-2016 [1]:

Opening up additional choices below the point of action was discussed and was clearly not felt to qualify. Adding information above the point of action was felt to be a problem. Dynamic pages – which are really other pages generated on the fly by the page script, is clearly a change of context.

In other words, in my opinion: If the script creates "other pages on the fly" it is simply another page to which all of WCAG 2.0 applies. For example, consider error messages i.e. new content, added by employing client side scripting to a page. While the page displayed may comply with WCAG 2.0 on page-load, the newly reported validation errors must also be held to the same standard, namely WCAG 2.0 in order to gauge the conformance of the page post-validation.

That is perhaps why some accessibility consultants agree that when only some content on the page has been altered or is freshly introduced, such content must be positioned in a logical focus order or reading order so as to maintain the accessibility of the page. In fact these instructions are also included in official training and guidance material of leading accessibility consulting firms.

Reason #4:

I fail to understand why the first exception listed in the success criterion suffices as a reason for waiving the required programmatic notification. How does a programmatically determined relationship between the new content and the control that triggers it help a screen reader user for instance detect that new content has been presented on the page? Such a relationship with the trigger element, whether existing at the time of page load or added dynamically later on, will do nothing to inform the user of the new content. Consider an example:

A user enters an invalid email address in the email field and tabs off. Instantly a message pops up and is placed above the form, "Email address is not valid".

If that message has aria-live, it will be read by a supporting screen reader even when the focus is on the control that follows the email field and there is no programmatic determinable relationship between the email field and the error message.

If that message is merely associated with the email field via aria-describedby, no screen reader will read it unless the user tabs back to the email field assuming it suddenly dawns on the user that the text entered is invalid.

Interestingly, this success criterion is believed to fall under the "Perceivable" principle as per Github Issue 2 and is yet listed under the "Understanding" list of success criteria on latest editor's draft of the proposed WCAG 2.1[ Oct. 4, 2017].

Continual change in content that conveys information

Consider a page contains such information (example: stock indices / stock price updates, score updates for a sporting event, update to incoming text messages, and the like) that happen at random intervals. At the outset, one would expect such content to occupy a designated portion of the page. One would then expect the section to have suitable semantics and structural markup. This is not very different from landmark regions like banner, main navigation, secondary navigation, breadcrumb navigation, search region, main content, footer section. Maybe this continually updating content could be a complementary region with a suitable heading. Then, depending on the intent of the page and the content author's objectives, the updates should be exposed via suitable aria-live properties. This would enable a user to navigate to and direct attention to that specific section of the page as needed. This again, this is something that does not need a success criterion but merely a supporting technique under the heading, "Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable" on How to meet SC 1.3.1.

Needless to say, auto-updating content already has explicit requirements in WCAG 2.0 SC 2.2.2. How Auto-Updating Content Is Fully Addressed By WCAG 2.0?

Conclusion:

Depending on the situation, one can invoke any one or a combination of existing WCAG 2.0 Level A success criteria if newly added content to a page is not accessible. Predominantly, these are:

  • 1.3.1 Info and Relationships
  • 1.3.2 Meaningful Sequence
  • 2.4.3 Focus Order
  • 4.1.2 Name, Role, Value

The proposed success criterion gives rise to two dangers:

  • This unequivocally conveys that changes in content as contemplated by the proposed success criterion need to be made accessible only by organizations which adopt WCAG 2.1 and not those that seek conformance with WCAG 2.0.
  • It tantamounts to proclaiming that the drafters of WCAG 2.0 failed to include a specific success criterion to address a serious accessibility issue even after recognizing in the normative text that, "major changes if made without user awareness, can disorient users who are not able to view the entire page simultaneously". This is patently not true I believe.

Just as an image on a page is rendered imperceivable because of a missing accessibility attribute, newly added content on a page goes undetected simply because suitable accessibility markup is not programmatically set, as a result of which, user agents and assistive technologies are unable to notify users of change in content. Accessibility evaluators today routinely flag such content addition issues as WCAG 2.0 accessibility violations. Techniques that address such situations have been in use for a while now. The techniques and understanding suite of WCAG 2.0 supporting documentation has lagged behind in this regard. These need to be updated with references to existing WCAG 2.0 success criteria in order to provide guidance to developers and evaluators alike. No new success criterion is needed.

One thought on “What’s The Void In WCAG 2.0 That The Proposed "Change in Content" Success Criterion 3.2.6 Attempts To Bridge?”

Comments are closed.