Web Accessibility Tips


Non-focusable Links

Links within a page are used to trigger an action, such as navigating to another web page or to another location within a page. The href attribute of the link generally defines where the link will navigate to. In modern web applications, the href attribute is often omitted and scripting is instead applied to links to cause them to perform an action. Links without an href attribute cannot be navigated to using the keyboard because the browser assumes the link has no function. Ensure that all interactive links have an href attribute or are given a tabindex="0" attribute so they can be navigated to using the keyboard.


Link and Button Roles

Buttons should only be used when form data is being submitted or when other in-page elements are being controlled or manipulated. Links, on the other hand, should be used when a context change will occur for the user - such as going to another page or jumping to another position within a page. Because links and buttons are identified differently by screen readers (e.g., "Search link" versus "Search button"), they should be used appropriately (i.e., links to do link functions and buttons to do button functions). Sometimes constraints may make it difficult to use the appropriate element. In these cases, role="link" or role="button" can be added to cause the element to be identified appropriately in screen readers.


Quick Contrast Checking

While WCAG 2.0 outlines specific requirements for contrast between text and background colors, these can sometimes be difficult to test, though tools make this easier. Common sense and some basic testing can usually be used to identify potential contrast issues. Printing the page on a black/white printer, decreasing your screen brightness (this is particularly helpful on mobile devices), and even squinting while viewing the page can make contrast issues more apparent.


ARIA Design Patterns

ARIA (Accessible Rich Internet Applications) defines a way to make complex interactive widgets accessible. When building an ARIA-enhanced widget (such as a slider or complex menu), it is vital that the keyboard interaction with that element follow prescribed guidelines so the user knows how to interact with it. The ARIA Specification outlines interaction design patterns for all ARIA elements.


HTML5 Main Element

HTML5 currently allows the newly defined <main> element to be used to identify the main content area of a web page. This element should be present on nearly all HTML5 pages. It can greatly facilitate navigation directly to the content area of pages by keyboard and screen reader users. For pages that are not yet HTML5, the ARIA role="main" can be added to the main content area to provide similar functionality.


HTML5 and Captioning

A primary issue with captioning has always been the wide variety of caption data formats. Each media player supports a different format for captioning. This has made authoring and converting of caption data difficult. In HTML5, audio and video natively support captioning using the WebVTT standard. While WebVTT is still in development, it provides a basic structure for captioning that, when full supported by browsers, will provide a universal format for all HTML5 video.


CSS3 Transitions and Animation

CSS3 allows new forms of animation and transitions. These transitions are purely visual, so they do not interrupt screen reader or keyboard reading or functionality. However, the animations can cause distraction, confusion, or disorientation, particularly for users with some cognitive or learning disabilities. These transitions are also sometimes used to convey content or meaning (such as through animating images or by providing visual associations between content). Because accessible content cannot generally be presented using CSS, alternative content or versions would likely be necessary.


Are "Skip" Links Still Necessary?

"Skip to main content" or "skip navigation" links provide a mechanism for keyboard users to jump over repetitive navigation directly to the main content of a page. Headings, ARIA landmarks, HTML5 structural elements (particularly <main>), etc., also provide elements which users can navigate to get to main content, but navigation by these elements is not yet supported in standard browsers for sighted keyboard-only users who are not using screen readers. Because of this, "skip" links still provide very useful functionality for sighted keyboard users. "Skip" links can, however, be hidden visually until they receive keyboard focus.


Carousels and Accessibility Issues

Many websites, particularly home pages, contain carousels - a section of the page that automatically rotates through a series of images or content. Carousels can often introduce accessibility issues, especially for screen reader users. In order to make a carousel accessible, several things must occur:

  • It must be accessible using only a keyboard.
  • Users must be able to pause and resume the carousel.
  • The information contained in the carousel must be readable by screen readers.
  • It needs to be designed so that the user will not encounter problems if it updates when the user is reading or has keyboard focus on it.

The accessibility of a carousel should always be tested in a screen reader.


Motor Disabilities

