1. Add Alternative Text to Your Logo

Alternative text is presented to blind screen reader users in place of images they cannot see. Every image that conveys content or has a function on your web site should be given alternative text. But to get started, adding alternative text to your site logo presents your company or organization name to help users know which site they are on.

Simply find your logo image in your markup, and if it’s not present, add an alt attribute with your company or organization name as its value.

<img src="webaimlogo.jpg" alt="WebAIM - Web Accessibility In Mind">

2. Add Basic Landmarks

ARIA landmarks identify significant page areas, giving them meaning and making them more keyboard navigable. There are several available landmark types, but simply adding 3 of them – main, navigation, and search – can greatly enhance the accessibility of your page. Find the elements on your page that surround or contain the main body content, main navigation, and site search (this one will probably be a <form> element) and add the appropriate landmark role attribute (role="main", role="navigation", or role="search". If your site uses HTML5 <main> or <nav>, add the role to these elements.

<div id="maincontent" role="main">

<form action="search.php" role="search">

3. Enhance Focus Indicators

Sighted keyboard users generally navigate through the links and form fields on a web page using the Tab and Shift+Tab keys on the keyboard. To help ensure they can visually identify which link or form field they have navigated to, you can add the following to your CSS file:

a:focus {
outline:1px solid red;
background:yellow;
}

The colors may need to be customized to fit your site design, but they should be fairly distinctive.

To take this tip one step further, you can search your CSS files for a:hover and in each instance change it to a:hover, a:focus. This will ensure that keyboard users get the same visual highlighting when they navigate to items as mouse users get when they hover over an item.

4. Identify Required Form Fields

If your form has a mix of required and non-required form fields, add the aria-required="true" attribute to each input that is required. This will identify them as required to screen reader users.

<input type="text" name="username" aria-required="true">

5. Make Your Page Title an <h1>

Your page title (not to be confused with the <title> element, though this should be brief and descriptive of the page content) is generally the big, bold text typically at the beginning of the main content that describes the content or functionality of that page. While a good heading structure for your entire document is great for accessibility, simply making your main page title an <h1> will facilitate page navigation and comprehension.

6. Identify Table Headers

If your site has data tables, you can make them much more accessible by marking up table header cells appropriately. Find the row and/or column headers (almost always the cells in the first row and first column) and make sure they are marked up using the <th> element (stands for table header) instead of the <td> element (stands for table data). The <th> element should be given a scope attribute value of col if it’s a column header or row if it’s a row header.

Change <td>Date</td> to <th scope="col">Date</th>

7. Identify Table Captions

Most data tables have short descriptive text immediately before the data table that describes that table. You can associate that description or table caption to the table itself using the <caption> element. This element should be the first thing inside your <table> tag.

For example, you would change
<p>Class Schedule</p>
<table><tr>....

to
<table>
<caption>Class Schedule</caption>
<tr>....

8. Avoid "click here"

Search your site for the words "click here". This link text is ambiguous for all users, but is particularly difficult for screen reader users. It always adds additional, unnecessary text. Change the link text to be more descriptive of the content or function of the link.

For example, you would change
<a href="prices.htm">Click here</a> for prices

to
<a href="prices.htm">Prices</a>

9. Remove tabindex

Search your site's code for any tabindex attributes. If the attribute value is 1 or higher, and you're not absolutely sure why it was added or that it was added correctly, remove this attribute. Tabindex specifies a keyboard navigation order, but almost always causes more accessibility issues than it solves. If your navigation order is not logical (you can test this by navigating with the Tab key), you should restructure your underlying code so that it is logical.

10. Check Your Page in WAVE

The WAVE web accessibility evaluation tool is an easy-to-use tool that gives you feedback about your web site and facilitates additional evaluation. Simply go to http://wave.webaim.org/, enter your web page URL, and hit the button to get feedback on your page's accessibility.

This data underscores that users with low vision are very diverse. The range of vision loss varies greatly, as do the assistive technologies used. The vast majority of respondents use multiple assistive technologies, ranging from screen readers to simply changing text sizes in browsers. There is very high keyboard use in this population, strengthening arguments for ensuring keyboard accessibility.

For respondents that use a screen reader, ZoomText was the most popular, followed by JAWS and VoiceOver. Few respondents use System Access, Window-Eyes, or MAGic, and no respondents reported using ChromeVox.

Respondents report significant usage of mobile devices, with 13% of respondents using a mobile device as their primary device for navigating the web. iOS devices dominate in the mobile area, with 43% of respondents using these devices, and iOS users were more likely to use the accessibility settings of their mobile device.

Internet Explorer usage among respondents is notably higher than the overall population, perhaps suggesting lack of keyboard accessibility or assistive technology support in other browsers.

99.5% of respondents had JavaScript enabled when completing the survey.

Read the full low vision survey results at http://webaim.org/projects/lowvisionsurvey/.

The aggregate results of these surveys will be released publicly and will be used to inform design and development choices for those creating accessible web content. The surveys will remain open through March 15th.

We are excited to collaborate with Dr. Luján on WAVE development, design and analysis of additional WebAIM surveys, and other topics in the web accessibility field. It is not typical for someone to leave coastal Southern Spain to come to snowy, bitterly cold Utah in January (it snowed 4 inches last night and will be below freezing for at least the next week), so we hope the transition has not been too much of a shock for him. We’ve assured him that Northern Utah is the perfect place for him to enjoy some of his other hobbies – hiking and mountain climbing. We’re looking forward to 6 months of collaboration with such an esteemed colleague.

WebAIM continued to provide web accessibility services throughout 2012. We provided 100′s of hours of trainings, including hosting three training sessions here in Utah. Our first Advanced Web Accessibility Training session was very popular and was attended by many that had attended previous WebAIM trainings. Our web accessibility evaluation and technical assistance clients ranged from small non-profits to several Fortune 500 corporations. We are encouraged by the quickening pace and increased momentum of accessibility across the web and are happy to be a part of it.

2012 also saw the beta launch of WAVE version 5. Work continues on the beta and we’re currently well underway on WAVE APIs and updated WAVE toolbars.

Here are a few WebAIM fun facts from 2012:

• 2,531 – Posts to the WebAIM e-mail discussion list, our most active year yet
• 3,312,000 – Distinct e-mails sent via the discussion list.
• 59 – Approximate number of computer crashes caused by JAWS
• 184,000 – WebAIM blog spam comments blocked by our spam filter.
• 111,000 – Number of airline miles flown by WebAIM staff
• 366 – Days this year in which Section 508 was still not updated
• 211 – Countries represented by WebAIM web site visitors
• 379 – Gigabytes of content downloaded from the WebAIM web site
• 29% – Browser usage on the WebAIM site for three separate browsers – Firefox, Chrome, and Internet Explorer
• 1,025,000 – Number of web pages analyzed with the WAVE web accessibility tool, excluding countless millions others by the WAVE toolbar.
• 2 – Number of children born to WebAIM staff
• 372 – Approximate number of diapers changed by WebAIM staff and spouses
• 1,782 – Number of responses to our fourth screen reader user survey

Cyndi, Jon, Tom, Dio, Denise, Paige, Cecily, and I look forward to 2013 as we continue our mission of increasing web accessibility for people with disabilities.

Alternative text for images

Adding alternative text to images has always been a frustrating process in Acrobat. It usually entails viewing the document with the TouchUp Reading Order tool and searching for images that display the text “Figure – No alternate text exists.” You then have to right click on the image, select “Edit Alternate Text…”, and then type the alternative text in the provided box. This is very inefficient and time consuming, especially if a page has numerous images, or small images with overlapping alternative text. Acrobat XI now includes a “Set Alternate Text” option that allows you to add alternative text to all the images in your document at one time. It even includes the ability to identify an image as a “Decorative figure”, the PDF equivalent of alt=””.

TouchUp Reading Order Tool

There are two solid improvements to the “TouchUp Reading Order” tool. First, the number of available headings has been upgraded from 3 to 6. This is nice. While documents with sixth-level headings are not very common, I have often wished for an easier way to tag an item as an h4. An even more significant improvement is found in a single radio button that I passed over the first few times using the Acrobat XI. A new option to show “Structure types” allows you to view the tag structure of the page inline at a glance.

Several Solid Improvements

There are other accessibility features as well, including significant improvements to the accessibility “action wizard” and accessibility checker. The updated wizard quides you through several commonly-overlooked steps, including adding the document title and language, alternative text for images, etc. The accessibility checker does a better job of identifying issues that need to be checked manually and now provides helpful explanations for each rule. The export to DOC or PPT format is promising as well.

All in all, I am very pleased with the accessibility improvements in Acrobat XI. If you spend even a few hours a month modifying or creating tagged PDF files, this is a worthwhile upgrade.

We will be participating in a free webinar on Tuesday, October 9th at 11am Pacific time (2pm Eastern) to share details on these new updates and the future of WAVE. Details are available at http://www.ada-audio.org/Webinar/AccessibleTechnology/Schedule/

We want WAVE to be the most powerful and easiest-to-use web accessibility evaluation tool available, and this release is a significant update that represents several years of effort and thought. After some testing and a few feature and performance enhancements are completed, this version will soon replace the main version of WAVE found at http://wave.webaim.org/

Notable changes:

• There is now a sidebar that allows you to dynamically interact with WAVE report.
• Greatly improved processing logic to ensure that WAVE gives you useful and accurate feedback about actual end-user accessibility issues.
• Many new WAVE icons to give you feedback on additional aspects of web accessibility, including links that are missing focus indicators, missing document language, possible table captions, HTML5 and ARIA markup, and much more.
• Color contrast checking based on WCAG 2.0 Level AA, and some nifty tools to preview and modify contrast.
• Ability to filter results to WCAG AA, WCAG A, and Section 508 guidelines.
• A code panel so you can see the underlying markup of your page as you evaluate it.
• Significantly improved documentation so you can learn about web accessibility as you use WAVE.
• Much more!

We would love to hear your feedback on WAVE5. Please leave a comment below, or select the “Feedback” link in WAVE.

In the coming weeks and months we will be releasing updated WAVE toolbars, a WAVE API, and other WAVE tools.

Poor color contrast can affect everyone with vision, but has a particular impact on users with low vision. There are many tools to check for color contrast issues, such as WebAIM’s Color Contrast Checker.

Relying on color to convey content will impact blind users (page colors are not identified by screen readers), users with low vision who may override page colors, and users with color vision deficiency (or color blindness) who may have difficulty differentiating between certain colors. Checking for color reliance can be difficult and cannot easily be automated. Removing color information from the page so that it appears in grayscale allows an evaluator to more easily identify content that relies on color. We have long suggested that printing the page on a black and white printer is a good, though not particularly environmentally friendly, way to detect color reliance. Viewing the page in grayscale can also help you identify poor color contrast.

Styles for Desaturation

To make checking for color reliance and potential contrast issues easier, I put together a basic CSS file that will desaturate your entire web page to make it appear in grayscale. Simply add the following to any web page to try it out:

Preview the desaturation styles on this page (JavaScript required).

Style Details

The following CSS3 style will apply a grayscale filter:

Most modern browsers implement CSS3 via vendor prefixes, and some don’t yet support CSS3 filters, but by declaring the prefixes, using an SVG file, and a proprietary filter for Internet Explorer, the following should work in all major browsers.

The SVG file must be referenced appropriately. It is of note that the results are sometimes a bit odd in IE. These styles were primarily derived from this article.

Hopefully this will be a useful resource in your accessibility evaluation of color.

1. A shared commitment
2. A concrete policy and plan
3. Sufficient support for personnel
4. Ongoing evaluation

Shared commitment

A shared commitment to system-wide accessibility is probably the most crucial element to ensure accessibility. Almost every exemplary group has a person who has assumed the role of "accessibility champion." This person encourages others to be passionate about accessibility, but their enthusiasm is seldom enough to carry an entire organization over time. Some of this enthusiasm must be transferred to the highest level of the organization and to the people creating the content. Without administrative support, an organization lacks the necessary focus and funding. On the other hand, imposing a new accessibility policy without support from the ground level is likely to be met with resistance.

A few years ago, WebAIM provided several days of training for a very large corporation. While we are sometimes introduced by our hosts at the beginning of these trainings, the introduction at this training was very memorable. One of the company’s vice presidents took the time to provide a very enthusiastic introduction by including his own research about the importance of web accessibility worldwide and within their company. There could be little doubt in the minds of trainees that this was something that was important to the company and that it should be important to them individually.

Policy and Plan

While the decision to "be accessible" is important, a commitment to accessibility needs a more concrete roadmap. This roadmap has at least two key elements: a policy and an implementation plan.

The policy is the governance document for your group, and it will need to be reviewed and approved by the organization’s administrators or executive officers. It will probably be heavily scrutinized and will most likely be difficult to update, so it should be as succinct as possible. While policies differ, most should contain at least the following elements:

• A summary statement – This opening section should include a statement of commitment to accessibility, desired outcomes, etc. This might be the only paragraph that your president or CEO will read.
• Effective date(s) – When will the policy take effect and will it take effect at once or in phases?
• Scope – What sections will be repaired first? Are there any legacy areas which will be excluded?
• A technical standard – The pros and cons of different technical standards is an article in itself, but most standards in the US are based on the relevant-but-aging WCAG 2.0 or the terribly-dated-but-should-be-updated-in-the-next-decade Section 508. Some groups may find it beneficial to separate their policy (which should change very little and may include general language like "international standards") from their technical standard (which may change more frequently).
• Procurement – What about the things you buy? This section is often overlooked.

Once a standard has been established, an implementation plan should be put into place. An implementation plan is usually highly customized to an organization and should address issues such as timelines, budget, training, communication, etc. This document, or series of documents, should be updated more frequently than the policy.

Support

While web developers and other content creators should be included in the planning process, the reality is that the people who decide on the accessibility standard are not always the people who will be expected to create accessible content. Support must be available for web developers and other content creators. Most large groups will need a staff member or small team whose role includes web accessibility support. This requires ongoing funding, which brings us back to the need for administrative commitment.

Training within an organization is essential if efforts are to be sustainable. Training may be the most cost-intensive part of the whole effort—it includes the cost of the training provider as well as the time of every staff member in attendance. However, once this cost has been incurred, it should reduce the ongoing costs of reporting and retrofitting. Training may vary in length from a few hours for graphic designers or content creators to a day or more for developers and programmers.

Evaluation

We are often approached by groups who request a single assessment that identifies as many accessibility issues as possible. They think once they fix the issues in the report, they will be "accessible." The reality is that the type of evaluation that is most helpful depends on where you are in the process. Here are a few examples:

• An initial assessment of a small representative sample is a great way to get started. We typically recommend an audit of 20 or so pages with a report that highlights accessibility issues, explains how these issues impact individuals with disabilities, and guidance for addressing these issues. This initial accessibility audit can be used to help educate administrators or executives about the importance of accessibility. It can also help identify which sections of the site should be addressed first and can even be used to customize the training given to web developers.
• Once a policy, plan, and training are in place, a more detailed report will help identify additional accessibility issues. This report is often more detailed and technical and should be used to further refine training and support.
• Wide-scale site monitoring can be helpful once a group is well on their way to creating accessible content. Automated reporting tools are often used during this phase.
• Evaluation should not be limited to web content—the quality of the web accessibility policy and implementation should also be evaluated on a regular basis.

Take a step back

When we encounter groups that are having difficulties implementing web accessibility system-wide, I have found that it is almost always due to a shortcoming in one of the above four areas. While it’s tempting to focus your accessibility efforts on technical standards and reports, it is usually best to take a step back and evaluate the true root of the problem. If your policy is not being followed, see if it is paired with an implementation plan. If you only have budget for a comprehensive evaluation, consider a less detailed report paired with training. Most importantly, make sure that your organization shares a vision for accessibility and that your staff knows that they will receive the training and support that they need. If these four elements are addressed, the accessibility of your content will certainly improve.

There were 1782 valid responses, making this the most popular survey thus far. We hope the data is informative and will help promote more accessible web development.

A few items of note:

• JAWS is still the primary screen reader, but usage continues to decrease as usage of NVDA and VoiceOver increases.
• 98.6% of respondents had JavaScript enabled.
• The perception of free or low-cost screen readers is improving.
• The perception of accessibility of web content is decreasing.
• 72% of the respondents use a screen reader on a mobile device, up from only 12% three years ago.
• iOS device usage is significantly increasing and well above that of the standard population. Screen reader users represent a notable portion of the iOS device user market. Usage of Android devices is well below that of non-disabled users.
• The use of properly structured headings remains of great importance.
• The items that cause the most difficulty on the web remain largely unchanged over the last 2.5 years, with inaccessible Flash content and CAPTCHA being the most problematic.

View the full survey results.