# data[].attributes.attachment_link.readable_text
WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities

In-Suite Navigation
How do people who cannot move their arms use your website? What about people who cannot see well or at all? Or people who have difficulty hearing or understanding, or have other disabilities?
This resource introduces how people with disabilities, including people with age-related impairments, use the Web. It describes tools and approaches that people with different kinds of disabilities use to browse the Web and the barriers they encounter due to poor design. It helps developers, designers, and others to understand the principles for creating accessible websites, web applications, browsers, and other web tools.
This resource includes the following pages:

Stories of Web Users - stories of selected scenarios of people with disabilities using the Web, to highlight the effect of barriers and the broader benefits of accessible websites and web tools.

Diversity of Web Users - explores the wide range of diversity of people and abilities, and highlights some of the types of barriers that people commonly encounter due to inaccessible design.

Diversity in Web Use - introduces some of the techniques and tools that people with disabilities use to interact with the Web, such as browser settings, text-to-speech, voice recognition, and many more.

Accessibility Principles - introduces some of the web accessibility requirements and provides references to the international accessibility standards from the W3C Web Accessibility Initiative (WAI).

Related resources:

Web Accessibility Perspectives - short videos highlighting accessibility features that are essential to people with disabilities and useful for all.

Better Web Browsing - tips on how to customize your particular web browser and computer setup to benefit from accessibility features.

[ Top of Page | Next Page - Stories of Web Users]

Help improve this page

Please share your ideas, suggestions, or comments via email to the publicly-archived list wai-eo-editors@w3.org or via GitHub.

# data[].attributes.attachment_link.title
How People with Disabilities Use the Web: Overview ◦ Web Accessibility Initiative ◦ W3C

# data[].attributes.attachment_link.description
WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities How do people who cannot move their arms use your website? What about people who cannot see well or at all? Or people who have difficulty hearing or understanding, or have other disabilities?

# data[].attributes.attachment_link.description
Accessibility relates to how a disabled person accesses or benefits from a site, system or application. Section 508 is the governing principal; it requires that all government information be accessible to disabled users.

# data[].attributes.headline
Some tools to help test website accessibility

# data[].attributes.subject
Some tools to help test website accessibility

# data[].attributes.attachment_link.readable_text
WAVE ® is a suite of evaluation tools that helps authors make their web content more accessible to individuals with disabilities. WAVE can identify many accessibility and Web Content Accessibility Guideline (WCAG) errors, but also facilitates human evaluation of web content. Our philosophy is to focus on issues that we know impact end users, facilitate human evaluation, and to educate about web accessibility.

WAVE Browser Extensions

You can use the online WAVE tool by entering a web page address (URL) in the field above. WAVE Chrome, Firefox, and Edge browser extensions are available for testing accessibility directly within your web browser - handy for checking password protected, locally stored, or highly dynamic pages.

WAVE API and Testing Engine

The WAVE subscription API and Stand-alone WAVE API and Testing Engine are powerful tools for easily collecting accessibility test data on many pages. The stand-alone API and Testing Engine can be integrated into your infrastructure for testing intranet, non-public, and secure pages, including in continuous integration processes.

Accessibility IMpact (AIM) Report

Your Accessibility IMpact (AIM) assessment report provides detailed WAVE test data, your site's AIM score (a measure of end user impact compared to web pages generally and as determined by human testers), and expert manual test results to give you insights into the accessibility of your web site for users with disabilities.

Need more than one page at a time?

Our friends at provide an enterprise-level web accessibility evaluation system based on WAVE that gives site-wide monitoring and reporting over time.

Learn more at pope.tech.

# data[].attributes.attachment_link.description
WAVE ® is a suite of evaluation tools that helps authors make their web content more accessible to individuals with disabilities. WAVE can identify many accessibility and Web Content Accessibility Guideline (WCAG) errors, but also facilitates human evaluation of web content.

# data[].attributes.attachment_link.description
(Deprecated.) Accessibility audit and element properties.

# data[].attributes.body
Website accessibility refers to the sensitivity to the visitors of the sites. making sure that everything is legible, easy to navigate to anyone who will visit the site.

# data[].attributes.headline
Tips for Improving Website Accessibility 

# data[].attributes.subject
Tips for Improving Website Accessibility 

# data[].attributes.attachment_link.readable_text
1. Choose a content management system that supports accessibility

2. Use headings correctly to organize the structure of your content

3. Include proper alt text for images

4. Give your links unique and descriptive names

5. Use color with care

6. Design your forms for accessibility

7. Use tables for tabular data, not for layout

8. Ensure that all content can be accessed with the keyboard alone in a logical way