Some users have motor disabilities that make it difficult or impossible to use a standard keyboard or mouse. Although these users may rely on any number of assistive technologies to interact with a computer, the computer will generally treat these devices as either a mouse or a keyboard. All of these devices interface with a computer in one or more of the following ways:

  • Uses a mouse or pointing device. This includes trackballs, eye tracking, or other devices that behave like a mouse.
  • Uses a keyboard, including adaptive keyboards.
  • Uses speech recognition.

Ensure that you web site interfaces are accessible to these technologies.


Screen Magnification

Low vision (vision that cannot be corrected to normal levels with glasses or contact lenses) can be caused by a variety of conditions including glaucoma, cataracts, and macular degeneration. Many users with low vision use screen magnification software to enlarge content on the screen. Screen magnification software may also be used to change the default color scheme and read content out loud. Keep the following principles in mind while designing for users with low vision.

  • Use true text instead of text within a graphic text when possible.
  • A proper heading structure can make it easier to navigate large blocks of text.
  • A flexible page layout that allows for multiple page widths will reduce the need for horizontal scrolling.
  • Succinct text, especially link text, can reduce the need for scrolling.

Consider Multiple Disabilities

An area of web accessibility that is often neglected is considering the needs of users with multiple disabilities. While addressing the needs of users with distinct disabilities is relatively straightforward, meeting the needs of users with multiple disabilities introduces some complex considerations. Here are a few of many combinations to consider:

  • Users that are deaf and blind can perceive content through a refreshable braille display (typically connected to screen reader software). Content that is accessible to users that are blind and also accessible to users that are deaf, generally meets the needs of deaf-blind users. However, a few unique considerations are needed, particularly for media where only a transcript can provide sufficient accessibility. Additionally, a graphical CAPTCHA that provides an audio alternative cannot be made accessible to a user that is both deaf and blind.
  • A flashing banner advertisement (while certainly distracting) likely falls below the minimal size requirement that may cause a photo-epileptic seizure. But what about a user with photosensitive epilepsy and low vision that may magnify the flashing image so that it exceeds the size threshold?
  • Screen readers are complex software. Modern web applications often introduce complex keyboard interactions. This combination may introduce difficulties for a user that is blind and also has a cognitive or learning disability.

Avoid Using Too Many Links

A page with a large number of links can be very difficult for some users to navigate. Screen reader users, as well as some users with cognitive disabilities, may be overwhelmed by the number of links that are presented. Users with motor disabilities may find navigation tedious (imagine navigating through 100 links using a stick in your mouth), and the effectiveness of speech recognition software can be diminished (e.g., Dragon NaturallySpeaking has difficulty with pages that have more than 200 links).


Use Unique Link Text

Screen reader users and users of speech recognition software rely on link text to navigate through links on a webpage. Not only does link text need to be descriptive, it needs to be unique to the page. Navigation by links can become difficult if multiple links use the same text, or even begin with the same text. Generic text at the beginning of a link should generally be removed wherever it occurs (e.g., "click here for...", "visit...", "read more about...", "more information on...","go to...", etc. ), and links with the same text should be avoided (e.g., "Visit this site's homepage" could be changed to "NASA homepage").


Small Text

WCAG 2.0 does not provide requirements for text sizes. It is easy to overlook the impact that small text has on web site users, particularly those with low vision. Because text sizes vary based on the font face in use, the user's display, viewing distance, etc., use common sense in determining if text is likely small enough to cause issues. As a very general rule, text that is sized smaller than 10 pixels in height tends to cause readability issues for many users.


Modal Dialogs

A modal dialog is a window that opens within a web page that requires user interaction. The underlying page is typically hidden or greyed out until the user dismisses or interacts with the dialog window content. While very helpful for presenting or soliciting important information, they can be very difficult for screen reader users. A few guiding principles:

  • When a modal dialog opens, focus should be set to the dialog using JavaScript so the screen reader user can begin reading or navigating within the dialog.
  • Keyboard focus must be trapped within the dialog. You do not want the user to read or navigate content from the underlying page.
  • The dialog should be easily dismissible. A prominent "close" button or link, as well as closing with the Esc key, should be provided.
  • If the dialog is closed or dismissed, focus should be set back into the underlying page at a location that is logical (typically on the link or button that triggered the dialog).

