The following are the top 9 accessibility issues that face websites, including those at Temple University. We encourage you to review the list and fix these issues you may have on your website. This list does not encompass every issue that can impact any given website.
Sections in this document:
- Alt Tags
- Proper document structure
- Page titles
- Form field labels
- Layout tables
- Skip-navs
- Scripted landings
- Interactive/rotating content
- Accessibility bolt-ons
1 – Alt Tags
Images or image based content need suitable alternative text (alt-tag). Decorative images, or those used for structural layout, should use a null-alt (alt="".)
What to do for Alt Tags
Read W3's Alt Text guidelines for how to craft the alternative text.
The person hearing/reading the alt tag knows that it’s an image, do not reiterate this in the alt-tag (i.e. do not use “a picture of Temple’s bell tower” instead use “Temple’s bell tower”.)
A null-alt (alt="") should be used if the image is decorative or only used for structural purposes.
2 – Proper document structure
Logical and sequential use of “Headings” (H1, H2, etc.) is absolutely essential to the effective and efficient use of websites. Assistive technology users often navigate a website through its headings and links. It can be confusing if the headings are not in a logical and sequential order, or if the links do not have appropriate names.
What to do for document structure
Web pages must use heading tags in a meaningful and logical sequence (not jumping from H1 to H3), and mark-up language to help text-reading devices interpret the structure of the page. Headings and labels should be used to describe a topic or purpose, and not as a mechanism for text formatting. Insure that users can navigate the page in a manner which matches the visual layout (typically top to bottom left to right.)
3 – Page titles
Web pages need to be properly titled to indicate that the user has moved from one web page to another. Frequently the landing page and all subsequent pages use the same title. This is particularly problematic for users of assistive technology since it is often only the page title that indicates when they have moved from a one page to another in the same site.
What to do for page titles
The pages must be uniquely titled to describe the purpose or topic of the page (note: it is appropriate to change the title of the page to include "error" if a page is reloaded due to a rejected form submission error.)
4 – Form fields
Form fields need to be associated with a proper field label so that assistive technology users know what information to provide. Text entry boxes also need to include a text label indicating the field's purpose.
What to do for form fields
Appropriately labeled all fields in electronic forms so that people using assistive technology can access the information, field elements, and functionality required for completion and submission of the form.
Errors for form submissions should be displayed in the page itself and not via a popup window or modal dialog. In addition, the title of the page should be changed to inform the user that an error has occurred.
5 – Layout tables
Tables should not be used to structure the visual display, or layout, of the page.
What to do for layout tables
Table based layout should be replaced with Cascading Style Sheet (CSS) based layout.
6 – Skip-navs
Links which allow users to skip the navigation, or menu, of a site are called "skip-navs." Skip-navs should be used so that non-visual or keyboard only users don't have to navigate through a series of repeated menus or list of links before they can get to the main content of the web page.
What to do for skip-navs
Provide skip navigation links (labeled "Skip to main content") as the first link keyboard and screen readers' access, positioned in the upper right corner of the site, and which is visible only with keyboard focus, and to screen readers. For more information on how to use CSS to implement screenreader/keyboard only skip-navs visit WebAIM's skip navigation page.
7 – Scripted landings
It is a common practice on many sites to use javascript to “land” the focus onto a particular control (for example in the Username field of a login box.) When a non-visual user encounters a page with a scripted landing they are often not given any indication what is being asked for. Sometimes these scripted landings interfere with keyboard only navigation.
What to do for scripted landings
Keyboard input focus should not be forced unless it is accompanied by appropriate ARIA markup language so that screen reader users have context for the requested input.
8 – Interactive/rotating content
It is common for websites to have a rotating banner, or to utilize interactive Flash objects. Both types of content are often problematic from an accessibility and usability perspective because they if not implemented well they can limit the ability of an assistive technology, or keyboard only user to interact with or bypass the content.
What to do for interactive/rotating content
The use of Flash and Shockware is strongly discouraged but if they must be used, then they must also gracefully degrade and provide the ability to be ignored without impacting the function or information contained on the site.
Essential content should not be conveyed using Flash, Shockwave or JavaScript
Rotating banners need to be controllable (to pause/resume rotation, or stop it all together) by keyboard only.
9 – Accessibility bolt-ons
Several companies sell specialized technology (e.g. automatic rendering of a text only version of a page, text-to-speech, "Access keys") in an effort to improve accessibility. In most cases these technologies are not needed, are poorly implemented, or interfere with an assistive technology users' own technology.
What to do for accessibility bolt-ons
If you cannot insure that a secondary specialized technology has a positive impact on the usability of the web content, do not use it. Automatically generated text only sites are only as good as the structure of the source page. Most users that need text-to-speech already have software installed and don't need it implemented on an individual website. “Access Keys” should be avoided since they are not implemented uniformly across all sites at Temple.