9. Use ARIA roles and landmarks (but only when necessary)

10. Make dynamic content accessible

1. Choose a content management system that supports accessibility.

There are many content management systems available to help you build your website. Common examples include Drupal and Wordpress, but there are many other options available.

Once you've chosen a CMS that suits your needs, make sure to choose a theme/template that is accessible. Consult the theme's documentation for notes on accessibility and tips for creating accessible content and layouts for that theme. Be sure to follow the same guidelines when selecting modules, plugins, or widgets.

For elements like editing toolbars and video players, make sure that they support creating accessible content. For example, editing toolbars should include options for headings and accessible tables, and video players should include closed captioning. The CMS administration options (such as creating a blog post or posting a comment) should be accessible as well.
Return to Tips list
2. Use headings correctly to organize the structure of your content.

Screen reader users can use heading structure to navigate content. By using headings (<h1>, <h2>, etc.) correctly and strategically, the content of your website will be well-organized and easily interpreted by screen readers.

Be sure to adhere to the correct order of headings, and separate presentation from structure by using CSS (Cascading Style Sheets). Do not pick a header just because it looks good visually (which can confuse screen reader users); instead, create a new CSS class to style your text.

Examples of proper use of headings:

Use <h1> for the primary title of the page. Avoid using an <h1> for anything other than the title of the website and the title of individual pages.

Use headings to indicate and organize your content structure.

Do not skip heading levels (e.g., go from an <h1> to an <h3>), as screen reader users will wonder if content is missing.

Return to Tips list
3. Include proper alt text for images.

Alt text should be provided for images, so that screen reader users can understand the message conveyed by the use of images on the page. This is especially important for informative images (such as infographics). When creating the alt text, the text should contain the message you wish to convey through that image, and if the image includes text, that text should also be included in the alt.

The exception to this rule is when an image is used purely for decoration; in this case, the alt text can be left empty so that the screen reader user is not distracted from the more important content on the page.

If an image is the only content of a link, the screen reader will read the file name if alt text is not provided. Always provide alt text for images that are used as links.
Return to Tips list
4. Give your links unique and descriptive names.

When including links in your content, use text that properly describes where the link will go. Using "click here" is not considered descriptive, and is ineffective for a screen reader user.

Just like sighted users scan the page for linked text, visually-impaired users can use their screen readers to scan for links. As a result, screen reader users often do not read the link within the context of the rest of the page. Using descriptive text properly explains the context of links to the screen reader user.

The most unique content of the link should be presented first, as screen reader users will often navigate the links list by searching via the first letter.

For example, if you are pointing visitors to a page called "About Us":

Try not to say: "Click here to read about our company."

Instead, say: "To learn more about our company, read About Us."

Return to Tips list
5. Use color with care.

The most common form of color deficiency, red-green color deficiency, affects approximately 8% of the population. Using ONLY colors such as these (especially to indicate required fields in a form) will prevent these individuals from understanding your message.

Other groups of people with disabilities, particularly users with learning disabilities, benefit greatly from color when used to distinguish and organize your content.

To satisfy both groups, use color, but also be sure to use other visual indicators, such as an asterisk or question mark. Be sure to also distinguish blocks of content from one another using visual separation (such as whitespace or borders).

There are several tools you can use to evaluate color contrast, which will assist you in making your page as visually usable as possible to individuals with low vision or varying levels of color blindness.
Return to Tips list
6. Design your forms for accessibility.

When form fields are not labeled appropriately, the screen reader user does not have the same cues available as the sighted user. It may be impossible to tell what type of content should be entered into a form field.

Each field in your form should have a well-positioned, descriptive label. For example, if the field is for a person's name, it should be labeled appropriately as either "Full Name" or have two separate fields labeled as "First Name" and "Last Name." Use the <label> tag or an ARIA property (see tip #9) to associate the label text with the form field.

As you are going through a form field, a person should be able to tab through the form and fill out all the fields before getting to the "Submit" button, or they may not even realize that additional fields exist. Essentially, the tab order should follow the visual order.

If you have fields that are related or similar, consider grouping them together using fieldsets. For example, fields like "Full Name" and "Date of Birth" could be grouped together as "Personal Information." This type of form organization can help a screen reader user keep track of progress, and can provide the context that might be lost while filling out the form.

If certain form fields are required, the field should be labeled accordingly, and configured to alert the screen reader user. Commonly, required fields are noted as such with an asterisk, which will not be spoken by some screen readers. Asterisks (or similar visual indications) should still be used for sighted users, people with learning disabilities or people who speak English as a second language. Indicating that a field is required to a screen reader can be accomplished by adding ARIA required="true" and ARIA required="false" for optional fields. After submitting the form, user will need to be alerted to submission confirmation and any submission errors. We recommend including any error counts in the page title (after the user has submitted), so the user will immediately be informed that there are errors on the page. If a user submits a form with errors, the user should be brought to a submission page that indicates what the errors are, and provides an easy way to navigate to those errors.