Image Sprites and Accessibility

An image sprite is a collection of images that are put into a single image file. This allows the end user to download one large file containing multiple images, rather than downloading multiple image files, thus saving bandwidth and processing time. To present a particular image from within the sprite, the sprite image is defined as a CSS background then positioned to display the appropriate portion.

Because alternative text cannot be provided directly for background images, background sprites are inherently inaccessible. However, a text alternative to an image sprite may be presented in content, but hidden using CSS. For example, a link to a PDF file may present an icon to indicate that it is to a PDF file. If the PDF icon is presented as a sprite background image at the end of the link, the link markup could be <a href="app.pdf">Employment Application<span> - PDF file</span></a>. The text within the span could then be hidden off-screen using CSS. Sighted users would see the CSS background icon while screen reader users hear the "- PDF file" text.


Accessibility, Code Validation, and WCAG 2.0

Valid code, meaning code that follows the HTML and CSS specifications, supports accessibility. Valid code, however, does not ensure accessibility. WCAG 2.0 does not require valid code (use the W3C validator to test your page), but does require that significant parsing errors (such as incomplete start and end tags, improperly nested elements, etc.) are avoided. While well-intentioned, if a code validation error results in a true accessibility issue for end users, it is almost always addressed elsewhere in WCAG 2.0.


Programmatically Determined

The term "Programmatically Determined" is found frequently in WCAG 2.0. As defined in the specification, "This means that the content is delivered in such a way that user agents, including assistive technologies, can extract and present this information to users in different modalities." In short, it means that even a computer can figure it out. As an example, WCAG 2.0 has a Level A success criteria that allows ambiguous links, such as "Read More" or "Continue", if the "programmatically determined" link context provides an adequate description. So if a heading previous to the link or the surrounding text or a table header describe the link, then this is acceptable.

A fundamental issue with this approach to accessibility is that just because a computer could determine the context of the link from its programmatic context doesn't mean that it actually does so. The reality is that these links require additional user interaction and effort - the user must navigate or visually scan before or after the ambiguous link to find its description. So while such a presentation may be WCAG Level A conformant, consider the impact on actual end users.


Labeling ARIA Landmarks

ARIA landmarks can define significant web page areas (such as the main content, navigation, search, etc.) and provide navigation to them. In most cases, the type of landmark is sufficient to identify the page area (e.g., it is apparent that the search landmark is for search functionality). However, if a page contains more than one of the same type of landmark (e.g., multiple navigation sections), a label can be useful to differentiate them (e.g., main navigation, as opposed to sub-navigation). If a landmark begins with a heading, use aria-labelledby on the element to reference that heading (e.g., <form role="search" aria-labelledby="searchheading"><h2 id="searchheading">Site Search</h2>). If not, you may use aria-label (e.g., <ul role="navigation" aria-label="Main navigation">) to provide a brief description.


ARIA Presentation Role

ARIA's role="presentation" can be used to neutralize or remove the semantics of HTML elements. Any element (or its child elements) that are assigned role="presentation" will be presented without structure or meaning, like HTML <div>s and <span>s. This can be useful if you are using HTML elements to build other interactive controls, such as using a <ul> to structure and style a group of interactive checkboxes, or a <table> to create an interactive ARIA grid. One would not want the list or table to be presented to a screen reader user.

Care must be taken to re-assign semantics to elements within a role="presentation", if needed. For example, if a <table role="presentation"> contains an actual list, that list will need to be given role="list" so it is presented correctly to screen reader users.


Hiding Content with ARIA

The aria-hidden="true" attribute will hide content from screen reader users, even if that content is visually presented within the page. It is very rare that one would present content visually that would not be presented to screen reader users. In nearly all cases, content with aria-hidden="true" should be hidden from all users using CSS display:none.

Sometimes content (such as form error messages) can be hidden or revealed based on the user interaction. With ARIA and CSS, a developer can focus on changing semantic ARIA values while allowing CSS to toggle the visual presentation. CSS of [aria-hidden:true] {display:none} will hide content when aria-hidden has a value of true. By toggling an element's aria-hidden value between true and false, the content will automatically display or hide visually as well.


