Begin site navigation:
End site navigation.
Child using a symbol-based tablet. Testing combines a combination of semi-automatic and manual methods, listed below.
You do not need to follow the list in the order in which it is presented, or complete each type of testing every time. Rather, as you become more familiar with incorporating accessibility measures into your design, you will know what things too look for, and what items you have mastered. Nonetheless, your pages and applications are expected to comply with these testing methods even if you omit certain steps.
Well-formed, standards-compliant HTML provides the foundation for an accessible Web site. Your markup, syntax and style sheets should pass these W3C validators without errors:
Make sure you are coding to the proper <DOCTYPE>, or else you will receive significant errors. Even for very experienced developers, it is often necessary to fix errors and re-validate several times. Validation ensures that all tags are closed, nested properly, and that depreciated elements are avoided.
Cascading Style Sheets (CSS) are the recommended technique for the presentation and positioning of Web content. However, some CSS properties and techniques can make content on your page inaccessible. Always test your page or application in a browser that has CSS disabled.
When you view your page without CSS, the colors and fonts change, and the page will be linearized similar to how a screen reader will read it. This will help you determine if your content makes sense without the style, if the page is organized in a logical manner, and if form controls are still identifiable. Viewing your pages without CSS enabled can also give you an understanding of how older browsers may display the content.
While Internet Explorer remains the dominant browser used by most people, ensuring that your page or application looks and functions well in other browsers is a fundamental element of universal design. Always view and test your product in at least two graphical Web browsers such as Internet Explorer and Netscape (preferably an older version like 4.76). Including one "alternative" browser such as Opera, Firefox, Safari, Galeon, etc., is ideal.
Internet Explorer is very forgiving when it comes to HTML and CSS errors, and it will typically compensate for broken tags or improper syntax. A page that looks great in Internet Explorer can be a jumbled mess when viewed using a more standards-compliant browser. Testing across multiple browsers is critical when CSS is used for positioning and formatting. Some CSS references are handled very differently in each Web browser, particularly padding and positioning attributes. Other references are browser-specific, for example, mouse hovers and some border and text formatting properties.
Your page or application should be fully functional, and the content and layout should make sense. However, the page does not have to look identical in each browser. Instead, ensure that the content is positioned properly on the page, that hyperlinks are identifiable, that no text is overlapping, that all form and application controls work correctly, etc.
A non-graphical browser does not load images or display content according to table or CSS structure. This testing method can achieve two goals. First, it enables you to see how the content on your page is represented when images are not accessible or loaded. You can also achieve this by turning off images in your Web browser.
Secondly, you can get an idea of how your page appears when it is viewed or read in a linear manner. This is important whether you use tables for layout, or CSS for positioning. A screen reader will indicate that a table structure is present. The text-only browser will completely ignore tables. However, both will linearize the structure of your page and display the content as the table cells are read from left to right, cell by cell, beginning at the top left corner of the page.
To test, use a screen reader like JAWS, Home Page Reader, a text-only browser like Lynx or a simulator like Lynx-Me.
When testing, pay attention to how the content of your page is displayed. If the content does not make sense, or if it flows in such a way that the text from one column of a table is intermingled with text from another, then you need to make further modifications to ensure that it is accessible. Check whether appropriate alternative text is available for all images, and that the alternative text makes sense when it is read or heard within the context of other text elsewhere on the page.
Many people use the accessibility features that come bundled as part of their operating systems. Screen magnification is prevalent among people who typically wear reading glasses or by those who have visual impairments caused by age, glaucoma, macular degeneration, injury, and disease.
Tools are available as part of the operating system, for example, In Windows 2000, magnification can be turned on by going to Start > Programs > Accessibility > Magnifier. Also, some people use lower screen resolutions to prevent eye strain. Fonts can be increased or decreased by selecting browser and/or operating system settings. Similarly, newer technologies are permitting people to view Web pages on large, high-resolution monitors, for example, LCD televisions. Others may be using hand-held devices to access your page.
A good way to test if your page will be accessible is to change your screen resolution. Once you have settled on a design and structural layout for your page or application, it should be tested at the following screen resolutions: 640 x 480, 800 x 600, 1024 x 768, and 1280 x 1024. Some browsers may require a page refresh to see how the page looks at a different resolution. Also, toggle between maximize and minimize, or resize your browser window, to see how the content adjusts.
A successful design will be fluid across all resolutions, so that content fills the browser window properly, and that form and application controls are easily accessible without causing excessive horizontal scrolling. If you have images that contain text, make sure that the text is still readable. If not, consider using plain text instead. Using relative sizing in your CSS and table properties will ensure that your pages transform well.
Accessibility tools are helpful to understand the various Section 508 and W3C checkpoints, and they offer great tips along with concrete examples. The two most popular semi-automatic accessibility checkers are Bobby and WAVE.
While these tools are essential for testing, they cannot ensure that you have met every single checkpoint. Some checkpoints require visual or manual user testing, others involve some interpretation, and some accessibility techniques are still being debated by industry leaders. Therefore, strive to meet as many checkpoints as possible, even if they go beyond those outlined by this Web site. However, do not display any icons or links that state that your page has passed the checker. Your page, application or Web site is covered by the accessibility policy defined on this Web site.
For reference, Conformance Level A meets WCAG 1.0 Priority 1 guidelines, Conformance Level AA meets WCAG 1.0 Priority 1 and 2 guidelines (which is the recommended level outlined on this Web site), and Conformance Level AAA meets all WCAG 1.0 Priority 1, 2 and 3 guidelines.
Some people with visual impairments use high contrast settings to view Web pages. Colorblindness also affects a significant portion of the population. Always evaluate your use of color to ensure that it is not used as the sole method to convey information.
To test, change your monitor's display color to grayscale, or print out your page in grayscale or black and white. Does the content still make sense? Pay particular attention to text in images and on form or application controls. For example, map legend elements are often conveyed by different color shadings. Is the legend item represented in another way other than just color, for example, via a number or geometric symbol? Observe whether the contrast of the text to the background of the image or page is adequate.
A helpful test for colorblindness is available from Vischeck. It is a good idea to test your design and images using each of the simulations: deuteranope and protanope (red/green deficits), and tritanope (a blue/yellow deficit). This will help you determine if you have used any color combinations that may be indistinguishable for certain visitors with colorblindness.
Visitors may navigate your Web site using a keyboard for a variety of reasons. Some find that controlling a mouse is difficult because of a disease such as Parkinson's or multiple sclerosis. Others may have an injury or limited use of their hands. Some may use assistive technology. For example, screen reader commands are entirely keyboard-driven. Others simply prefer the keyboard, finding it faster and less painful than repetitive mouse actions.
Ensure that all content you have created is keyboard accessible. Without using the mouse, use your TAB key to navigate through hyperlinks and form controls. You should be able to access links and form controls in a simple, logical tab order, not by jumping all around the page. You should be able to launch links or submit information using the ENTER and/or ARROW keys.
Some people who access your content may be Deaf or hard of hearing. If you have created multimedia or programming content that is audible, test your pages with the sound or speakers turned off. Make sure that the audio content is still available through text equivalents. Depending on the complexity of the content, this may entail including synchronized captioning, a transcript, or a textual description.
If you have included JavaScript event handlers or other scripted content, disable scripting in your Web browser and test your page or application. This test does not indicate whether or not you have met accessibility guidelines, for example, ensuring if it is device-independent and keyboard accessible. Rather, it will help you determine if the script is considered essential or non-essential. If the content of the page is still accessible, and the main tasks of the application can be accomplished when you have disabled scripting, then the scripting is considered non-essential and it does not need to be directly accessible. Otherwise, your script must conform to the accessibility guidelines outlined on this Web site.
Review your written content for clarity and simplicity. If the content on your page does not make sense, then you counteract all of your other accessibility efforts. Copy your text and paste it into a word processing document to check it for spelling and grammar errors. Screen readers and speech synthesizers often "guess" what a word means if it has a spelling error. This can be confusing to some of your visitors. Unclear phrases and grammar problems can decrease reading comprehension. Simple errors like these also make your page appear unprofessional and your visitor will assume that your page is not a credible source of information.
If you are making a significant design revision, building a stand-alone Web site, creating a complex form or Web-based application, it helps to conduct broader user testing. Your testing can catch many design and accessibility problems, but the input of a few other people will nearly always immediately catch any glaring issues. Whenever you are in doubt, always seek feedback. People are generally happy to oblige, and if needed, a formal focus group can be established.
When looking for feedback, seek out people with different disabilities, different levels of technical expertise, and different levels of familiarity with your content.
If you are testing specific accessibility features, include people who regularly use the assistive technology that you are designing for, because they will be able to better determine the usability of your page or application compared to their other Web experiences. For example, asking another developer to check your page using a screen reader is not as effective as having a person who uses that device every day test your page.
Looking for a great all-around option? The Opera Web browser is a wonderful testing tool for developers. Because it is a based on HTML standards, if you design for Opera, you can be confident that your pages can be viewed with any browser. Opera is ideal for developers who want to test their content, and for many users with disabilities.
Opera has a variety of user modes that enable a person to view Web content in many different ways, including but not limited to: disabling CSS, emulating a text browser, high contrast settings, and disabling tables. Pages can be reduced down to 20 percent or magnified as high as 1000 percent.
Through the Quick Preferences menu, you can enable or disable sounds, Java, JavaScript, plug-ins and pop-ups. You can also identify the browser as Opera, Mozilla-compliant, or MSIE, which can be a helpful testing step for form and application controls. It even has a small-screen view, which serves as a reasonable PDA simulator. And, images can be turned on or off using a toggle button on the toolbar.
All of these changes can be made quickly and easily on the fly, without the need to refresh your page. Learn more about using Opera as a testing tool from WebAIM.org.
