Part I of this article described what accessibility practices are and listed a few examples of accessibility best practices. This part discusses what should not be interpreted as a best practice in a report of accessibility findings and recommendations.
What is not an accessibility best practice recommendation
Besides documenting accessibility barriers that cause content to fail one or more WCAG 2.0 success criteria, a report in my opinion is incomplete if it fails to point out instances of:
- Accessibility technique misapplied
- Accessibility technique applied incompletely
- Poor design
that disproportionately impacts individuals with disabilities / users of assistive technologies. Well-meaning accessibility fixes when implemented incorrectly create new irritants that people with disabilities have to perpetually endure while negotiating Web content that is supposed to be more accessible. This directly ties in with the underlying premise for this article outlined in the introduction.
Accessibility technique misapplied – examples
- Failing to associate visible label with corresponding form control but setting a title on the control instead does not work with voice input software; it also breaks the ability to click on a label to activate / move focus to the related control.
- Sometimes developers over do it and have both an explicit (or implicit) meaningful label as well as a meaningful title attribute for a form field causing the control's purpose to be exposed twice.
- Setting a title attribute on a link that duplicates link text causes some screen readers to read both.
- Setting identical table caption and summary attribute on a data table
- Inconsistency: target of skip to content link and placement of main landmark
- Including an element's role in its name that is exposed to assistive technology, effectively causing duplication. e.g. alt="Apply button" on an INPUT type=image button is read as "Apply button button" by screen readers
Some years ago, it was not uncommon to come across decorative images to have non-empty alt attribute values like "spacer image" or "rounded corner image". By requiring that non-text content that is decoration, formatting, or Invisible should be implemented in a way that can be ignored by assistive technology as part of SC 1.1.1, WCAG 2.0 seeks to prevent mis-application of an accessibility technique. It is not realistic to expect WCAG 2.0 to "codify" all possible mis-applications of every accessibility technique.
Accessibility technique applied incompletely – examples
- Only 2 landmarks, say, banner and contentinfo are present; the page has sufficient headings to expose structure. In this scenario, screen reader users may attempt to look for navigation / main / search landmark regions and come up short. Users then have to switch to another navigation technique to understand the page’s structure / discover content. (Note: This view differs from the one indicated by Technique ARIA11 that suggests including all content within a WAI-ARIA landmark is a best practice.
Poor design – examples
- All links in navigation section begin with "Link to" or "Click" which breaks first-letter navigation in a links’list.
- Displaying and marking up elements as tabs but making them behave like hyperlinks
- Not hiding disabled fields
Not digital accessibility best practice
The following recommendations if implemented do not impact accessibility . At best, fixing these may improve the quality of code / make it more standards compliant.
- Ensure no text is marked up as a label if it is not associated with a form control
- Make sure every fieldset has a legend
- Make sure every layout table has role="presentation"
- Do not place empty heading (h-tags) or list (UL or OL Tags) on the page