Invalid Form Controls

Presenting invalid form controls (form controls that have a known error, such as a required field that the user has not entered) in an accessible way introduces unique accessibility challenges. Typically color (such as a red text label and/or a red border) can provide a distinctive visual indication of the errant control, but this is not accessible to screen reader users. Other approaches involve adding descriptive error text to the form label, which can be overwhelming visually.

By adding the aria-invalid="true" attribute to the errant control, a screen reader will identify the control as being invalid. This provides for much more simple and accessible form error identification.


Disabled Form Controls

Form controls are sometimes disabled to prohibit user interaction or modification. Form controls that have been given a disabled (or disabled="disabled") attribute have accessibility issues. First, most browsers present the controls with very low contrast levels, making the form values very difficult to read. Second, disabled form controls are removed from the keyboard navigation flow - a user cannot 'tab' to them, and thus may be unaware that they are even present, particularly if using a screen reader.

By using aria-disabled="true" instead of the HTML disabled attribute, the control will remain in the keyboard navigation flow and will be identified as being disabled to a screen reader user. One could then style the control to visually appear disabled, without resorting to the default low-contrast presentation. You can even use [aria-disabled=true]{opacity:.6} or similar in CSS to style the control based on its ARIA attribute. Adding aria-disabled="true" does not actually disable the form control (one would likely need to use JavaScript to do that), but it does address several accessibility concerns.


Identifying Pop-up Windows and Dialogs

There is no accessibility requirement to identify links or buttons that open new windows or dialog prompts (though if there is a visual indication of this, it should also be made accessible to screen reader users). However, it can be helpful for users, particularly screen reader users, to know that a link or button will open such a pop-up, as opposed to taking them to another page or submitting a form. Simply adding aria-haspopup="true" to the link or button that opens the pop-up will cause the screen reader to identify that the control will open a pop-up window or dialog.


Consider Sighted Keyboard Users

While it is very important to remember the needs of screen reader users when creating web content, it is also important to remember the needs of the many users who have sight, but rely on a keyboard due to a motor disability. Links, including "skip" links that allow users to jump over repetitive navigation, should never be hidden visually.

  • Various techniques are used to hide content off-screen using CSS so that it is only read by screen readers. While this can be an appropriate technique, putting a link in hidden text can cause the view to change when the link receives focus, but the link itself will not be visible (unless the text becomes visible when it receives keyboard focus).
  • Links are sometimes placed in 1 pixel by 1 pixel images, but these images are not visible to sighted keyboard users (or may appear as a very tiny box). These should be avoided.
  • Rollover menus (menus that expand when the user hovers over them with a mouse) are sometimes designed so that the user has to navigate through all the options with a keyboard, but the menus do not expand visually when they receive keyboard focus. This can be especially confusing for sighted keyboard users because these menus often contain dozens of links, making them both confusing and time consuming. Additionally, if these menus do not expand, the user has no idea how many options are in the sub menu without navigating through all of them. It could be ten, or it could be a hundred. If these menu options can be navigated with a keyboard, they need to be visible as well.

"Rollover" Menus and Keyboard Accessibility

Rollover menus (menus that expand when the user hovers over them with a mouse) can be made accessible in one of two ways. First, the entire menu, including all sub-menus, should be keyboard accessible. While this approach can be best for menus with a few options, a keyboard user may be forced to navigate through dozens of items on the page before accessing the main content of the page, making it very cumbersome. The second, and generally optimal, approach is to NOT make the entire menu keyboard accessible, but to instead make the top level of the menu a standard link to a page that provides links to the same pages as the sub-menus. This requires an extra navigation step, but in this case it is easier and more accessible. This approach also works optimally for users of touch screen devices.


Keyboard Trap

An interface should not trap focus so that a keyboard user cannot interact with other page elements. By using scripting to change standard keyboard navigation mechanisms (typically by setting focus to page elements), keyboard users can easily be trapped. When testing a page with the keyboard, ensure that you can interact with all page elements. And ensure that you can navigate both forward (typically Tab key) and backward (typically Shift + Tab) key through all interactive controls.


