Back to KATS Network Publications

Back to KATS Network Homepage

Web Accessibility Tips

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.

Evaluating Web Accessibility with WAVE

WAVE is a free web accessibility evaluation tool found at 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.

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.

Text Readability

Keep the following guidelines in mind for displaying text:

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.

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.

Do Not Require Unnecessary Form Data

One of the keys to creating highly accessible forms is to avoid as many errors as possible before the form is submitted. Ensure that forms are as simple and intuitive as possible, and don't require that a field be filled out if the content is not necessary (e.g., a telephone number to subscribe to an email discussion list). Errors can also be prevented by allowing informatoin to be entered in a number of logical formats. For example, allow a telephone number to be formatted: (123)456-7890, 123-456-7890, 123.456.7890, or 1234567890, as long as ten numerals are present. This data can easily be reformatted using scripting or database languages for further usage.

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.

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.

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 title attribute value (which is intended for this type of advisory information).

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).

Auto-playing Audio

Audio, such as background music, that automatically plays when a user comes to a web page can be very distracting and will interfere with screen reader audio. WCAG 2.0 Level A requires that "a mechanism is provided to stop, pause, mute, or adjust volume for audio that automatically plays on a page for more than 3 seconds". It is usually better to not automatically play audio, but allow the user to manually play the audio if they choose.

Pop-up Windows

Pop-up windows (new windows that are triggered automatically or when a user activates a link) can cause confusion and disorientation for all users. While screen readers typically indicate that a new window has opened, managing multiple windows can be complicated, especially for blind users. Because of the various difficulties with pop-up windows, they should generally be avoided. If pop-up windows are triggered via a link, the user should typically be informed within the link text that the link opens a new window.

Layout Tables

Tables in HTML are intended for tabular data. Although using tables for page layout is not considered best practice, this typically has minimal impact on accessibility, as long as two primary guidelines are kept in mind. First, do not use any markup that is typically used to identify data tables. This includes table headers (<th>), <caption>, and <summary>. These tags are often used by a screen reader to detect the presence of a data table, which is read very differently. Second, the reading and navigation order of layout table content (based on the source code order) must be logical and intuitive (e.g., typically the same as the visual order).

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 alt attribute. 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 ismap attribute) 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.


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 lang attribute 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 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).

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.


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 508 and 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.

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.

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:

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.

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.

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.

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:

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.

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 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.

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:

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.

Back to KATS Network Publications

Back to KATS Network Homepage