W3C SVG

Scope

Introduction

This document sets out the scope for the testing and evaluation of the C3 software. For efficient reporting, not every page and component is included in the scope. However, samples are chosen such that each important design pattern is covered.

In the report, issues are divided into General and Components categories. General issues may include problems with – for example – document structure or absence of focus styles. Components issues organize advice by isolated component, such as a dropdown menu or dialog window.

Buttons

Introduction

In some cases, developers build custom versions of native HTML controls because they cannot achieve the exact look and feel or behavior they desire with a native control. Wherever possible, it is strongly recommended that native HTML controls be used over custom controls, as their accessibility support is much more robust.

WCAG criteria

Scope of the issue

In the case of C3, the buttons throughout the application are only styled to look like buttons. The C3 markup for a submit button is as follows:

<input type="image" name="btnSubmit" tabindex="12" src="/button_submit.gif" border="0">

There are a few accessibility issues with this:

  1. It only has a visual “submit” label. Non-sighted users will not know the purpose of this button.
  2. It is identified in the code as an image, not a button.
  3. It has a positive tab index. (See Inconsistency for more info on this.)
  4. In some cases, it may not be usable with a keyboard because:
    1. it is not focusable
    2. it does not respond to the expected keys for activating a button

Fixing the issue

It is recommended that the image type buttons be replaced with the native HTML <button> element, like so:

<button type="submit">Submit</button>

Images

Introduction

Assistive technologies have no way of translating an image into words to be read to the user, even if an image consists of only text. As a result, it is necessary for images to have short, descriptive alt text so that assistive technology users clearly understand an image’s content and purpose.

All types of visual information, such as images, are completely useless to some users unless a digital text alternative is provided so that screen readers or braille output devices can convert that text into either sound or braille. The same is true in varying degrees for people with low vision or color-blindness.

WCAG criteria

Scope of the issue

  • The “TMI Trust Company Specialized Trust Services Bond Account Access” header, present throughout the entire application, has no alt text.
  • Throughout C3, images function as buttons (see Buttons for more information) and lack alt text.

Fixing the issue

It is recommended that every <img> element has an alt text attribute as well as either role="presentation" or role="none" to convey their purpose and meaning to assistive technologies.

Submenu navigation

Introduction

The forms on the site are currently only available via dropdown sub-menus (pictured).

C3 Dropdowns

Dropdown sub-menus are precarious design patterns, prone to accessibility issues. In the case of C3’s implementation, there is are a few issues:

  • The link that activates each submenu does not communicate state (expanded or collapsed).
  • The menu does not close when focus is moved from its last item to the next adjacent link (e.g., from “Generate User Alert” under Alerts to Batch Control/Journal Entry).
  • Menu disclosures are inconsistent. The menu closes when the enter key is pressed to activate the next adjacent menu, but at times does not close when the next adjacent menu is clicked (i.e., the menus, at times, do not function the same way for mouse users and keyboard users).
  • The nested lists are not identified as submenus which, though not crucial, would be helpful.

WCAG criteria

Fixing the issue

It is recommended that the enhancements to the dropdown menu noted in the introduction are provided, as well as providing in-page navigation menus for each child page.

  • Give the top-level links role="button" (since they no longer function as links).
  • Include aria-expanded on the top-level links and toggle between false (nested dropdown menu not showing) and true (nested dropdown menu showing).
  • Add aria-label="submenu" to the nested dropdowns.
  • Close the menu when the last item is unfocused in a forwards direction.

Form errors

Introduction

As users attempt to complete forms, it is important that they be notified promptly when they make errors, and are provided assistance in fixing those errors.

For assistive technology users, completing forms can be especially arduous when one or more of the following are not true:

  • The invalid state of a field is not communicated
  • The error message is not associated with the field
  • The presence of errors is not communicated on submission

The careful wording of error messages and descriptions is also important, as well as indicating which text is error text without relying entirely on color or other visual cues.

WCAG criteria

Scope of the issue

Throughout the C3 software, form errors are announced upon form submission, but are not associated to the form element. Rather, form errors are announced via a dialog window that does NOT communicate the error message to assistive technologies like screen readers. Pictured here is an example of an error received on the “Alerts Lookup” form in C3 as well as what the screen reader (VoiceOver) announces to the user:

C3 Alerts Lookup form error