Finally, the use of CAPTCHA is inaccessible and should not be used to validate submissions. WebAIM has a helpful summary of accessible alternatives to CAPTCHA to keep forms free of spam submissions.
Return to Tips list
7. Use tables for tabular data, not for layout.

Using tables for page layout adds additional verbosity to screen reader users. Whenever a screen reader encounters a table, the user is informed that there is a table with "x" number of columns and rows, which distracts from the content. Also, the content may be read in an order that does not match the visual order of the page. Do not create the layout of a website using a table; instead, use CSS for presentation.

When a data table is necessary (i.e. you have a set of data that is best interpreted in a table format, such as a bank statement), use headers for rows and columns, which helps explain the relationships of cells. Complex tables may have several cells within the table that have a unique relationship to each other, and these should be identified by using the "scope" attribute in HTML. Table captions (HTML5) can be used to give additional information to users about how best to read and understand the table relationships.
Return to Tips list
8. Ensure that all content can be accessed with the keyboard alone in a logical way.

Users with mobility disabilities, including repetitive stress injuries, may not be able to use a mouse or trackpad. These people are able to access content through the use of a keyboard by pressing the "tab" or "arrow" keys, or through the use of alternative input devices such as single-switch input or mouth stick. As a result, the tab order should match the visual order, so keyboard-only users are able to logically navigate through site content.

Long pages with lots of content should be broken up with anchor links (jump lists), allowing keyboard-only users to skip to relevant portions of the page without having to negotiate through other content. "Skip to main content" should be provided at the top of each page, so keyboard-only users won't have to tab through the page navigation in order to get the main content.

For pages with local menus and multiple levels and sub-items, the menus should be configured so that all menu items can be accessed with the keyboard. Do not use elements that only activate when a user hovers over items with a mouse, as keyboard-only or screen readers users will not be able to activate them.
Return to Tips list
9. Use ARIA roles and landmarks (but only when necessary).

ARIA (Accessible Rich Internet Applications) is a complex, powerful technical specification for adding accessibility information to elements that are not natively accessible. You should always use native HTML elements when they are available. Remember, the first rule of ARIA is "Don't use ARIA." Many functions that used to require ARIA attributes are now implemented in HTML5.

For example:

Use the native HTML button tag instead of the ARIA role of button.

Use the HTML label tag instead of aria-label or arial-labeledby.

Use the HTML 5 nav tag instead of the ARIA role of navigation.

ARIA attributes can be added to your HTML, in the same way that you add classes to HTML in order to load attributes from CSS.

Please note that just adding ARIA attributes is not sufficient to make most complex widgets accessible. ARIA does nothing for keyboard-only users (see #8 tip); it only affects people using assistive technology. You still need to set up your interactions and behaviors using Javascript.

Examples of appropriate ARIA usage include:

Adding alerts to notify screenreader users of dynamic page changes, such as stock tickers and search filters.

Making complex, interactive widgets such as date pickers accessible to screenreader users.

Return to Tips list
10. Make dynamic content accessible.

When content updates dynamically (i.e. without a page refresh), screen readers may not be aware. This includes screen overlays, lightboxes, in-page updates, popups, and modal dialogs. Keyboard-only users may be trapped in page overlays. Magnification software users might be zoomed in on the wrong section of the page.

These functions can easily be made accessible. Options include ARIA roles and alerts, as well as front-end development frameworks that specifically support accessibility.

Ensure that video players do not auto-play (non-consensual sound), and that the players can be used with a keyboard. Additionally, all videos must have options for closed captioning and transcripts for the hearing-impaired.

If your site contains a slideshow, make sure that each photo has alt text and can be navigated via the keyboard. If you are using any unique widgets (such as a calendar picker or drag-and-drops), be sure to test for accessibility.
Return to Tips list

# data[].attributes.attachment_link.title
Top 10 Tips for Making Your Website Accessible

# data[].attributes.attachment_link.description
Choose a content management system that supports accessibility Use headings correctly to organize the structure of your content Include proper alt text for images Give your links unique and descriptive names Use color with care Design your forms for accessibility Use tables for tabular data, not for layout Ensure that all content can be accessed with the keyboard alone in a logical way Use ARIA roles and landmarks (but only when necessary) Make dynamic content accessible There are many content management systems available to help you build your website.