Note: this information is directly from W3, rewritten for simplicity. Visit W3 for more info.
Make your site work as well as you can for everyone.
Web accessibility is the art & science of making websites usable by as many people as possible. It includes designing for & adding features to help blind, partially sighted & many other types of disabilities. Accessibility should be considered at the earliest stages, otherwise one day you may not even be able to use your own stuff. Helps with SEO too.
Text color should provide ample contrast against background colors, including that on images, background gradients, buttons, etc. The minimum contrast ratio (luminance contrast ratio) for text required by the WCAG is 4.5:1. Text in logos, inactive UI, for decoration or part of a complicated visual have no contrast requirements.
- Text that is less than 14 point when bold & less than 18 point when not bold is subject to a 4.5:1 contrast ratio when displayed on a solid (black or white) background.
- Text (or text in images) at least 14 point when bold & at least 18 point when not bold is subject to a 3:1 contrast ratio.
- Patterned or busy backgrounds, graphs, diagrams, empty text fields, etc. all require extra contrast considerations. (Ex: shading behind text content to maintain correct contrast ratio.)
- Red/black combinations for text/background also require extra contrast considerations.
- Black text on a faintly pastel background color (instead of white) makes the contrast less extreme & easier for some users to read.
- If for some reason contrast requirements cannot be met, a prominent link or control (with sufficient contrast ratio) allowing the user to govern contrast should be provided.
- Avoid using images that contain text, use Unicode text & style sheets instead.
- Ideally text & background colors should be left ‘unspecified’ so they can be determined wholly by the user or their assistive technology.
- Components should use middle of the spectrum (green, yellow, orange) for light colors & the outer edges (indigo, red) for dark.
- Simplify icons as much as possible (line drawings are ideal) & they should also meet contrast provisions for text.
An optimum level of contrast makes it easier for all users to read text content on your site, but especially those with poor vision or difficulty distinguishing color.
Not all users can perceive all colors (especially red & green) so it’s essential to provide alternate text identification for information that is generally conveyed using color. This is beneficial for more than just visually impaired users, it’s useful for various assistive technologies.
- Colored form control labels should also provide a text cue (ex: a required field on a form).
- Be consistent when using a color (& their alternatives) to communicate information.
- Provide alternative (redundant) visual cues (underline, bold, italics, font size, etc.) when text color alone conveys information.
- When color is used in an image or graphic to relate information, a pattern should be utilized for additional distinction. (Ex: bar charts using patterns along with colors to distinguish different bar values.)
- Hover states with obvious visual highlighting (that doesn’t rely on color alone) should be used to make clear when elements on the page are interactive.
Enables users who can’t see or distinguish between colors to access/interact with color-dependent information.
Offers monochrome or text-only displays & tactile (braille) interfaces better access to/interaction with color-dependent information.
Ensure that all interactive elements are highly keyboard accessible & visibly obvious when they are in focus (outlined, highlighted, etc.). Also, using a distinct (consistent) style & name for interactive elements (like links or buttons) makes them easy for users to identify & predict.
- Highlight links & controls when in hover state or receive keyboard focus (can be done in the CSS).
- All interactive components should have alternative text explanations along with information about what will happen when they are activated.
- Most operating systems/assistive technologies provide a native focus indicator which can be manipulated by the user for optimal visibility. When designing on a platform (WordPress, Joomla, etc.) ideally focus indicator settings should remain default, or they could interfere with the user’s original settings.
- If done correctly, default focus indicator settings can also be created in the content (higher contrast ratio, 3px yellow outline, etc.) for a higher degree of visibility.
Enables users who operate the page via their keyboard (no mouse) to visually determine which component on the page will be affected by keyboard interactions at any time.
Provides a clear focus point for interaction to users with limitations in attention, short term memory or executive processes.
Creates a more predictable experience for users relying on text alternatives, also enabling them to search for consistent labels on separate pages.
Navigation should be logical & enable the user to understand where they are within the page or on the site. Pages should provide clear (useful) headers, along with consistent layout, navigation, naming, styling & positioning, etc.
- Provide alternate methods of site navigation (ex: breadcrumbs, site search, site map).
- Multiple components which are repeated should always appear in the same relative order, even when new components are inserted. (Ex: menu should always be in the same location & order.)
- Where possible, overall page layout, positioning, layering & alignment should remain consistent sitewide.
- Use page templates to maintain page & navigation consistency.
- Creating a site map that links to all sections/pages on the site provides an overview of the site, methodized navigation & helps users understand/predict how content is organized.
- Site maps must be maintained when pages are added or removed & are not valid as ‘site maps’ if they don’t link to all sections of a site, present organization that doesn’t match that of the site or contain broken/invalid links.
- Creating a (linking) table of contents for long, complicated documents (especially if they span multiple pages) provides a document overview & enables users to jump to specific sections.
- Adding a search function enables users to locate content with specific keywords without the need of site navigation (especially useful on large sites). One offering basic corrective technology (spell-check, stemming, etc.) increases accessibility.
- For small sites, it’s acceptable to provide a list of links to each page, on every page (ex: footer links). If the list becomes longer than the actual content of the page, an alternative method should be implemented.
- Smaller sites can also offer links to all site pages from the homepage (& conversely all pages linking back to the homepage).
- Using the link element for navigation offers metadata for the position of an HTML page & assists in locating specific content within a set of pages.
- Tables of contents & concept maps should also include information about presentation modes.
Consistency of components from page to page enables users with poor/no vision, cognitive limitations or intellectual disabilities to accurately predict location & functionality of site elements.
Multiple navigation types enable users with a variety of different impairments find information in the way best suited to their specific needs.
All form fields should provide descriptive labels & the label should be obviously associated with the field they identify. For languages reading left to right, labels go on the left or above the field, for languages reading right to left, labels go on the right or above the field.
- Include clear descriptions about the effect of form control interactions/changes which cause a transformation of context. (Ex: language changing radio boxes at the top of a site should be proceeded by a text explanation.)
- Forms should follow a linear design, with similar items grouped & provide expected data input formats with examples.
- Text instructions describing necessary interaction should be provided before a (small) form or set of fields.
- Generally labels should be located immediately before input fields (for consistent alignment & ease of use/location).
- However, checkboxes/radio buttons are uniform in width (& their labels aren’t always), so their labels should be located after the field (this is a general ‘default’).
- Required fields should be marked with a symbol or text indicating their obligatory status. When the symbol or text is programmatically associated with their field, the user is advised of its meaning before they use it the first time.
- Any field which requires a specific (defined) set of input values should be accompanied by a text explanation, including a list of allowed values/suggestions of similar values.
- For fields accepting data formats with many common variants (date, time, phone number, etc.) providing a preference option enables users to input whatever format is easiest for them.
- The ‘label’ element can be used to associate a label with a form control, using the ‘for’ attribute (form control ‘id’ attribute value must = the ‘for’ attribute value).
- Groups of related form controls can be defined together using the ‘fieldset’ element with a legend (as the 1st element) providing a label or description. Nesting fieldsets can cause confusion & should be avoided.
- The ‘fieldset’ & ‘legend’ elements can be utilized whenever a group of controls inside a longer form require an additional heading for further delineation. (Ex: a group of address controls within a longer form.)
- By default most browsers display ‘fieldset’ elements with a border around grouped controls. While this visual cue is useful to many users, it can be modified in CSS & made more attractive.
- Descriptive labels can also be added various ways using Accessible Rich Internet Applications (WAI-ARIA) technology.
- In the rare case a label can’t be used or where it might cause confusion a ‘title’ attribute can be used to label form controls so they can still be read by assistive technology. *This technique can reduce accessibility for other types of disables users.
- In some situations it is acceptable to label a input field with an adjacent button, especially if it will reduce text redundancy. Buttons used to label single input fields generally follow the field (ex: search boxes). *This technique can reduce accessibility for other types of disables users.
When associated with input elements, label elements are spoken by screen readers when the field is in focus.
Visible field labels in close proximity to the fields they describe make it easier for users relying on screen magnifiers to understand content.
Examples of expected data formats & clearly identified required fields assist users with disabilities in cognition, motor skills, learning or language to enter information accurately.
Well written labels are meaningful to users who may read them out of context (table of contents, etc.)
Feedback requiring user action (like confirmations, alerts or notifications) should be prominently presented & exact action instructions should be easily identifiable.
- Error messages should be written in short, concise language & clearly distinguished from other text on the page.
- When a form is successfully submitted, always provide the user with success feedback in a prominent place.
- Where possible, highlight input errors in real-time by visually emphasizing them as they occur (using client-side scripting). This triggers an alert dialog with a text description of the error (dialog dismissal should return keyboard focus on the same field).
- Provide text feedback when a user enters information that falls outside of required/allowed formats or values.
- Provide text feedback identifying required fields & instructions/examples when left incomplete.
- When information is input incorrectly by the user, providing a list of suggestions for correction (spelling, format, etc.) can be useful. Suggestions (or a link to them) should be located in close proximity to the field(s) requiring correction.
- Where possible forms should accept input data in all common formats.
- If a form is submitted with errors it should be re-displayed with an outline of errors, a notification in the page title & the ability to jump (links) to/between errors.
- WAI-ARIA technology can also be used to indicate an error field.
Obvious notifications enable users with disabilities in cognition, language, learning & the visually impaired to be made aware when errors occur.
Clear information & examples for correcting errors allows users with a variety of impairments to update incorrect information with minimal effort.
Aids users with disabilities in cognition, language & learning to understand information represented by visual cues.
Use proximity & whitespace to ensure relationships between content are obvious to the reader. Provide descriptive page/section headings for easier scanning & understanding of content.
- Use unique headings for pages & sections.
- Break up long blocks of text into more digestible paragraphs & sections with relevant headers.
- Descriptive headings provide an overview of content & how it’s organized. This enables users to identify sections of content in relation to other sections on the page & to the page itself.
- Adding important information early in the heading allows for easier skimming through content via assistive technology.
- Headings should be marked so they can be identified programmatically using (properly nested) header tags (h1, h2, h3, etc.) to convey logical hierarchy.
- Each section of content should begin with a header tag. Not only does this indicate the start of main sections of content, but it demarcates navigation sections & enable users to quickly navigate by sections.
The use of descriptive headings aids users with difficulty reading, visual impairment or limited short-term memories to predict the usefulness of content in each section.
Enables those with limited mobility to reach the content they want with limited keystrokes.
Well written headings are meaningful to users who may read them out of context (table of contents, etc.) & in page navigation for the visually impaired.
Logical heading tags are an easy way for users to quickly navigate a page, predict organization & access recently updated content.
Website information is displayed differently on different devices/browsers/window sizes. Positioning of essential site elements should make good use of space & text/line height should maximize legibility for any screen size.
- Content-heavy sites can offer a mobile version with simplified content to accommodate smaller screens/limited space.
- Responsive designs can simplify mobile content delivery using CSS.
- Buttons, links & other touch controls should be large enough to easily access on mobile screens (even for those with low mobility or vision).
- Short urls are easier to read, type & use on smaller devices.
- In mobile portrait layout, form labels should always be displayed above their respective fields.
- Forcing a specific mobile display orientation can make it difficult for users with limited mobility to use & should be avoided if possible.
- Consistent layout of components across pages is especially important on responsive designs.
- Important page elements should be (consistently) displayed on mobile screens before page scrolling, enabling users with limited mobility to access & predict content without interacting with the page.
- When multiple elements perform the same action, they should be combined for mobile design (ex: text link & icon/image link combined in the same actionable element). Not only does this increase touch target size, it reduces redundancy in focus targets.
- Any element which triggers a change (links, buttons, etc.) should be clearly distinguished in a way that doesn’t require solely visual detection (detectable by assistive technology).
- The principle of redundant coding ensures that elements are indicated as actionable by more than one characteristic feature (shape, color, style, etc.)
- When using touchscreen & device manipulation gestures in mobile interfaces, instructions should be provided (in a prominent place, before scroll) explaining gesture controls along with possible alternatives. Users should be able to re-access these instructions when needed.
Making your website useful for mobile devices is essential for all of your users (most of which probably visit on their phone – are you reading this on yours?).
Aids users with low mobility or visibility understand, predict & navigate on smaller devices.
Any media or non-text content should also offer a short text alternative which serves the same purpose. This includes images, graphics, videos, graphs, charts, etc. For long/complicated content, written or audio transcript are useful to many types of users.
- All images should include alternative text using the alt attribute. This text should briefly convey what the image means, along with any text found within the image.
- Image title tags can be omitted for better accessibility, removing potentially redundant/confusing extra text (note: title tag displays text when an image is in hover state).
- Provide text explanation labels for icons or buttons with no text.
- Place captions or descriptions for tables, graphs & charts before they are displayed.
- Descriptive labels can be added various ways using Accessible Rich Internet Applications (WAI-ARIA) technology.
- Groups of non-text content used together to present function or information should provide a text alternative for the entire group & associate it with one of the grouped items. The remaining items in the group should be marked so assistive technologies will ignore them, limiting redundancy. (Ex: filled/unfilled star rating systems.)
- It can become confusing for users of assistive technology when non-text & text content contain adjacent links for the same resource. Combine text & non-text content links into one element & leave the image alt tag blank (which nullifies it for screen readers, eliminating duplicate text).
- Use alt attributes to label applets & provide a text alternative in the body of the applet element (both are required, as user agent support for the alt attribute & applet body text varies).
- Create a consistent place for visible links to transcripts of audio & visual description of videos.
- Users of assistive technology can’t render content that uses the objective element. Fallback text content can be added to the body of the element & is only available if the user agent can’t (or has been instructed not to) render an objective element.
- ASCII art can be confusing for the visually impaired using screen readers & should provide a text alternative. Where possible, a link to skip past the ASCII art is ideal for a variety of users.
- Emoticons include ASCII characters which can also confuse screen readers & should be avoided. When they are used, they should provide a text alternative (plugins are available on some blog & forum software for this purpose).
- Text content including leetspeak should also provide a plain text alternative for screen readers.
Users with difficulty perceiving visual content can use assistive technology to ‘view’ the content through audio, braille or simplified visuals.
Aside from the obvious benefits for the hearing impaired, text descriptions are helpful for users who have difficulty visually interpreting complicated information found in graphics, charts, photos, etc.
Text alternatives can also show up in site search, which otherwise wouldn’t return non-text results.
Provide obvious controls for all content that starts automatically & plays for more than 3 seconds when the page is loaded. This includes info that moves, blinks, scrolls, auto-updates, audio, video & animations that affect content.
- While automatic audio can be turned off when assistive technology is detected, ideally audio should only play when requested by the user.
- Provide (WCAG conforming) controls to automatic content at the top of the page/section reading order in an obvious location with a clear text label.
- If your site is auto-content heavy, provide users an obvious control to disable audio site-wide.
- Moving, blinking or scrolling information that begins automatically, last more than 5 seconds & is presented in parallel with other content should provide obvious controls to pause, stop or hide.
- Ideally controls to stop moving (blinking, scrolling) content should be provided to the user even if movement stops automatically after 5 seconds.
- Auto-updating information that begins automatically & is presented in parallel with other content should provide obvious controls to pause, stop, hide or control update frequency.
- Moving or scrolling content should provide controls enabling the user to pause activity & restart as needed. This can be done via (WCAG conforming) interactive controls or (documented) keyboard shortcuts.
- An easily accessible pause mechanism should be provided to any scrolling content created by a script.
- Assistive technologies enable users to stop some types of animated content (usually by pressing the ‘escape’ key). Graphics Interchange Format (GIF) & Animated Portable Network Graphics (APNG) technologies generally do not interfere with user agents.
- For blinking content that can’t easily be turned off, provide the user an obvious link/button option to re-load the page with a non-blinking text content alternative. The alternative page should provide the same information as the page with the blinking content that it replaces.
Automatic audio interferes with the use of screen readers, especially those that control system volume for users.
The ability to stop or hide loud, blinking or moving content is important for users with difficulty reading, intellectual disabilities & attention deficit disorders who may struggle to interact with the page otherwise.