Empty or Value-less Buttons

With the increasing prevalence of CSS, it is becoming more common to see buttons that have use CSS to display a background image instead of the default browser button. Because all buttons perform a function, they must present meaningful, descriptive text for screen reader users. When CSS is used to style a button, the button still must have a value (<input type="submit" value="Search">) or text (<button>Register</button>) to ensure that this information is read by screen readers and is visible when images do not load or are disabled.


Ambiguous Buttons

Much is written on the impact of ambiguous links (such as "click here") on accessibility. Modern web pages and web applications, however, seem to be increasing in the number of ambiguous "Go" buttons that are being used. Such buttons do not generally provide a description of what the button does. This is particularly troublesome when multiple "Go" buttons appear on the same page. Simply replacing "Go" with descriptive text (such as "Search" or "Sign In") provides a more accessible experience for all users.


JavaScript Jump Menus

Select menus (drop-down form controls) are sometimes modified with scripting so that selecting an item from the menu automatically directs the browser to a new web page. While these "jump menus" can provide handy navigation controls, they also pose accessibility issues for keyboard users. In some browsers (particularly Internet Explorer), if a keyboard or screen reader user navigates within the select menu (typically by pressing the up or down arrow keys), a single keystroke triggers the browser location change. This makes it very difficult to navigate to distinct items from the menu without being redirected to all of the previous pages in the menu. This issue can easily be addressed by removing the scripting from the select menu and presenting a standard button adjacent to the select menu. The user can then select the desired item from the list, then activate the button to go to that page.


Acronyms and Abbreviations

Acronyms and abbreviations should generally be expanded in text the first time they are presented - for example, "WCAG (Web Content Accessibility Guidelines)". Commonly known acronyms or abbreviations (such as US for United States) may not need to be expanded at all. Similarly, acronyms or abbreviations for which an explanation is unlikely to help clarify may not necessitate an expansion (for example, knowing that HTML is HyperText Markup Language may cause more confusion than assistance).