Though the dialog window visually explains the error and what the user must do to correct it, the screenreader only communicates the error to the user as, “Now in, demo.issinfo.com says, window, OK, button.” This would leave non-sighted users confused about what error occurred and what steps they need to take to remediate the error.

Fixing the issue

Form error messages must be included consistently and accessibly across the C3 software.

Individual form errors

The following code example shows what this form might look like (according to the semantic structure set forth in Forms) in its invalid/errored state, with notes to follow:

<fieldset> <legend>Alerts Reporting Selection Criteria</legend> <label for="trustnum">Trust #: </label> <input type="text" id="trustnum" aria-describedby="trustnum-error" aria-invalid="true"> <div id="trustnum-error"> <strong>Error:</strong> Please enter a Trust #. </div> </fieldset>
  1. The aria-describedby attribute associates the input field to the error message element using the shared trustnum-error in this case.
  2. The aria-invalid property sets the state and tells assistive technology users who have focused the field that it is invalid. Note that you must explicitly write ="true". Using aria-invalid (boolean) alone is unreliable.
  3. The id value matches the aria-describedby value.
  4. The <strong> tag allows for added meaning to the content. Visually, it works the same as the <b> tag, but it also serves as a non-visual indication to a screen reader of how something should be understood.

However, if the forms retain the table markup they currently have, the dialog window may also be modified to support assistive technologies. Here is an example of an accessible dialog window, with notes to follow:

<div role="dialog" aria-labelledby="dialog-heading"> <button aria-label="close">x</button> <h2 id="dialog-heading">Form error</h2> <p>Please enter at least one search criteria.</p> </div>
  1. The dialog is only announced as a dialog if it takes the dialog ARIA role.
  2. The aria-labelledby relationship attribute makes the element carrying the id it points to its label.
  3. The close button uses aria-label to provide the text label “close”, overriding the text content.
  4. The heading is used as the dialog’s label. The aria-labelledby attribute points to its id.

Announcing the presence of errors

You should let users attempt form submission and alert them to errors if they are present. You can announce error messages to screen readers by including a live region.

If you are not familiar with live regions, they announce (in screen readers) content as it is added with JavaScript. The basic markup for an alert live region is as follows:

<div role="alert" aria-live="assertive"> <!-- add anything here to have it announced in screen reader software --> </div>

A live region would be used, for example, if you wanted to add a div with a form error corresponding to a specific form field to the page upon form submission.

Forms

Introduction

In order for users to know how to fill out a form, the form has to be accessible. Key concepts include:

  • Labels for form inputs
  • Labels for groups of inputs
  • Instructions and hints, where necessary
  • Error prevention
  • Form validation

With all of these, information must be visible on the screen, accurate and meaningful, programmatically discernible, and programmatically associated with the appropriate form element or group.

The more interactive a form element or process is, the more attention needs to be given to accessibility with respect to:

  • Focus management
  • Setting and updating ARIA names, roles, and values, where necessary
  • ARIA live announcements, where necessary

Perhaps most importantly, all form elements need labels associated to them to be accessible. Where a label is not associated, the screen reader user is not informed of the field’s purpose upon focusing that field.

WCAG criteria

Scope of the issue

As mentioned in Page structure, C3 uses a layout table throughout the application, rather than semantic markup. This means that labels are missing throughout all the child forms and <span> elements are used in their place.

Fixing the issue

It is recommended that the child forms be reworked to use semantic structure including labels, fieldsets, and legends. An accessible version of the Alerts Lookup form (under “Edit an Alert” in Alerts) might be rewritten as follows:

<form> <fieldset> <legend>Alerts Lookup Selection Criteria</legend> <label for="trustnum">Trust #: </label> <input type="text" id="trustnum" aria-invalid="true"> <label for="typecode">Type Code:</label> <select id="typecode"> <label for="resp">Responsible:</label> <select id="resp"> <label for="freq">Frequency:</label> <select id="freq"> <label for="fdt">Starting date between:</label> <input type="text" id="fdt"> <label for="tdt">and</label> <input type="text" id="tdt"> </fieldset> <button type="submit">Submit</button> </form>

Heading structure

Introduction

Headings play a vital role in the accessibility level of any document. They provide a clear structure of a document which benefits all users, making it easier to scan through the content, and are used for navigation by screen readers.

