Archived Web Accessibility Tips

Evaluating Web Accessibility on iDevices

If you have an iPad, iPhone, or iPod touch, you have a screen reader. VoiceOver comes built-in to all modern Apple touchscreen devices. VoiceOver can be enabled in the device Settings, or by quickly pressing the Home button three times. The following core functions are available:

• Read the entire page: Swipe two fingers upward
• Stop reading: Tap with two fingers
• Read through page elements: Swipe left or right
• Open or modify the rotor (a list of elements which can be navigated): Twist two fingers on the screen
• Select from multiple rotor element by twisting
• Once selected, swipe up or down to cycle through the selected rotor element
• Read from current location: Swipe downward with two fingers
• Select an element: Press and drag finger to an item, or navigate to an item using another navigation gesture
• Activate an item: Double tap
• Zoom: Triple tap

Basic web accessibility evaluation (checking alternative text, form labels, heading structure, reading and navigation order, etc.) can easily be performed on any Apple touchscreen device.

HTML5 and Longdesc

The longdesc attribute, which is used to reference a page that contains a longer description of a complex image (such as a chart or graph), is currently not present in the HTML5 specification. It was dropped due to poor implementation by authors (it was often coded incorrectly or didn't provide a true alternative to the complex image), poor browser support, and because it really only provided utility for some screen reader users. Unfortunately, there is not yet a suitable alternative attribute or functionality in HTML5 or ARIA for referencing a long description page. While longdesc will likely have continued support in browsers and screen readers for some time, it has long been recommended that for optimal usability and accessibility that authors provide a standard link to the long description page instead of or in addition to using longdesc.

HTML5 Video and Audio

HTML5 provides browser-native audio and video support via the <video> and <audio> elements. It also specifies support for keyboard accessibility to player controls, native support for captions and subtitles via the <track> element, and a specification for captioning data (currently the WebVVT format). While browser and accessibility support is not yet present, this will eventually result in more accessible audio and video content that does not rely on external programs and players.

HTML5 Input Types

HTML5 introduces several new form field types - search, tel (for telephone numbers), url, email, datetime, date, month, week, time, datetime-local, number, range, and color. While browser support currently varies (if they are not supported, browsers simply present a text input), it is getting better. These new input types will greatly facilitate usability and better accessibility. For example, an <input type="number"> might present a numbers-only keyboard, require only numbers be inserted, or alert the user if something other than a number is inserted. An <input type="date"> might present a date picker to support easier insertion of a date. Because the date picker would be browser-provided (and presumably accessible), authors would not need to provide a date picker, something that currently requires scripting and effort to make accessible.

HTML5 Heading Outlines

Headings in HTML5 may be presented to users differently based on the document structure, particularly within <section> and <article> elements. Headings within these elements are isolated from the surrounding document, but when presented to end users the heading level may be shifted up or down based on surrounding content and preceding headings. For example, an <h1> heading in an <article> may be presented as a second-level heading if there is a preceding <h1> in the document. To ensure the HTML5 outline is accurate and logical, use the HTML5 Outliner to view how headings will be presented to end users.

HTML5 and Optional Alt Attribute

HTML5 currently allows the alt attribute of the image element to be optional. If an image is given alt="", it indicates that the image is decorative and does not convey content, or that the content of the image is conveyed elsewhere, such as through an image caption or adjacent text. In HTML5, omitting the alt attribute indicates that an alternative for the image was not provided or cannot be determined. An instance where no alt attribute might be necessary is when a user uploads hundreds of photos to a photo sharing site and will not provide alternative text for each of them. Because the alt attribute is required in previous versions of HTML and XHTML, this would require the photo sharing site to give the images improper alternative text (either alt="", which is not accurate because the image does convey content, or generic, inaccurate alternative text such as alt="photo087" or similar) in order to be valid HTML. In HTML5, the alt attribute may be omitted in this case, and while this does not make the image accessible, this does provide an indication that the image is not accessible and might allow screen readers to then attempt to find or present additional potentially useful information about the image (such as the image file name, results from a related image search, etc.).

HTML5 Structural Elements and ARIA

HTML5 introduces several new structural elements that will be very beneficial for accessibility: <nav> (for identifying navigational elements), <header> (a group of introductory or navigational aids), <article>, <aside> (tangentially related content, such as a sidebar), and <footer> provide meaning to major page structural areas. These can also be used to enhance keyboard navigation (a user could press the "N" key to jump to the page navigation, for example). Many HTML5 structural elements mirror or map to ARIA landmark roles:

   • <article> — role="article"
   • <footer> — role="contentinfo" (only one per page)
   • <header> — role="banner"
   • <nav> — role="navigation"
   • <aside> — role="complementary"

If transitioning to HTML5, you will want to use both the HTML5 native element and the ARIA role (e.g., <nav role="navigation">) until assistive technology support for HTML5 improves. Of note is that ARIA provides very useful role="search" and role="main" that do not have HTML5 counterparts. The accessibility of nearly all web pages would be increased if these roles are implemented.

ARIA Application Role

ARIA role="application" can be used to identify web applications or widgets within a page. When a screen reader is within an element with this role, it functions in forms mode, meaning that when keyboard keys are pressed, they are passed to the web page rather than handled by the screen reader itself. This, however, can be confusing for the user if they are unaware that they are within an application. For example, a screen reader user may press the "H" key expecting to navigate to the next heading, but within an application, this functionality would not occur. Instead, the "H" key press would be passed to the application where it could trigger a "Help" dialog. Because of this potential confusion, role="application" should generally only be used on web applications that are handling keyboard events. When possible, inform the user that the application will be controlling keyboard interaction and provide a listing of the shortcut keys and their functions.

ARIA Attributes and Element Styles

ARIA attributes are often necessary for optimal accessibility of web applications. They can be used to present information and meaning that otherwise would only be presented visually. For example, a red border or red text might be used to identify errant form fields (such as a form field that was not completed properly). This color-only designation would not be accessible to screen reader users. However, adding aria-invalid="true" would provide an indication to a screen reader user that this field is invalid or broken. With CSS, visual styles can be applied to elements based on their ARIA attribute values. Instead of setting the ARIA attribute and also styling the form control to present a red border, CSS styles of [aria-invalid=true] {border: 2px solid red;} could be used to automatically style the element based on its ARIA attribute.

ARIA Roles and Native Semantics

ARIA roles enhance or change the semantics and meaning of page elements. Whenever possible, the proper native HTML elements should be used. For example, while role="button" could be added to a scripted link that is used to submit a form, a native button element would provide this same functionality in less markup and without relying on ARIA.
Additionally, an ARIA role should not be used if it is the same as the default role of the element. For example, role="button" on a <button> element, role="grid" on a table, or role="checkbox" on an <input type="checkbox"> would be redundant and unnecessary.

ARIA Alert Roles

ARIA role="alert" can be used for very important messages that a screen reader should read immediately, even if keyboard focus is not set to that element. ARIA alerts are typically triggered with scripting, such as when a critical form error has been detected. Because ARIA alerts are very intrusive (they read immediately regardless of screen reader status or focus position), they should be used with great care and only for very important messages.

Form Fields Without Visible Labels

Sometimes form fields, such as a search text box, do not have visible label text. In order to be accessible, these fields must have descriptive text provided in one of two ways:
• Use the title attribute in place of a label. If a form field has a title, but no label, the screen reader will read the title as if it were a label. Using the title attribute will also create a tooltip that will be visible if a user hovers over the form field with a mouse.
• Use the <label> element and hide the label element off-screen using CSS. This technique has the advantage of creating a label that will be visible when styles are disabled. It is also possible to use CSS to create a label where part of the text is visible and part of the text is hidden off-screen.

WCAG 2.0 and Text Sizes

WCAG 2.0 does not specify a minimum text size—1 pixel font would be compliant, though obviously inaccessible to all sighted users. Font sizes should generally be at least 10 pixels.
WCAG 2.0 Success Criterion 1.4.4 (Level AA) requires that content must remain readable and functional when text size or page zoom is set to at least 200% or twice the default size. This can be tested by selecting Control + (or Command + on a Mac) in your web browser or by increasing the text size under the View menu. The 200% text sizing requirement can be very difficult to meet on many pages. However, it is very uncommon for end users to need text sizing this big. Any user requirements over around 150% would necessitate page zooming or a dedicated screen enlarger. While supporting 200% text sizing ensures significant flexibility for end user text sizing, effort may best be spent achieving a more reasonable requirement of 150% text sizing.

Web Accessibility and SEO

Web accessibility and search engine optimization (SEO) are both about getting relevant content to users. Accessible content and search engine optimized content are both machine readable. Accessibility and SEO best practices are closely aligned. Proper alternative text for images, good heading structure, descriptive link text, descriptive and succinct page titles, ensuring keyboard accessibility, providing captions and transcripts, identifying the language of the page, using text instead of images when possible, providing clear and consistent navigation and page structure, and several other best practices help provide accessible and search engine friendly content.

Button Text

Buttons should have descriptive and succinct values or text that describe the function of that form button. Like "click here" links, ambiguous button text (such as "Go" or "Submit") requires the user to scan before the button to determine precisely what the button does. Descriptive text such as "Search", "Subscribe", etc. are unambiguous and more accessible. If multiple buttons are present on a page, the button text should be different (e.g., "Search the web" versus "Search this site").

Use Links and Buttons Appropriately

Links and buttons can be scripted to perform various functions. In general, 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 a content area 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 so it is clear to screen reader users what a particular link or button will do. For example, it could be confusing to use a scripted link to submit a search form - a screen reader user that hears "Search link" may think this link will take them to the search page when they are instead looking for a search button to submit the form.

CAPTCHA

CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart. A CAPTCHA is typically presented as a graphic with distorted letters or numbers that a user must decipher and enter into a text field. Although CAPTCHA attempts to ensure a response that is generated by a person, nearly all modern CAPTCHAs can be readily solved by computer programs. Graphical CAPTCHAs cannot be made screen reader accessible. By their nature, CAPTCHA introduces usability, accessibility, and cognition issues for end users, and therefore should be avoided when possible. When necessary, audio CAPTCHA (distorted audio is played instead) should be provided in addition to a graphical CAPTCHA.

Avoid Screen Reader "Freak Out"

Modern screen readers are able to read dynamic, scripted content updates within a web page. However, if the content a screen reader is currently reading or focused on changes or is removed/hidden from the page, the screen reader "freaks out" due to this loss of focus, and typically reverts focus to the top of the page. This can be very problematic if a page has continually updating content areas (such as a page area for updating sports scores or stock quotes). This screen reader issue can generally be avoided by ensuring that page content updates are controlled by the user or that they do not update when the screen reader is within that area of the page. ARIA live regions provide a mechanism for avoiding screen reader "freak out". When page elements disappear or are hidden, such as when a user closes a modal dialog window, focus must be set with JavaScript focus() to a logical element within the page.

Requiring JavaScript

Some advanced web applications would not be possible without JavaScript. Both Section 508and WCAG 2.0 allow JavaScript to be required so long as the JavaScript content and interactions are compliant and accessible. Whether you should require JavaScript is not really an accessibility question. It is a general usability question. Some users (most users indicate less than 2%), regardless of disability, may have JavaScript disabled. When possible, the functionality should be available without requiring JavaScript. When this is not possible, the functionality should fail gracefully (i.e., inform the user that JavaScript is required).

It is a common misconception that screen readers to not support JavaScript or that users with disabilities always disable JavaScript. The approach to accessibility is then to only ensure that the non-JavaScript version or fallback content is accessible. A screen reader user survey found that 98.6% of respondents had JavaScript enabled, meaning that in this case, nearly all screen reader users would not get the accessible fallback but would instead get the inaccessible scripted content. In order to be compliant and accessible, all scripted content and functionality must be accessible.

Avoid Form Auto-advancing

Ensure that focus is never automatically advanced from form field to form field. This is often experienced when three text fields are used for telephone numbers (area code, first three digits, last four digits). After entering the first thee numbers, focus is automatically set via JavaScript to the second field, but a user who has pressed the tab key will then be moved to the third field. The problem can sometimes be compounded when the user attempts to fix an error. For example, if the first field contains an incorrect area code and the user presses Shift + Tab to go back to the field, the JavaScript may detect that the field already has three characters and automatically set focus to the next field, making it impossible to correct the field with the error. This can be avoided by not setting focus and simply allowing the user to move to the desired fields manually.

Mouse Hover

Many interactive elements on the web require the user to hover the mouse over a page element - drop-down or fly-out menus, tooltips, etc. Mouse hover functionality is usually not accessible to keyboard-only users (note that the functionality can sometimes be programmed to respond to keyboard focus or pressing Enter in addition to mouse hover). Perhaps more significant, hover functionality is not generally available on touch screen devices where only tap/click events are recognized. Because of these compatibility and accessibility issues, functionality should be programmed to not rely on mouse hover interactions.

Empty Table Headers

When marking up data tables, avoid empty table headers (<th>element). Empty headers can cause confusion for screen reader users because there is no information to be read for a data row or column, or they may cause the screen reader to associate a header to an incorrect column or row. Pay particular attention to the first cell, in the upper-left corner. While this cell is usually a column header(<th scope="col">), it can also be a row header(<th scope="row">), or left empty. If a header is empty, identify it as a table data cell (<td></td>), not a table header.

Accesskey

The accesskey attribute allows page authors to define a shortcut key for interactive page elements (e.g., <a href="search.htm" accesskey="s">Search</a> defines "s" as the accesskey for the search page). Browsers provide varying keyboard shortcut combinations to activate this accesskey. Because of the wide variety of browser and assistive technology shortcut keys, and because there is not a set of keys reserved for use with accesskey, authors can never be sure that their defined accesskey will not conflict with end-user shortcut keys. Because of these difficulties, accesskey should generally be avoided, except in controlled situations where the user systems are well defined, or when users can define their own site accesskeys.

Document Language

The natural language of every web page should be defined. This is typically done by simply specifying the appropriate language code in the langattribute on the <html> tag (<html lang="en">, for example).

This WCAG 2.0 Level A requirement is vital to ensure that assistive technologies present content in the appropriate language. Consider a user that understands and has set his screenreader to read in both French and English, with French being the primary language. If he encounters an English page that does not have the language specified, it would likely be read using the screen reader's French language settings, intonation, inflections, etc., thus making it very unintelligible. Specifying the document language ensures that it be read in the appropriate way, so long as the screen reader supports that language.

The language should also be defined for portions of a page that are not in the document's language, such as a quotation in French found on an English web page. This is also done using the lang attribute (e.g., <div lang="fr">).

Avoid Form Auto-focusing

Users should typically have control over the position of their cursor. Avoid using JavaScript or the HTML5 autofocus attribute to automatically place focus into a form control unless the entire purpose of that application is for user interaction in that field (such as the Search text box at google.com). Automatically setting focus within the page can cause confusion for keyboard users who immediately interact with internal page content rather than the page's initial content (typically the site name/logo and navigation).

Simplify Data Tables

Accessibility of data tables can be achieved by identifying table headers and defining whether they are row or column headers (for example, <th scope="col">). Complex tables (those that have more than one level of row or column header, or spanned data or header cells) can easily become too complex for screen reader users to comprehend even though markup may technically provide the necessary associations between data cells and headers. Consider a table where 3 or 4 or more headers are identified for each data cell; understanding the relationships between the data and the appropriate headers can be difficult for users, especially for users that cannot see the table. When possible, simplify or 'flatten' data tables so that there is no more than one row and column header for each data cell.

Image Maps

Image maps allow an image to have defined clickable areas or 'hotspots'. These hotspots are defined in the <area> element using coordinates for geometric shapes. The hotspots are navigated by keyboard users in the order in which they are defined in the source code. The order should be logical - usually either left-to-right, top-to-bottom or alphabetically. Because these hot spots provide functionality, every <area> element must have a descriptive altattribute. The main image may require alternative text if it conveys content that is not conveyed through the individual <area> elements. For example, a map of the state of Utah with hotspots for each county would likely be given alt="Map of counties in Utah".

Server-side Image Maps

Server-side image maps (typically an <img> with the ismapattribute) allows x and y coordinates of where a user clicks the image with a mouse to be sent to a server for processing. For example, for a state map, the x and y coordinates of where the user clicks could be analyzed to direct the user to a web page for the county they clicked. Server-side image maps are not keyboard accessible - one cannot click a particular point on an image using the keyboard. Instead of server-side image maps, client-side image maps (wherein clickable areas or 'hotspots' are defined) should be used. Client side images maps (<area> elements with appropriate alternative text and a logical navigation order) are fully accessible to both mouse and keyboard users.

Sensory Characteristics

Avoid relying on sensory characteristics, such as shape, size, or visual location. For example, "Click the green button" will not be useful to screen reader users or some users who are color blind. Instead, use "Click on the green button labeled 'submit'" or simply "Click the 'submit' button". Similarly, "Use the form on the right" could be changed to something more descriptive such as, "Use the search form on the right." Other examples include prompts such as "Click the larger button," "Select a state on the east coast on the map", "Instructions are included in the sidebar", etc. Purely auditory cues ("Click 'Continue' after you hear the beep") should also be avoided.

WCAG 2.0 and Transcripts

The word "transcript" doesn't appear in WCAG 2.0 because it is strictly interpreted as being only the verbatim text version of that which is spoken. For optimal web accessibility for users with auditory disabilities, information in addition to the spoken content (such as indications of laughter or explosions, or the presentation of visual-only content) are necessary. WCAG uses the term "alternative for time-based media" to describe this descriptive transcript. WCAG 2.0 Success Criterion 1.2.3 (Level A) requires synchronized captions and either audio descriptions or an "alternative for time-based media" (i.e., descriptive transcript).

Icons vs. Text

Icons can present complex information, meaning, and functionality in a very small amount of space. A browser's "Home" icon (typically an illustration of a house) readily conveys rather complex meaning and functionality - activating it will take you to the browser's defined home page. While such icons can be very useful, care must also be taken to ensure that the icon is understandable to the end user and reflects well-known conventions. The floppy disk icon, for example, is used for "Save", yet the real-world connection between saving a file and an actual floppy disk (something that is rarely seen and no longer produced) is not present for many people, particularly newcomers to the web and youth. Real text ("Home" or "Save") should be used in place of an icon, or perhaps in conjunction with an icon.

Avoid Redundant Alternative Text

Images and related text are often paired together, such as a product image with the product name immediately below it, or a photograph with a caption. In instances where the text conveys the content of the image, the image should usually be given null or empty alternative text (alt=""). This avoids the redundancy of having a screen reader read the same information twice (once for the image alternative text and once for the caption or adjacent text).

If the image and the adjacent text are links to the same location, combine both the image and the text into one link and give the image null alternative text. This avoids redundancy, results in fewer links for the user to navigate, and results in fewer links for the user to navigate.

Extraneous Alternative Text

Alternative text should convey the content and function of an image, but it should not be used to convey additional information that is not presented visually by the image. For example, file size, file format, copyright details, that a graphical link opens in a new window, link destination, price (on e-commerce sites), keywords for search engines, etc. should not be included in alternative text. If this content is important, it should be included in the page in a way (such as in nearby text) that makes it available to all users. If this information is not necessary, it should be removed or may be presented in the titleattribute value (which is intended for this type of advisory information).

Accessibility of User Flows

When implementing accessibility, the issues on the most visited or high profile pages are often the first to be addressed. While this is effective, also consider user flows or processes. For example, on an online shopping site, focus on making the entire checkout process accessible. While the final purchasing page of this critical process may not be as high profile or receive as much traffic, if it is inaccessible, the entire flow is essentially inaccessible. Unfortunately, the user may not realize this until they have spent considerable time on previous steps in this flow.

Cognitive Load vs. Functionality

Cognitive load is the amount of mental effort required to engage in a process. On a web page, clutter, animation, confusing content, background sounds, complex information, and other aspects of poor accessibility and usability increase cognitive load. Try to provide necessary functionality while minimizing cognitive load. This can be particularly difficult on site home pages where much functionality is provided, which generally results in a very high cognitive load. Good usability and accessibility techniques, often as identified in user testing, can help site authors maintain necessary functionality while decreasing the cognitive load.

Large Clickable Targets

Some mouse users have may have difficulty with fine motor control, so it is important that clickable targets be sufficiently large. Radio buttons and checkboxes should include properly-associated labels (using the <label> element). Small icons or text, such as previous/next arrows or superscript links for footnotes, should be sufficiently large or combined with adjacent text into a single link.

Consistent Navigation and Identification

Consistency is important for web site accessibility and usability. WCAG 2.0 Success Criterion 3.2.3 (Level AA) requires that navigation elements that are repeated on web pages do not change order across pages. Success Criterion 3.2.4 (Level AA) requires that elements that have the same functionality across multiple web pages be consistently identified. For example, a search box at the top of the site should always appear in the same place and be labeled the same way.

Separate Content/Functionality from Visual Design

Accessibility of web page content and functionality occurs almost entirely in page markup (HTML). Cascading Style Sheets (CSS), on the other hand, should be used exclusively for defining page styling and visual design. While CSS can be used to improve visual design, accessibility, and usability, screen readers ignore nearly all styles. When page content or functionality are integrated into visual design and CSS (such as a CSS background image that presents content, or a styled button that presents no functional text), then this content is not available to screen reader users. Ensure that content and/or functionality are not lost when page styles are disabled.

Link Type Indicators

It is a good idea to inform users when a link goes to non-HTML content (such as a PDF file or Word document). It can be frustrating to activate a link and then realize that the link requires an external program or viewer. An icon (with appropriate alternative text) or text, such as "(PDF)", is sufficient. Because screen reader users commonly navigate by links, it is vital that the link type indicator icon or text be placed within the link, otherwise this information is readily available to sighted users, but not presented in the context of the link for screen reader users.

Accessibility User Testing

Instead of conducting accessibility testing with users with disabilities (asking users to identify accessibility issues), it is almost always more effective to do usability testing (asking users to evaluate overall usability) with users with disabilities. While accessibility testing can be used to identify instances of accessibility – poor alt text here and a missing label there, fixing all significant instances of inaccessibility and non-compliance still might result in a poor experience for users with disabilities. Basic user testing that includes users with disabilities has a focus on the broader user experience with a site, yet still can identify specific accessibility issues. User testing with individuals with disabilities should be part of a broader testing plan that involves compliance checklists, automated tests, manual testing, and assistive technology testing.

Text Readability

Keep the following guidelines in mind for displaying text:

Avoid very small text. This not only impacts some users with low vision, but many users with cognitive disabilities as well.
While serif fonts (e.g., Times) are more readable when printed, both serif and sans-serif fonts are appropriate when displaying body text onscreen, as long as the font is clean and readable.
Underlined text should be avoided, except to designate links.
Minimize the number of different fonts used on a page. Two to three fonts is optimal.
ALL CAPS should be used minimally. It is more difficult to read and is often interpreted as "shouting". Additionally, screen readers may read all-caps text letter by letter (like an acronym) rather than as full words.

WCAG 2.0 and Reading Level

It is always a good idea to make content as readable and understandable as is suitable for the audience. For complex content (defined as that which requires a reading ability more advanced than the lower secondary education level), WCAG 2.0 Success Criterion 3.1.5 (Level AAA)requires that a more simplified and readable version of the content be provided. Much content cannot be made perfectly understandable at these levels (consider a college-level chemistry class, for example), thus it's a Level AAA success criterion. Regardless of the limitations for some content, for a page to be optimally accessible, it should be written so as to be easily readable and understandable to the target audience.

Voice Control Software and Image Alternative Text

To activate links on a page, users of voice control software, such as Dragon NaturallySpeaking, speak the visible link text. When an image is linked, the alternative text of that image can be spoken to activate that link. When an image presents graphical text, the alternative text of the image should match the visible text to ensure voice control software users can easily activate that link.

Use True Text

True text has several advantages over graphical text and should be used whenever possible. True text is easier to read, especially if it is enlarged. The user can more easily customize the appearance of the text to make it more readable (changing color, size, font, etc.). File size is typically smaller for true text and it can be translated into other languages.

WCAG 2.0 Level AA requires that if the same presentation can be accomplished using true text, then you must use true text rather than an image of text. Level AAA requires that text cannot generally be used within images at all.

Evaluating Web Accessibility with WAVE

WAVE is a free web accessibility evaluation tool found at http://wave.webaim.org/. Rather than providing a complex technical report, WAVE shows the original web page with embedded icons and indicators that reveal the accessibility of that page. This presentation facilitates manual evaluation of web accessibility. A Firefox toolbar version of WAVE allows evaluation of web content directly within the browser - thus allowing sensitive, password protected, dynamic, or intranet pages to be easily evaluated. Because WAVE performs evaluation after page styles (CSS) has been applied and (in the toolbar) after scripting has been processed, WAVE provides a very accurate representation of true end user accessibility.

Evaluating Alternative Text

When evaluating the alternative text of images, remember that the alternative text (whether in the image's alt attribute or in adjacent text) should convey the content and function of an image. Asking the question, "If the image could not be used, what text would replace the image?" is often a good way to determine appropriate alternative text. First, view the alternative text along with the image. Is the alternative text equivalent to the content of the image? Second, disable images and view the alternative text in place of the image and consider if the alternative text makes sense in its context and reading position within the page.

Low Vision Custom Color Settings

Some users with low vision can see content more easily if the default colors are inverted (white text on a black background), customized user styles are applied (blue text on a yellow background, for example), or a custom color scheme is used. This can be done using the operating system, with screen magnification software, or with user style sheets in a web browser. To ensure web accessibility for these users, make sure your page colors have sufficient contrast, that color is not used as the only means of conveying information or meaning, and that colors are specified for page elements (typically using CSS to at least define the page foreground and background colors).

Accessibility, Compliance, and Discrimination

Accessibility is about the user experience. Because a web site can always be more accessible, accessibility is best viewed as being a continuum. Web accessibility guidelines and standards (such as Section 508 and WCAG) provide useful measures along that continuum. Discrimination laws (such as the Americans with Disabilities Act or Section 504 of the Rehabilitation Act), however, generally do not define web accessibility, but instead clarify that web sites should not discriminate based on disability. Because standards and guidelines do not address all aspects of web accessibility, it is possible for a site to comply with a set of guidelines, yet remain very inaccessible to some users and potentially discriminatory. This is particularly true with very minimal standards such as Section 508. For these reasons, it is best to get a true understanding of accessibility and how end users access and use the web. Standards and guidelines should be used as tools and measures of accessibility, but the ultimate goal should not merely be compliance, but to provide an efficient, friendly, and accessible user experience regardless of disability.

Audio Descriptions

Difficulty: Advanced

Category:

Content

Audio descriptions can enhance accessibility of video content for users who are blind or have other visual disabilities. Audio descriptions provide an auditory presentation of content that is presented visually, but not presented audibly in video. They typically take the form of a narrator that describes the important information or content elements that sighted users can see. Audio descriptions are difficult and costly to produce. You typically must present two versions of the video. When producing video content, if you simply ensure that all visual content is presented audibly, then there will be no need for audio descriptions.

Scaling Images

Difficulty: Advanced

Category:

Presentation

Users with low vision often use a screen enlarger to increase the size of elements in a web page. Images can become pixelated or blocky when they are enlarged. Text within images can become particularly difficult to read. When you can get the same visual presentation using real text, you should use it instead of text within images. When images that contain text are used, ensure that the text remains readable when the image is at least doubled in size. Using sans-serif fonts and adequate contrast makes enlarged text in images more readable.

Adobe PDF

Difficulty: Advanced

Category:

Content
Structure
Presentation

Adobe PDF files can be made accessible. PDF files store accessibility information for screen readers in tags. Tags are text elements that are hidden within the PDF file, but that are presented to the screen reader. You must ensure that PDF files are authored in a way that supports accessibility within these tags, and that the tags contain the full content of the PDF document. PDF accessibility is best implemented and modified using Adobe Acrobat Pro.

aria-labelledby

Difficulty: Advanced

Category:

Structure

Traditional form labeling with the <label> has distinct limitations; you can only have one label for each form element. You cannot have one label for multiple form elements (consider "Telephone Number" as a label for 3 text boxes to comprise a complete telephone number). You also cannot have multiple labels for one form element (consider a text box that has a label preceding it and the word "required" immediately after it, both of which provide important information). The aria-labelledby attribute (part of the ARIA specification) overcomes these limitations by allowing any element to be labeled by any other page element.

Landmark roles

Difficulty: Advanced

Category:

Structure

Adding landmark roles to your page is an easy way to enhance accessibility. Landmark roles are part of ARIA, a new accessibility specification. Landmark roles define significant web page areas and provide the user quick access to them. The available landmark roles are application, banner, complementary, contentinfo, form, main, navigation, and search. You can simply add role="search" to your search form (<form role="search">) to identify it specifically as the search form on the page. <div role="main"> designates the element that contains the main content. <ul role="navigation"> could be used to specify the navigation items for a page. Landmark roles can easily provide significant functionality and increased accessibility to keyboard and screen reader users.

Tabindex

Difficulty: Advanced

Category:

Structure

Tabindex values of 1 or greater assign a specific tab order to elements. Because the default tab order of the page is typically logical and intuitive, positive values are rarely necessary. A tabindex value of 0 allows elements other than links or form elements to be focusable in the default tab order of the document. Tabindex of -1 allow other elements to receive focus, but only when focus is set through JavaScript or via a link. Setting and modifying tabindex values and controlling keyboard focus with JavaScript can greatly increase the accessibility of dynamic and interactive web applications and widgets.

Noscript and Progressive Enhancement

Difficulty: Advanced

Category:

Presentation

The noscript element provides a fall-back for when JavaScipt is not enabled or supported. Because most screen readers and other assistive technologies support JavaScript, and because users of these technologies are generally no more likely to have JavaScript disabled, the use of noscript is not really an accessibility concern. Developers must simply consider that if they require JavaScript, that some users may not get that content or functionality. It is important, however, that the functionality fail gracefully (e.g., it is clear or the user is alerted that a web application will not work without JavaScript).

Progressive enhancement is a better approach than noscript. noscript provides a fall-back for when JavaScript is disabled, whereas progressive enhancement is an approach where the web page is built to be fully functional without JavaScript, and is then enhanced with JavaScript. Using progressive enhancement ensures that the page works regardless of whether JavaScript is enabled.

ARIA

Difficulty: Advanced

Category:

Structure

While support for ARIA (Accessible Rich Internet Applications) is not perfect, implementing it can never make a web application less accessible. While native accessibility should be implemented to the extent possible in HTML, ARIA allows enhanced semantics and accessibility that is not possible with HTML alone. Much of ARIA will be part of native HTML5, but because ARIA accessibility support is much more extensive than HTML5 accessibility support and because ARIA can be applied to HTML and XHTML pages, it makes the most sense to implement ARIA and take advantage of the enhanced accessibility it provides now.

ARIA Components

Difficulty: Advanced

Category:

Structure

The core components of ARIA are roles, states, and properties. The dozens of attributes and role values possible in ARIA provide significantly enhanced semantics and accessibility detail over HTML alone. Basic ARIA attributes such a landmark roles, various roles to define the function of non-standard interactive elements (e.g., sliders, links used as buttons, etc.), aria-required for required form elements, aria-labelledby to enhance labeling for complex form elements, and so forth can be easily implemented now without any negative impact on functionality, presentation, or accessibility.

Hidden Screen Reader Content

Difficulty: Advanced

Category:

Content
Presentation

By positioning content off the left side of the visible screen using CSS, it removes it from the visual presentation of the page, but allows it to still be read by a screen reader. Off-screen text should be used with care and generally only in cases where information or structure is apparent visually, but may not be readily accessible to a screen reader accessing it linearly. Content hidden with display:none or visibility:hidden in CSS is not read by a screen reader.

For more information, see Invisible Content Just for Screen Reader Users

User Style Sheets, Specified Colors, and Page Flexibility

Difficulty: Advanced

Category:

Presentation

The end user always has ultimate control over what the page looks like. They can apply user style sheets to change font sizes, colors, layout, or any other property of the page. As much as possible, web pages should be designed to accommodate user customization. This means that the page has specified foreground and background colors for all elements. Each element need to be defined specifically due to the cascading nature of CSS, but at a minimum, the body element should have a foreground (color) and background (background-color) color specified in CSS. These colors must have sufficient contrast. This helps ensure that if the user overrides page colors, that each page element can be adequately overridden to remain readable. The page should also be designed so that page elements to not overlap or become invisible when text is increased or when the browser size is very small or very large. Bulletproof and flexible web design is an important aspect of usability and web accessibility.

Link Focus Indicators

Difficulty: Advanced

Category:

Presentation

A link that has keyboard focus (accessed using the Tab key) is typically identified by a dotted line that surrounds the link. This dotted line is called the focus indicator or link outline. This focus indicator can be removed with outline:0 in CSS. Doing so will make it very difficult for sighted keyboard users to determine which element currently has keyboard focus as they navigate through the page. The default focus indicator can be enhanced by providing additional visual styles when the link receives focus. Typically, any style changes when the user hovers their mouse over a link should be duplicated in the keyboard focus styles. All links should be clearly differentiated from surrounding text for visual users and keyboard-only users.

In your CSS, you can generally change
a:hover { ... }
to
a:hover, a:focus { ... }
to have all hover styles also appear on keyboard focus.

Data Tables

Difficulty: Advanced

Category:

Structure
Presentation

Because data tables are presented and navigated differently by screen readers than layout tables, it is vital that data tables be marked up to support greater accessibility. Row and/or column headers should be identified as such (using the <th> tag) and given an appropriate scope designating that header as a column header or a row header (<th scope="col"> or <th scope="row">). For most tables, this markup will ensure that each data cell is programmatically associated with its appropriate row and/or column headers.

Table Captions

Difficulty: Advanced

Category:

Structure
Presentation

When a visual caption is provided that describes the content of a data table, it should be marked up as a <caption> element. The <caption> element should be the first tag within the table. This associates the caption to the data table and allows it to be identified by assistive technologies.

Example:
<table>
<caption>Fall Class Schedule</caption>
<tr>
...

Title Attributes

Difficulty: Advanced

Category:

Content
Presentation

As defined in the HTML specification, the title attribute is for "advisory information". As such, it should not be relied on to provide accessibility. The title attribute is generally ignored by screen readers, except when used on form elements that do not have labels, frames and iframes, and acronym and abbreviation (though many screen readers and screen reader settings ignore title for even these elements). The title attribute value can be used to present additional, supplementary information, but you cannot be sure it will be read. It is not visible to sighted keyboard-only users or to users who do not hover their mouse over the element (e.g., on touchscreen devices). Additionally, because title generates a browser tooltip when the mouse is placed over an element, it should be used with care and should not present redundant information that is already apparent visually in the page.

Fieldsets and Legends

Difficulty: Advanced

Category:

Structure
Presentation

Groups of checkboxes and radio buttons often have a higher-level description that indicates the purpose of the grouping. In such cases, a fieldset and legend should be used to visually identify the grouping and to ensure that the higher-level legend is read by assistive technologies.

<fieldset><legend>Choose your shipping method</legend>
Radio buttons for shipping options
</fieldset>

Fieldsets can be used for groupings of other types of form elements (e.g., "Shipping Address" vs. "Billing Address"), but should be used with care because the legend is identified for each form element in the fieldset.

For more information, see Creating Accessible Form Controls

Frame Titles

Difficulty: Advanced

Category:

Structure
Validation

Frames (a way of combining multiple web pages into one visual presentation) are not used as frequently today, but when they are used, they must be identified with descriptive text. All frames must be given a descriptive title. The title should succinctly present the content and/or functionality of that frame.

Headings

Difficulty: Advanced

Category:

Structure
Presentation

A logical heading structure greatly enhances the accessibility of a web page. They are used for page navigation and orientation. Each page should generally have one first-level heading (<h1>). While it is usually most logical to have the <h1> present the site name for the home page, for content pages the <h1> should typically contain the document title or main heading for that page. Heading levels should not be skipped, though it's acceptable to have lower level headings (such an <h2>'s) precede the <h1>, if the page structure requires it.

difficult to learn and use. Learning enough to simply listen to a web page and navigate through a web page can be sufficient to identify accessibility issues. Tutorials are available for using JAWS and NVDA for web accessibility evaluation. To ensure that your experience is accurate, turn off your monitor and don't use a mouse.

Succinct Alternative Text

Difficulty: Beginner

Category:

Content
Presentation

Alternative text should be succinct. There is not a defined maximum length for alt text, but a rough guideline of around 100 characters is generally a good threshold. Alternative text longer than around 100 characters typically indicates that the content should be provided some other way (such as in text in the context of the image, on a separate description page, etc.)

Alternative Text

Difficulty: Beginner

Category:

Content
Presentation

Alternative text conveys the content and functionality (if present) of an image. It is very rarely a description of what the image looks like. When authoring alternative text, consider what the core information presented by the image is. Asking the question, "If you could not use the image, what text would you use to replace it?" is often a good test to determine appropriate alternative text.

Images

Difficulty: Beginner

Category:

Content
Presentation

Images can enhance accessibility. The expression "a picture is worth a thousand words" very much applies to accessibility as well. Complex concepts and content can be presented through images, illustrations, charts, graphs, etc. Icons can present complex functionality or information in a very small amount of space. As long as images are given appropriate alternative text and are presented in accessible ways, they can greatly improve the functionality, understandability, and accessibility of a web page.

Tip: Evaluation Tools

Difficulty: Beginner

Category: Validation

Web accessibility evaluation has many aspects. No automated evaluation tool can tell you if your site is accessible. A good evaluation tool will guide a person through evaluation of true accessibility. While guidelines and checklists are useful, a site can be compliant to an accessibility guideline, standard, or checklist, yet still be totally inaccessible to some users. Screen reader or other user testing is a wonderful way to ensure accessibility for that user, but may not provide sufficient insight into true accessibility. Only a combination of effective automated testing, manual checks, and user testing will provide a good assurance of the accessibility of a site.

See the WAVE Web Accessibility Evaluation Tool.

Contrast

Difficulty: Beginner

Category:

Presentation

Determining whether there is enough color contrast between text and background can be difficult. WCAG 2.0 has contrast guidelines at both level AA and level AAA and a complex formula for determining a contrast ratio. Large text (over 14 point bold) requires slightly less contrast than 'normal' text.There are many tools, such as WebAIM's color contrast checker that can generate this contrast ratio and give immediate feedback whether the contrast is sufficient. Simply enter a foreground and background color to see the results. Users of the Firefox web browser can use the Colorzilla add-on too easily select color values from within the web page.

Link Contrast

Difficulty: Beginner

Category:

Presentation

Links should be clearly distinguishable from surrounding text. The default underline for links clearly distinguishes them visually. Underline should generally not be used for text that is not linked. If underlining is disabled in CSS for links, WCAG 2.0 requires sufficient contrast between the link text and the surrounding non-link text. Because the linked text and the non-linked text must also have sufficient contrast from the background, the window of colors available for non-underlined links is very narrow. WCAG 2.0 also requires that non-underlined links provide a non-color designator (typically addition of the underline) on both mouse hover and keyboard focus links are clearly differentiated as users interact with them. The easiest way to avoid these additional requirements is to underline your links by default.

Text Size and Zoom

Difficulty: Beginner

Category:

Presentation

Content must remain readable and understandable when text size or page zoom is set to at least 200% or twice the default size. While it is optimal to decrease the likelihood of horizontal scrollbars or changes in visual design or document layout at these settings, readability and understandability are most critical to accessibility. This can be tested by selecting Control + (or Command + on a Mac) in your web browser or by increasing the text size under the View menu.

Robustness

Difficulty: Beginner

Category:

Validation

Robustness addresses the technology implications of accessibility. It requires following web standards (e.g., valid HTML and CSS), creating content/functionality that works across various user agents (web browsers and assistive technologies), ensuring compatibility with various hardware (such as mobile devices), and considering present, future, and older technologies. While it does not mean that a web site must be compatible with all present, future, or former technologies, it does suggest that consideration be given to ensure accessibility to the broadest range of technologies feasible.

Cognitive Disabilities

Difficulty: Beginner

Category:

Principles
Content

The number of people with cognitive disabilities is greater than the number people with all other disabilities combined. Cognitive disabilities are complex and vary greatly. Recommendations for those with cognitive disabilities share much overlap with general usability recommendations, however, the impact of poor usability and understandability can have a much more significant impact on those with cognitive disabilities. Care should be taken to ensure optimal functionality and understandability of web content by those with cognitive or learning disabilities.

Alternative Versions

Difficulty: Beginner

Category:

Principles

Building one version of a site that is highly accessible is the best approach to accessibility. Providing alternative versions or directing users to accessible or mobile versions of a site can be interpreted a segregation and separation, particularly if the content and functionality is not similar or equivalent to the main site. Statistics show that screen reader users are not likely to use this content anyway. A good site has full accessibility built in naturally, thus removing the need for alternative versions.

Skip Links

Difficulty: Beginner

Category:

Structure
Presentation

"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. These links must be one of the first links on a page and must be visually apparent in order to provide quick access to the main content for keyboard users, including screen reader users. They can be intrusive to visual design. However, because "skip" links are really only useful to keyboard users, they can be hidden from view until they receive keyboard focus, at which point they are presented visually and prevalently within the page - thus maintaining high utility to both sighted and blind keyboard users, but having no impact on other users - they probably won't even know that the link exists.

Error Prevention, Validation, and Recovery

Difficulty: Beginner

Category:

Content
Presentation

Form error prevention, validation, and recovery techniques can have a significant impact on site usability and accessibility. Forms should be easy to understand, complete, and submit. If there are problems with a form submission (e.g., the user did not complete a required form field), you should:

Alert the user to the presence of the error in an apparent and accessible manner
Allow the user to easily access the form elements that need to be modified
Allow resubmission and revalidation of the form

Clear and Simple Writing

Difficulty: Beginner

Category:

Content
Presentation

Clear and simple writing is one of the most important, yet often neglected, aspects of web accessibility. Technical accessibility provides access to content, but that content must be written and presented so it is understandable by the audience. This includes considering the use of headings and content sections, avoiding slang and jargon, being mindful of the required reading level, defining acronyms and abbreviations, avoiding misspellings, and presenting the text in a highly readable font face and presentation.

Multiple Ways of Accessing Content

Difficulty: Beginner

Category:

Content
Structure
Presentation

Some users prefer using a search form to quickly find information. Others may follow navigation or other links. Others may prefer a site map or index. Providing multiple ways of getting to content will improve the usability and accessibility of your site.

Line Length

Difficulty: Beginner

Category:

Presentation

Pages should be designed so the line length, the number of characters that appear per line, should be neither too short nor too long. Anything more than around 80 characters can introduce reading difficulties in scanning from the end of a line of text to the beginning of the next line. Short line lengths also introduce difficulty and vertical scrolling. The width of the body area of a web page should be constructed to ensure that lines of text are constrained to both minimum and maximum lengths across both small (such as mobile devices) and large screen resolutions.

Animation

Difficulty: Beginner

Category:

Presentation

Animation or other moving elements on a web page can be distracting to all users. Even simple animation can render a web page completely inaccessible to users with certain cognitive disabilities or high levels of distractibility. Animation should generally be avoided. Brief animations (ones that completely stop in less than 3 seconds), however, can be used to draw attention to important page elements, such as error messages or alerts.

A common use of animation to increase accessibility and usability is the implementation of what is called the Yellow Fade Technique. This technique presents a bright, quickly fading background to important page elements or messages.

Seizure Inducing Media

Difficulty: Beginner

Category:

Presentation

Flashing, strobing content can cause photo-epileptic seizures. In order to cause a seizure, strobing content must flash more than 3 times per second, be sufficiently large, and have significant contrast in the flashes. The color red is also more likely to cause a seizure. Bright flashing content, particularly in videos, must be avoided.

Keyboard Accessibility

Difficulty: Beginner

Category:

Structure
Presentation

Ensuring that your web page is fully accessible using only the keyboard is a vital component of web accessibility. All interactive elements, including links, buttons, form fields, media controls, etc. should be accessible using only the keyboard. Use the Tab key to navigate through page elements. Shift + Tab will navigate backward. The Enter key will typically activate links, buttons, etc. The navigation order of interactive elements should be logical and intuitive. It should generally follow the visual presentation order (left to right, top to bottom). Particular care should be taken to ensure that forms can be completed and submitted using only the keyboard. If you must press the Tab key a significant number of times to interact with a page, consider adding a "Skip to main content" or "skip navigation" link.

Week 11 Page Title

Difficulty: Beginner

Category:

Content
Presentation

Providing a descriptive, succinct page title is important for accessibility. The page title (usually appears at the very top of the browser window) is the first thing seen by sighted users, is the first thing read by screen readers, and is used by people and search engines to determine the content of the page. Because the page title is read on each page, it should be short (generally no more than a few words). The site name and other information may be included in the page title if it is succinct and informative (e.g., "Acme, Inc.: Order Form")

Week 10 Form Labels

Difficulty: Beginner

Category:

Structure
Presentation
Validation

Most types of form elements (text boxes, text areas, checkboxes, radio buttons, etc.) have a text label adjacent to them that identifies the function of that particular form element (e.g., "First name" adjacent to a text box). Sighted users make a visual associate between a label and its corresponding form element based on proximity and positioning. A user who is blind cannot make this visual association, so the label must be programmatically associated with its form element using the HTML <label> tag. When properly associated, a screen reader will read the text label when it encounters the form element.

<label for="fname">First name:</label> <input type="text" id="fname">

For more information, see Creating Accessible Forms

Week 9 Conveying Information Using Color Alone

Difficulty: Beginner

Category:

Presentation

Avoid using color or other stylistic differences as the only means of conveying information or meaning. Blind users do not care about the color, font size, or styling of text, so long as the visual aspects of that text are not used to convey content. Screen readers generally do not present stylistic information to the end user. Users with certain types of color deficiencies (color blindness) may not be able to differentiate certain color combinations. Users with low vision may override page colors. Each of these may have difficulty differentiating content based on color alone. The following relies on color to convey information:

The green mushrooms listed here are OK to eat. The red mushrooms will kill you.

Amanita
Chanterelle
Porcini
Shitake
Tylopilus

This can be made accessible by simply creating two lists - one for mushrooms that OK to eat and one for mushrooms that will kill you.

Week 8 Color Dependency

Difficulty: Beginner

Category: Presentation

Individuals with color-blindness or color deficiency may have difficulty in differentiating between certain color combinations. This affects approximately 7% of males and .1% of females. Difficulty in differentiating red and green is most common - these are most often the colors used to convey meaning or differences. While using appropriate colors, providing good color contrast, and not using color as the only means of conveying content is important for those with color-blindness or color deficiency, these techniques may also improve accessibility to those who are blind (screen readers do not typically identify color) or have low vision (these users may override page colors to make the page more readable). An easy test for color dependency is to print the page on a black and white printer and see if any information is missing when the color is removed from the page.

Week 7

Descriptive Link Text

Difficulty: Beginner

Category:

Content
Presentation

Screen reader users often navigate a page by reading only the links. The link text (typically blue, underlined text) is read. The function of the link should be available from the link text itself. Ambiguous links, such as "click here", "more", etc. do not provide useful information to these users. The user must navigate or read the link's surrounding context to determine what they link does or where it goes. These ambiguous links should be avoided and can almost always be made clearer.

Example:
Change "To perform a search, click here" to "Perform a search".

Week 6

Captions and Transcripts

Difficulty: Beginner

Category: Principles, Content, and Presentation

In order for multimedia content to be perceivable to the Deaf and hard-of-hearing, captions and transcripts must be provided. Captions provide a synchronized text presentation of the audio content. Beyond providing basic accessibility to users with auditory disabilities, captions are also useful to other users in noisy or very quiet locations, increase accessibility to those with cognitive or learning disabilities, and provide enhanced comprehension of complex content. They are also helpful when the audio is unclear or in a language that is not well known.

Transcripts provide a static text version of the spoken dialog. Transcripts allow the information to be searchable (by both users and search engines), remove the time-based nature of the content (they can read the transcript at their own pace), and allow the content to be accessible to screen readers and refreshable Braille devices.

Captions and transcripts should be provided for video content and transcripts alone should be provided for audio content (e.g., podcasts).

Week 5

WCAG 2.0

Difficulty: Beginner

Category:

Principles
Validation

The Web Content Accessibility Guidelines (WCAG) 2.0 is a W3C (World Wide Web Consortium) specification for measuring web accessibility. WCAG 2.0 is based upon four core principles - perceivable, operable, understandable, and robust; or as an acronym - POUR. Ensuring POUR content across disabilities will ensure highly accessible web content. These guidelines are most useful as tools for implementing and evaluating accessibility, but true accessibility is determined by the end user experience, not by compliance to a set of rules. Level AA conformance with WCAG 2.0 is a common standard measure of good accessibility.

Week 4

Screen Readers

Difficulty: Beginner

Category:

Principles
Structure
Presentation

A screen reader is a type of assistive technology that reads the text content of a web page audibly to the user. It is primarily used by individuals who are blind or have low vision, but can also be useful to individuals with certain cognitive or learning disabilities.

Screen readers read the text content of a web page linearly based on the underlying source code order - left to right, top to bottom. Screen reader users typically do not use a mouse, but instead use a wide array of keyboard shortcuts to navigate and interact with a web page. A screen reader can also output content to a refreshable Braille device to form Braille characters, thus allowing users who are deaf-blind to access web content. Design webpages with these principles in mind - techniques required include providing skip navigation links so that the screen reader users can bypass navigational menus and jump directly to the content, associating form labels with their appropriate form elements so the purpose of each form control is identified, identifying data table headers to aid in table orientation and navigation, etc. Much of web accessibility is about ensuring compatibility with screen reader technologies.

Week 3

Assistive Technologies

Difficulty: Beginner

Category: Principles

Assistive technologies, or AT, are technologies that help one overcome some physical issue or limitation so they can function in ways they otherwise would be unable to. AT includes both software and hardware. It can range from screen readers which convey information audibly to those who have visual or cognitive disabilities, to captions for the Deaf or hard-of-hearing, to refreshable Braille devices which present content to those who are deaf-blind, to screen enlargers for those with low vision, to physical devices to assist those with varying levels and types of motor function. For a web site to be accessible, it must be compatible with varying assistive technologies.

Week 2

Defining Web Accessibility

Difficulty: Beginner

Category:

Principles

Web accessibility is about reaching the broadest range of users regardless of age or disability. A web site can always be made more accessible, and thus, will always be inaccessible to someone. Guidelines, policies, and laws provide measures of accessibility that can be useful in establishing goals and in evaluating accessibility. Viewing web accessibility as a continuum on which improvement can always be made will help ensure that accessibility is continually improving and that it is about people, not merely compliance with law or guidelines.

Web Accessibility Tip Week 1

Considering Various Disabilities

Difficulty: Beginner

Category:

Principles

Web accessibility affects the following disability categories

Visual disabilities - blindness, low vision, and color-blindness
Auditory disabilities - deafness and hard-of-hearing
Motor disabilities - difficulty using a mouse or keyboard
Cognitive or learning disabilities
Photo-sensitive epilepsy

While care should be taken when grouping anyone into a category, when approaching web accessibility issues, it's often useful to consider the distinct needs of users with each of these types of disabilities.