HTML provides the <acronym> and <abbr> elements (in HTML5, only <abbr> is allowed). The title attribute value should present the expanded content (e.g., <acronym title="Web Content Accessibility Guidelines">WCAG</acronym>. Screen reader support for these elements varies, with most screen readers not reading the expansion with the default settings enabled. If one wishes to use one of these elements, it should typically only be used on one (typically the first) instance per page rather than on all instances (if a screen reader is set to read the expanded text, it would then do so on all instances which would be burdensome).


Be Careful with Fieldset

While the <fieldset> element is often used to organize groups of checkboxes or radio buttons, they do have their limitations and accessibility issues. Keep the following issues in mind when using fieldsets:

  • While screen readers have varying support for fieldset <legend>s, some screen readers will repeat the legend for every form control within the fieldset. While this may be appropriate for a grouping of checkboxes or radio buttons, it can quickly become tedious for large forms (and is especially problematic for fieldsets within other fieldsets, which should generally be avoided). For this reason, legends should be succinct and only provided when necessary for understanding the form controls within the fieldset.
  • In Internet Explorer, long fieldsets will not wrap to another line. Instead, they create a horizontal scrollbar and break some layouts. This, combined with the first issue, makes fieldsets unsuitable for most multiple-choice tests or survey questions.
  • Styling of fieldsets in CSS is somewhat limited. Their use could negatively impact some visual designs.

Fieldsets should generally be limited to describing groups of checkboxes and radio buttons. If these constraints make the use of fieldset inappropriate, consider the use of ARIA labeling techniques, such as aria-labelledby or aria-describedby.


Transparent Backgrounds and High Contrast

GIF and PNG images used on the web often have a transparent background. This is useful when the web page background has a pattern or gradient, but if a user with low vision changes or inverts the background color, these images can become unreadable. For example, a logo that contains black text and a transparent background may be highly visible on a light background, but it is hidden completely if the user changes the page so that it displays white text on a black background. You can test for this issue by enabling the high contrast settings in your operating system and evaluating your own web site. If some of your images become difficult to read, change the image design so that it is readable regardless of the background color.


Screen Reader and Browser Combinations

Most popular screen readers perform best with a specific browser. For example, JAWS for Windows typically performs best with newer versions of Internet Explorer. NVDA, a free screen reader for Windows, works better with Firefox. VoiceOver, the free screen reader built into the Mac operating system, will only work with Safari. When evaluating web content for accessibility, ensuring that you are using the correct browser/screen reader combination will produce the best results.


Getting Started with Screen Readers

Mastering a screen reader is difficult, but getting started with a screen reader is simple. All you really need to know is how to start and stop reading content on the page. In both JAWS and NVDA, pressing the down arrow key will read the current line, and pressing Insert + down arrow will cause the screen reader to keep reading. In VoiceOver for Mac, pressing control + option + arrow key will read the current line, and control + option + A will cause it to keep reading. In all three screen readers, pressing the control (Ctrl) key will cause it to stop reading.


Using Headings in Microsoft Word

A good heading structure is probably the most important accessibility consideration in the majority of Microsoft Word documents. Headings allow screen reader users to navigate through the page easily and make the page more usable for everyone. Many people do not use true styles in Word. For example, when creating a heading, they simply change the font, enlarge the font size, make it bold, etc. If this is done, the document has no real structure that can be discerned by a screen reader. In Word, the correct way to provide structure is to use Word "Styles" panel. You can also add 1st, 2nd, or 3rd level headings using Ctrl + Alt + 1, 2, or 3 (Cmd + Option on a Mac).


Create Accessible PDF Files

While there are many ways to create a PDF file, not all of these methods will result in a file that contains correct accessibility information. "Printing" to PDF will create a completely inaccessible file--basically a big scanned image--and is never recommended. In Office 2010 for Windows, selecting Save > Save as type: > PDF will preserve accessibility information such as headings and alternative text. If Adobe Acrobat is installed, you can also select Create PDF from the Acrobat ribbon to create an accessible PDF (assuming the original file is accessible). It is still a good idea to check the final PDF file in Acrobat Professional (if available). Unfortunately, saving a PDF file in Office for Mac does not result in a tagged PDF file.


Check Accessibility in MS Office and Acrobat

While no automated accessibility tester can guarantee accessibility, they are useful in assuring that nothing has been overlooked. Microsoft Office 2010 for Windows includes a very capable accessibility checker, as does Acrobat X and XI. To check accessibility in MS Word or PowerPoint, select File > Info > Check for Issues > Check Accessibility and an accessibility checker will open in a sidebar. This checker notifies the user of potential issues such as missing alternative text or unclear link text.

Acrobat Professional X includes two different Accessibility Checks. The first, the Quick Check, is not very helpful and should not be used. The accessibility "Full Check" (available in both Acrobat X and XI) is a much better option. This can be a good tool to ensure that nothing was overlooked (e.g., document language and alternative text). To run the full check, select Tools in the right-hand column > Advanced > Accessibility > Full Check. The Accessibility check in version XI is a bit more complete than version X and provides better documentation.


Adding Alternative Text in Microsoft Office

Adding alternative text to an image in Microsoft Office is a pretty straightforward process once the correct method is identified. Unfortunately, the correct method is not always clear. For example, in Office 2010 for Windows, select the image and then right click on the image and choose the Format Picture option. With the Format Picture menu open, select the option for Alt Text in the sidebar. Two fields will appear, one labeled Title and one labeled Description. Although it would appear that the Title field would be the best place to put alternative text, it is not. Information in the Title field will not be saved as alt text when the file is saved as HTML or PDF. Put alternative text in the second box labeled Description. In Office 2011 for Mac, the process is similar, but you will need to remove the image filename (e.g., "logo.gif") from the Description field before adding alternative text.


PowerPoint Accessibility Principles

When creating PowerPoint presentations, keep the following principles in mind:

  • Using the pre-formatted slides (e.g., title and subtitle, title with two columns) will almost always provide better accessibility than starting with a blank slide. It will ensure that your files have correctly-structured headings and lists, proper reading order, etc.
  • Ensure that font size and contrast are sufficient, especially if your presentation will be viewed on a projector.
  • Avoid automatic slide transitions and ensure that animations and transitions are simple.
  • Do not save a PowerPoint in HTML, or any other 'web' format. Converting the file to PDF and adding additional accessibility enhancements to the PDF often provides the most accessible presentation format.

Acrobat "Touch Up Reading Order" Tool

The two most important issues in in PDF accessibility are correct tag structure (PDF "tags" contain the accessibility information for screen readers) and correct reading order. The best way to evaluate and repair these two issues is with the Touch Up Reading Order tool in Acrobat Professional. To use the Touch Up Reading Order tool, select Tools from the right-hand menu, then select Accessibility > Touch Up Reading Order. If the Accessibility menu is not visible (it is hidden in version XI by default), make sure it is checked in the option menu in the upper-right corner of the Tools sidebar.

This tool can be used to change or update common tags such as headings, figures (or images), and tables. It will also display the current reading order of a page. If the order is not correct, select the Show Order Pane button to fix these issues.


Evaluate Your Accessibility Policy and Implementation

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. For example, an evaluation of your implementation process may help you uncover that your budget is insufficient, or that training of new staff needs to be improved. This evaluation should be used to help you improve or update your accessibility goals, objectives, milestones or other activities.


Components of a Successful Policy

A commitment to accessibility is seldom successful if it is not written down, usually in an accessibility policy. While the contents of an accessibility policy can vary, most successful policies contain 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 site areas will be repaired first? Are there any legacy areas which will be excluded?
  • A technical standard Most standards in the US are based on WCAG 2.0 or 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 purchase? This section is often overlooked.

Four Keys to System Wide Accessibility

An organization is more likely to successfully implement accessibility if the following four key factors are in place:

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

While these are not necessarily steps, the principles do build on one another. Creating a policy is difficult without administrative commitment. Training and other support will probably be lacking unless the need is identified and planned for in advance, etc.


Sufficient Time and Effort Allocation

Every organization faces time and budget constraints, but implementing web accessibility takes time and effort. This means accessibility will need to be identified in the role description and funding sources of key staff. This may include some web developers and accessibility support personnel, as well as less obvious positions such as those in purchasing, IT, HR, and training.


Need for Both Administrative and Grassroots Commitment to Accessibility

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.


Provide Support for Staff

All personnel must be provided with the knowledge, support, and materials they require to carry out their roles in implementing institution-wide web accessibility. Support can be provided in a number of ways, including the following:

  • Provide training that is appropriate for their duties (e.g., developers may receive a full day of training, support staff may receive two hours of less technical training).
  • Have an individual or team available to answer any questions.
  • Make support materials such as handouts or additional training available.
  • If necessary, provide staff opportunities for additional professional development (e.g., attend additional training or conferences).
  • Implement incentives and give recognition.

Require Accessibility in Contracts

Just as Section 508 outlines accessibility requirements of any electronic and information technology procured (or purchased) by the federal government, your organization should require a high level of accessibility in everything your purchase. Accessibility requirements should be outlined in contracts and other communication with all vendors and contractors--it sends a clear message that accessibility is important and may also provide some protection to your organization if a vendor's accessibility claims are not accurate.

If you currently have a contract to use an inaccessible product, let the vendor know that you care about accessibility, and that it will be a deciding factor in selecting a comparable product in the future.


A Web Accessibility Policy Should be Succinct

A web accessibility policy 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. It may also be made public, so ensure that the policy is attainable.


Accessibility Implementation Plan

Once a technical standard has been determined and an accessibility policy created, 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 regularly.


Legal obligations

While fear of a lawsuit should not be the only motivation for an accessible website, understanding your legal obligation can be important. In 2010, the Department of Justice made the following statement: "There is no doubt that the Internet sites of state and local government entities are covered by Title II of the ADA. Similarly, there is no doubt that the websites of recipients of federal financial assistance are covered by Section 504 of the Rehabilitation Act. The Department of Justice has affirmed the application of these statutes to Internet sites...in numerous agreements with state and local governments and recipients of federal financial assistance."

ATAP