Katherine Lynch dot org
Blog
contact
resume
decorative icon of a mug saying 'i heart design'

"People ignore design that ignores people." - Frank Chimero

Follow me on Twitter, handle @katelynch Subscribe via RSS

Accessibility Tips for Programmers


Programmers have daily close contact with web accessibility standards.  They can familiarize themselves with standards and code them directly into applications and tools, know what to look for in content editing tools and management systems, and help ensure that site designs are made accessible for everyone.

Web Content Accessibility Tips for Programmers

  • Make text resizable.
    Many browsers include tools for resizing text on a page.  Famously, Internet Explorer 6, 7, and 8 does not resize text sized in pixels.  Consider adding a widget at the start of the page to resize text for these users.
  • Make sure that the software your authors use to create and manage content supports accessibility techniques.
    The content-writing software that your clients use should support all of the following:
    • alternative text for images and links
    • applying header styles
    • scoping data cells in tables
    • the use of ID, name, labels, fieldsets, and legends for form construction
  • Set the language attribute to the appropriate language on all pages.
    Setting the correct language on the page will help screen readers and speech synthesizers pronounce native words correctly.  It can also help user agents with spell-checking and dictionary terms.  Finally, this also helps Braille translators interpret accented characters.  In HTML, simply set “lang=en” in the HTML element.  In XHTML, also set “xml:lang=en” to ensure full compatibility.
  • Validate your HTML.
    Use an HTML validator to ensure that all markup is correct, including opening/closing tags, nested elements, unique Ids, and non-duplicate attributes.  The W3C Markup Validation Service is widely-used, and checks both HTML and XHTML.  It can be accessed here.
  • Make events happen on click, not on focus.
    Many assistive technologies treat focus as a way to skim headings and links.  It is therefore best to set “activate” or “onclick” as the trigger for events such as opening a new page or advancing to the next step in an application.  Also always warn users if a link on a page will open in a new browser tab or window.
  • When imposing time limits, make sure that users have enough time to read and use content.
    If possible, allow the user to turn off or significantly increase (by at least 10 times) the time limit before encountering it on the page.  If there is a time limit on content such as audio or video, allow the user to pause and restart in the same location.
  • Make all of your site's controls accessible from the keyboard.
    Many assistive technologies are treated as keyboard input by web browsers.  Make sure that all links and sections can be gotten to via keyboard input that does not rely on timings of individual keystrokes. 
  • Let keyboard focus move to and away from components.
    Avoid “keyboard traps” by making sure that any content a user can access from the keyboard, can also be escaped using keyboard controls, such as the arrow keys or tab keys.  If the control keys are changed from the standard arrows or tabs, make sure that the user is notified on the page of the method for switching focus.  Also make sure that tabindex is set to the appropriate focus order for controls and inputs on a page.
  • If a page contains audio that plays for more than 3 seconds, let the user pause, stop, or lower the volume.
    Make sure that the audio content's volume control is on the page, independent of the user's native sound system.  Consider adding a feature for site-wide user preference to turn automatic sounds on or off.
  • Allow users to pause or hide animations, continuously-populating feed displays, and any other blinking/flickering/scrolling/moving content where the movement lasts more than 5 seconds.
    However, unobtrusive animation that indicates an application is loading must stay on the screen as long as necessary if the user cannot interact with the application while it is loading.  Without the loading indicator, the user may become confused by the inactivity and believe that the content does not work, or that the browser is frozen.

Sources Cited: