Back to KATS Network Publications
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 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.
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.
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.
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.
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.
Keep the following guidelines in mind for displaying text:
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.
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.
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.
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.
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.
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.
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.
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 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 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.
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.
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).
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.
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).
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 (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.
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).
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 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 (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.
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">).
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).
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.
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.
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.
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.
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 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.
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").
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.
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:
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.<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 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 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 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 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 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 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.
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 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.).
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 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 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.
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.