Web Accessibility tips
These web accessibility tips can be used by web designers, developers, or content authors to guide them in creating or deploying web-based resources that are fully accessible to all users.
Add proper alt text to images.
Use alt text to provide access to the content of images for individuals who cannot see them, including people using screen readers or Braille output devices. Alt text is supported by most document formats, including HTML, Microsoft Word, and Adobe PDF. For more information, see Making Images Accessible.
Use headings properly.
Use headings and subheadings to form an outline of the page. Do not skip heading levels. They help non-visual users (including search engines) to understand how the page is organized, and make it easy for screen reader users to navigate.
Create accessible PDFs.
Use "tagged PDF", the only type of PDF that supports headings and alt text for images. Use the PDF Accessibility Checker that’s provided by Adobe Acrobat. For more information, see Creating Accessible Documents.
Know when to use PDF.
PDF preserves a document’s appearance across operating systems and devices. If this characteristic is not essential, consider using another format such as HTML, which is much more accessible.
Use ARIA landmarks.
The W3C Accessible Rich Internet Applications (ARIA) specification makes it possible to produce accessible interactive web applications. One easy entry into ARIA is landmark roles. Simply add an HTML attribute for one of the eight landmark roles (e.g., role="navigation", role="main") and users will be able to jump directly to that section of the page with a single keystroke. Alternatively, use HTML semantic elements that map to ARIA roles.
Add labels to form fields.
Use the HTML label element so screen reader users will know which labels or prompts are associated with which form fields.
Group related form fields together.
In HTML, wrap groups of checkboxes or radio buttons in a fieldset element, and wrap the question or prompt that applies to them all in a legend element.
Markup tables appropriately.
Use HTML markup properly to communicate relationships between column and row headers and the data cells within their scope. For more information, see the WebAIM article Creating Accessible Tables.
Provide sufficient color contrast.
Be sure foreground and background have adequate contrast. There are many free tools that can help with this.
Avoid using tiny fonts.
Since users may be unaware they can increase font size using browser hot keys, use a reasonably large font size by default; then, users can make it smaller if desired. Note that a font size of 1em uses the default browser font size, therefore is an ideal choice for most text, thereby honoring users’ preferences and expectations.
Respect white space.
Provide plenty of space between lines and blocks of text. This helps many users to more easily track text horizontally, and generally makes text easier to read.
Provide visible indication of focus.
In CSS, use :hover to make the page come alive, responding to user’s mouse movements. For people who aren’t using a mouse, provide the same functionality using :focus.
Use text, not pictures of text.
Use text instead of pictures of text, and control its appearance using CSS. Pictures of text become blurry when enlarged, take longer to download, and are inefficient for the website author to edit.
Think twice about the words you choose.
Keep your content simple to read and understand. Often web authors use larger words and longer sentences than is really necessary.
Captions provide benefits to all users. There are many free, easy-to-use tools available that support the process of transcribing and captioning videos. For more information, see Creating Accessible Videos.
For people are unable to see video, create a script that includes brief descriptions of important visual content, then provide that as a separate description track, either as timed text or recorded narration. This solution is known as audio description.
Provide a transcript.
Provide a transcript for video and audio so individuals who are deaf-blind and those with low Internet bandwidth can access the content. Transcripts benefit all users by allowing them to access content quickly.
Use a website navigation menu that works for all users.
When creating a navigation menu, Ask questions like: Can this menu be operated by keyboard alone? If it can, is doing so efficient or does it require dozens or hundreds of keystrokes? Consult credible resources such as the WAI-ARIA Authoring Practices for accessible design patterns and examples on how to properly code navigation menus.
- Test web pages using a keyboard.
Take the #nomouse challenge! Try navigating the web page and controlling all its features using the tab key on a keyboard; don’t touch the mouse. This simple test is typically a good indicator of accessibility. For more information, see nomouse.org.
Test pages using high contrast color schemes.
All major operating systems and some web browsers have high contrast color schemes available. When these are enabled, make sure that all important page content is still visible.
Test pages with assistive technologies.
There are free screen readers and other AT available that can be used for testing. You don’t have to become an expert user, but simple tests with AT can provide valuable insights into whether certain features on a web page might present accessibility problems. For more information, see the WebAIM article Testing with Screen Readers, as well as their series of quick guides on testing with specific screen readers.
Test pages on mobile devices.
Growing numbers of users, including users with disabilities, are accessing the web using phones, tablets, and other mobile devices. Test your website using mobile devices, and when doing so, be sure to check for accessibility.
Ask vendors specific questions about the accessibility of their products.
When procuring products from third party vendors, we are dependent on those vendors to provide products that work for all users. Always ask about accessibility of products, even for minor purchases. For major products, consider adopting a more formal process for addressing accessibility.