Heading levels help to create a hierarchy of page subsections. There are certain rules to creating a hierarchy (or ‘document outline’) that should not be broken:

  • Levels should not be skipped. A section introduced by an <h2> must use <h3> to introduce immediate subsections.
  • Each page should have a single <h1> which introduces the unique topic of the page.
  • Any element that acts as a heading visually or structurally should be denoted as a true heading in the markup (<h1> → <h6>).
  • Any element that does NOT act as a heading visually or structurally should not be marked as a heading.

WCAG criteria

Scope of the issue

Throughout C3, <span> elements are used in the place of native heading elements and styled, using classes, to act as headings visually. For example, on the main page:

<td align="center" class="title1">
    C3 Main Menu
</td>

Fixing the issue

  • Each page should have a singular <h1> at the start of the main content.
  • Each subsection should take a heading level that reflects its nesting level in the document.
  • Each element that is used as a heading should use the correct heading element (and the appropriate level) in the HTML markup.

Inconsistency

Introduction

An important principle of inclusive design is consistency. Inconsistent interfaces present unnecessary burdens of comprehension to users – especially those who consume HTML semantics, such as screen reader users. In particular, inconsistent navigation schema and page structure can make the user feel disoriented and unsure.

Keyboard users

People who do not use a mouse – perhaps because they have a dexterity (motor) or vision disability – use a keyboard to access websites. In addition to being able to interact with controls on a page, a keyboard user must also be able to find items and follow both programmatic and visual focus. Sometimes the visual indication of focus may not exist or may not match what has programmatic focus, and this has huge implications for accessibility.

When keyboard users tab through focusable items (buttons, links, form elements, custom controls, etc), the order needs to make sense, so they don’t get confused. If a keyboard user – whether sighted or blind – uses the tab key to go through all of the focusable elements, the browser will start with the focusable elements at the top and proceed linearly through all focusable elements until reaching the bottom. The browser ignores all visual formatting and pays attention only to the underlying order that elements appear in the DOM.

WCAG criteria

Scope of the issue

This issue is most severe within the child forms, where navigation between each focusable item is inconsistent due to positive tabindex values. Positive tabindex values have the potential to cause significant problems for keyboard users:

  • A positive tabindex causes a discrepancy between the tab order and the reading order, leading to confusion. As the user starts tabbing through a form, the tab order can be counterintuitive and at odds with what the user expects, especially if they are sighted.
  • A positive tabindex remove items from their natural tab order, and instead places them first in the tab order. Browsers take any element with a positive tabindex value and promote it to the front of the pack for tabbing through the page, rather than proceeding linearly. Only after a browser gets through all elements with a tabindex does it then fall back to source order.

For example, the tab order on the “Alerts Reporting” form under Alerts is as follows (pictured):

C3 "Alerts Reporting" form

  1. “Trust #” input
  2. “Type Code” dropdown
  3. “Responsible” dropdown
  4. “Setup Date Range” input #1
  5. “Setup Date Range” input #2
  6. “Next Occurrence Range” input #1
  7. “Next Occurrence Range” input #2
  8. “Ending Date Range” input #1
  9. “Ending Date Range” input #2
  10. “Print To” dropdown
  11. “Submit” button
  12. “Main Menu” link
  13. “Log Out” link
  14. “Setup Date Range” calendar icon link #1
  15. “Setup Date Range” calendar icon link #2
  16. “Next Occurrence Range” calendar icon link #1
  17. “Next Occurrence Range” calendar icon link #2
  18. “Ending Date Range” calendar icon link #1
  19. “Ending Date Range” calendar icon link #2
  20. “Back” button

Note that the “Search” button next to the “Trust #” input never receives keyboard focus, which is another separate accessibility issue. (See Buttons for more info.)

Fixing the issue

It is recommended that positive tabindex values on the focusable items within the forms are removed, as this leads to inconsistent and unpredictable behavior for keyboard users. When these are removed, the browser will fall back to source order.

Language

Introduction

Screen reader users select a default language when installing and configuring their screen reader, so if no language is specified in the HTML document, the screen reader will read the document in the user’s default language.

WCAG criteria

Scope of the issue

Since a language is not currently specified in the HTML document, a screen reader will read the document in the user’s default language, which may result in an extremely hard-to-understand accent and render the entire application unintelligible if the page language doesn’t match the user’s default.

Fixing the issue

It is recommended to add an English lang attribute to the HTML document, like so:

<html lang="en">

Page structure

Introduction

