WebAIM Blog

Accessibility Improvements in Adobe Acrobat XI

November 30, 2012

Our article on Abode Acrobat accessibility has recently been updated to include accessibility improvements made in Acrobat XI, the newest version of Acrobat Professional. While I often experience my fair share of frustration with Acrobat, it is the only program that I am aware of that makes accessibility improvements with each new version. Acrobat XI is no exception—it includes several new and improved features that make it much easier to create accessible PDF files.

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.

WAVE5 Beta Launch

October 3, 2012

We’re very excited to announce the launch of the newly updated beta version of WAVE version 5. Please check it out at http://five.wave.webaim.org/.

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.

Styles for Checking Color Reliance

August 31, 2012

There are two primary accessibility issues that can be introduced by using color in web pages. First, you must ensure that there is sufficient contrast between foreground and background colors. Second, you must ensure that color is not the only means of conveying content or information.

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:

<link href=”http://webaim.org/resources/desaturate.css” rel=”stylesheet” type=”text/css”>

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

Style Details

The following CSS3 style will apply a grayscale filter:

filter: grayscale(100%);

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.

filter: grayscale(100%);
-webkit-filter: grayscale(100%);
-moz-filter: grayscale(100%);
-ms-filter: grayscale(100%);
-o-filter: grayscale(100%);
filter: url(desaturate.svg#grayscale);
filter: gray;

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.

Four Keys to System-wide Web Accessibility

June 28, 2012

The main focus of the GOALS project (a partner of WebAIM) is to help institutions of higher education develop a system-wide approach to web accessibility. At the beginning of the GOALS project, we analyzed several exemplary post-secondary institutions to identify what sets these institutions apart from schools that have been less successful in implementing web accessibility. These findings helped form Recommended Practice Indicators for Institutional Web Accessibility. This document is targeted to higher education, but I think the four principles at its foundation are universal. They are (in less academic terms):

  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.

Screen Reader User Survey #4 Results

May 31, 2012

The results from our most recent screen reader user survey are now available at http://webaim.org/projects/screenreadersurvey4/.

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.

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University