Screen Reader Fails To Detect Newly Added Content: WCAG 2.0 Failure?

Related Posts In This Series:

Introduction

Consider these two examples for error notification

  • Submit the form in Example 1 with input errors present.
  • Tab through the form in Example 2 without entering valid data.

Does the error message displayed above the form in Example 1, or the error message displayed for every field with invalid input in Example 2 fail WCAG 2.0? Notice that screen readers like NVDA or JAWS do not detect these messages when presented.

In my opinion, the answer is an unequivocal "Yes": it fails success criterion 1.3.1. This is mandated by the normative text (including definitions) of WCAG 2.0 and guidance documented by the Working Group for the success criterion in no uncertain terms. This success criterion applies to all content displayed on page-load or added later via script action. The above are examples of content rendered for users to consume without adequate markup to make information, structure and relationships programmatically determinable to the detriment of certain user groups, especially vision impaired users.

Quick Review Of Success Criterion 1.3.1 – Normative Text

The primary success criterion under the "Perceivable Principle" that is relevant is: SC 1.3.1 "Info and Relationships" which states,

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

Very aptly, this success criterion is placed under the "adaptable" guideline.

Note: The alternative method of making information, structure, and relationships available via text seldom applies when markup languages like HTML is used. The non-normative guidance suggests: it is strongly recommended that when technologies support programmatic relationships, information, structure and relationships are programmatically determineable rather than be described in text.

Related Definitions

content (Web content)
information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content’s structure, presentation, and interactions
presentation
rendering of the content in a form to be perceived by users
programmatically determined (programmatically determinable)
determined by software from author-supplied data provided in a way that different user agents, including assistive technologies, can extract and present this information to users in different modalities
relationships
meaningful associations between distinct pieces of content
structure
  1. The way the parts of a Web page are organized in relation to each other; and
  2. The way a collection of Web pages is organized

The examples (normative content) accompanying the definition for "programmatically determined" is instructive:

  • Example 1: Determined in a markup language from elements and attributes that are accessed directly by commonly available assistive technology.
  • Example 2: Determined from technology-specific data structures in a non-markup language and exposed to assistive technology via an accessibility API that is supported by commonly available assistive technology.

From the above definition, it is quite obvious that the onus is on the author to pick a technique that is suitable in the specific situation and implementing it correctly when the content is rendered or made available to users. Only then will information, structure and relationships of the content be programmatically determinable to serve users of assistive technologies and comply with SC 1.3.1. The alternative of conveying this via text is not considered here as it is largely inapplicable as explained above.

How Does Structure Become Perceivable?

The Working Group points out: "Sighted users perceive structure and relationships through various visual cues- headings are often in a larger, bold font separated from paragraphs by blank lines; list items are preceded by a bullet, and so on".

Elements that are "programmatically determinable" become adaptable. They permmits users to perceive structure and data relationships. A screen reader by default communicates a page’s structure when the page is first rendered in the browser announcing how many headings, links, forms etc. are on a page. Another screen reader feature permits users to pull up a list of headings or links or tables or form controls, etc. from any point on a page regardless of current focus to perceive content's organization and structure. The user can directly navigate to a desired element from this list.

What Is The Relation Between Focus And Programmatic Determination?

Consider the following examples:

  • When tabbing through a form, it is important for a screen reader to be aware of field specific instructions, error messages that appear to be related based on their presentation. Here, the related information should be programmatically determinable when the form control has focus.
  • The name for the form control, say placed within a label tag, serves as the control's identifier. It is announced by the screen reader when the control has focus. Conversely, a mouse user can click the label to move focus to the correspionding form control. It also permits the user to identify and navigate to a specific control regardless of current focus from a list of form elements drawn up by the screen reader.
  • While navigatiing a data table with a screen reader using arrow keys, there is no "focus" as one generally understands the term. The point of regard or interaction for the screen reader user is a particular data cell within the table.The corresponding row or column headers are announced by the screen reader as one navigates up / down the column or across a row respectively.
  • When section headings are marked with the h<n> tag, again there is no focus as such because headings are not natively keyboard-focusable. Yet a screen reader user can navigate effectively across headings on a page or perceive content organization and structure of the page. For the user a particular heading appears sort of to have "focus" or is the point of regard.

Here are three interesting points about focus:

  • Focus is covered by the term Web content. Being able to say which element has focus is critical for navigating and understanding Web content on a page.
  • Keyboard focus is seldom placed on informational content whose relation needs to be made programmatically determinable: e.g. visible text label for a form control or an error message placed next to the control and referenced, say, by aria-describedby. In the case of a data table, the screen reader user’s focus is on a particular data cell – not the header cell with <TH> markup. Newly added content in the nature of a notification or alert is no different- it does not require keyboard focus in order to become programmatically determinable.
  • Unless newly added content is in the nature of a user interface control one might not expect it to be focusable in the first place

Neither the normative text for SC 1.3.1 nor related definitions or guidance in WCAG 2.0 refer to "focus". Surely this is by design and is not an accident.

Critical Success Factor For Programmatic Determination: Choice of Accessibility Technique

Selecting a suitable technique that permits information, structure and relationships to become programmatically determinable in the context is critical. The guidance for this term states, "Several Success Criteria require that content (or certain aspects of content) can be programmatically determined. This means that the content is authored in such a way that user agents, including assistive technologies, can access the information".

Therefore, the author must consciously consider only the following when selecting a suitable accessibility technique in every situation when information, structure and relationships needs to be made programmatically determinable:

  • The information or content that needs to be communicated
  • A specific element or component, if any, to which that information relates
  • The action or event if any, user initiated or not, that triggers the rendering of the informational content.

Marking up the label text (without a label tag) as a p-tag or h-tag and positioning it next to the corresponding form control fails to make the label – control relationship programmatically determinable.

Likewise, placing the section’s header text in a p-tag with a 1.5em size and boldfaced does not render it as a heading unless it has role=heading or is marked up with an h-tag.

It hardly needs to be emphasized that exposing whether an element is a heading or a form control or a list item etc. is integral to the process of making information, structure and relationship programmatically determinable. In other words, if the element's role is absent or marked up incorrectly, it fails SC 1.3.1.

Accessibility Of Newly Added / Updated Content

If the informational content is triggered by an action or event, the accessibility technique employed must be able to expose the content to assistive technologies as soon as it is rendered by the user agent – because that's what the author intended.

An alert for instance is precisely something that conveys this semantic relationship to the user without causing a change in the point of focus. Failing to markup newly added content with a suitable role or property will cause the content to be not programmatically determinable and hence not perceivable to a screen reader user.

Experience a screen reader’s output (e.g. NVDA / JAWS) for the following examples:

  • Submit the form with input errors present in Example 1 (remediated for SC 1.3.1). Also submit the form with no input errors present.
  • Tab through the form in Example 2 (remediated) without entering valid data.
  • Finally, submit the form in Example 3 with input errors present and notice the screen reader prefixes the word "Alert" to the message placed above the form

Note: JAWS has the ability to list aria-live regions on a page with a filtering mechanism. (This feature is currently not working in JAWS 2018 / JAWS 18; a bug report has been filed). When the feature is restored, a user should be able to list aria-live elements including alerts on a page regardless of which element has focus. This is yet another example of content adaptability based on programmatically determined content.