Semantic HTML structure is paramount to accessible markup. Screen readers rely on the meaning of HTML elements and attributes to convey information to blind users. It is through the semantic markup that browsers are able to parse accessibility cues and information through the accessibility API and pass that information on to users through assistive technologies.

Using the appropriate semantic elements will make sure the structure is available to the user agent. The nature of a piece of content as a paragraph, header, emphasized text, etc. can all be indicated in this way.

HTML 5 key semantic markers

HTML has historically lacked key semantic markers, such as the ability to designate sections of the page as the header, navigation, main content, and footer. With HTML 5, these deignations are possible, using the new elements <header>, <nav>, <main>, and <footer>. Similar functionality is available using the ARIA (Accessible Rich Internet Application) attributes role="banner", role="navigation", role="main", and role="contentinfo".

Many screen readers now support the ability to navigate to sections of a web page using these landmarks.

WCAG criteria

Scope of the issue

C3 lacks a semantic HTML markup. The HTML markup relies on <table> elements which were intended to represent tabular data but have been commonly used for page layout, to overcome limitations in visual presentation using HTML.

Layout tables like those used in C3 do not pose inherent accessibility issues. C3 can still be navigated and understood using a screen reader. However, because tables were designed for data grids and tabular data, it is better to use them only for that purpose from a semantic structure perspective, especially because CSS is a more robust way to design visual layouts for the modern web.

Fixing the issue

It is recommended that the underlying structure of C3 is changed to a semantic markup using HTML 5 landmarks. Here is an example of appropriate landmark use:

<header role="banner">
    <h1>
        This is the header. Put company logo, etc. here.
    </h1>
</header> 
<nav role="navigation">
    <div>
        This is the navigation. Put navigation links here.
    </div>
</nav>
<main role="main">
    <div>
        This is the main content. Put main content here.
    </div> 
    <section>
        <div>
            Main content can also be divided into sections like this.
        </div>
    </section>
</main>
<footer role="contentinfo">
    <div>
        This is the footer. Put copyright info, etc. here.
    </div>
</footer>

However, if the layout table remains the underlying structure of the site, role="presentation" should be added to the main <table> element to ensure that all screen readers will read the content of the table as text in source order, rather than as a table (essentially ignoring the semantic table markup).

Timing

Introduction

Whenever there is a time limit on an activity, users should be made aware of the time limit ahead of time or be warned when the time is about to expire, and should be given sufficient time to either finish their work or extend the time limit.

In the case of C3, timeout occurs without advance warning to the user or the option to disable or extend the time limit before encountering it (pictured):

C3 Timeout Screen

WCAG criteria

Fixing the issue

It is recommended that users are warned of the time limit when they begin using the C3 software and are given the option to disable or extend the time limit before encountering the cut-off, perhaps via a timed dialog window. When a user’s authenticated session expires, their activity should be saved so that they can continue the activity without loss of data after logging in again.

Wording

Introduction

It isn’t enough that elements in a web page’s HTML are marked up correctly. Where they provide textual labels, these labels need to be readable and descriptive.

  • Headings must clearly describe the sections they introduce.
  • Labels for links, buttons, and form elements must clearly describe the purpose of those controls.
  • Page titles must sufficiently describe the page and its purpose.

Screen reader software aggregates headings and links into lists, so it is important they make sense independent of context. For example, a link reading “read more” are of little use in an aggregated list, especially where there are many sharing the same generic label.

The page’s main (<h1>) heading must be a subset of the page’s <title>. Ordinarily, you would include the name of the site, along with the name of the page, e.g. “C3: Alerts Reporting”. This way, a user with many tabs open knows which pages belong to which sites. The name of the page should be similar to the content of the <h1> tag.

Finally, it is important that parts of the interface are identified consistently, using the same terminology. This includes pairing the terminology in link text to the destination page’s <title> and main heading text.

WCAG criteria

Scope of the issue

C3 lacks descriptive titles throughout the application. The application <title> is “Welcome to First Access” on the main page as well as on all child form pages, which has the potential to leave screen reader users confused about where they are on the site.

As mentioned in Heading structure, C3 often uses <span> elements in the place of <h1> tags with title classes to add visual styling to look like the native HTML heading elements.

Fixing the issue

It is recommended that the main <title> tag is changed on each child form page to reflect the site title and page content. For example, the Alerts Reporting form under Alerts could be re-titled “C3 First Access – Alerts – Alerts Reporting”.