Accessibility Valet Warnings
This is a list of warnings and explanations. See also the overview of reports. Note too that every Accessibility Valet warning includes a link to the more detailed explanations in the original guidelines.
- ABBR and ACRONYM should be expanded. Use the TITLE attribute.
- Self-evident.
- Associate labels explicitly with their controls
- Use of the
labelwith theforattribute to identify what it labels can make forms more accessible. - Create keyboard shortcuts and/or a logical tab order between controls
- Links and Form Controls should be easy to select, even for users without
the benefit of a mouse. Consider using
accesskeyortabindexattributes if there is a more logical grouping or structure than simply first-to-last. - Document should identify language
- You should identify the natural language of a document in machine-readable
form; for example with
lang="en". - Do not cause pages to auto-refresh
- Let the user decide how long to spend on a page! Users on slow connections or devices may never see the whole of a page that auto-refreshes.
- Do not limit the user's time at this page
- Let the user decide how long to spend on a page! Users on slow connections or devices may never see the whole of a page that auto-refreshes.
- Do not open new windows without warning the user
- New browser windows can be very confusing, particularly to screen readers. Warn the user when a control will open a new window.
- Do not use onclick for multistate form inputs
- Onclick events can make it hard for the user to make a required selection.
- Do not use [various scripting events]
- Certain scripting events present serious difficulties to some users, most often those who cannot use a mouse.
- Do not use scripting pseudo-protocols for form Actions
- It should be possible to submit a form without clientside scripting.
When you want to use a clientside script with a form, use an
onsubmitevent to run your script, and provice a serverside fallback action for users who cannot use your clientside script. - Ensure alternative presentations for multimedia are synchronised
- When you include multimedia content, it should be comprehensible to people who can see but not hear it, or vice versa.
- Ensure content will not flicker, flash or blink
- Animated images as well as videos and other visual content should not flicker, flash or blink. At best this is distracting; at worst it can present a severe danger to epileptic users.
- Ensure scripting events are device-independent
- Where Javascript is used to provide functionality or information, it should not require a particular device (such as a mouse) to work.
- Ensure statusbar change doesn't hide useful information
- Don't hide useful information - such as the destination of a link - that browsers typically display in a status bar.
- Ensure that documents are readable without stylesheets too
- Self-evident.
- Ensure that information conveyed with colour is also available without it
- If you use colour to convey information, what happens when the user cannot see colour?
- Ensure there is a synchronised auditory description
- When you include multimedia content, it should be comprehensible to people who can see but not hear it, or vice versa.
- Ensure there is an accessible alternative to clicking on the imagemap
- Imagemaps and similar constructs may present problems to some users - eg those who cannot use a mouse. Alternatives should be provided.
- Ensure this field is labelled accessibly
- Form fields should be clearly labelled, for example using
label. - Form should have a means of submission that does not require scripting
- It should be possible to submit a form without clientside scripting.
When you want to use a clientside script with a form, provide a
fallback action and use an
onsubmitevent to run your script. - Frame should have a title
- Navigation amongst HTML Frames is much easier if each frame has a meaningful title - eg "Navigation" and "Contents", but not "Left" and "Right" which convey nothing useful to the reader.
- If onmouse[over|out] conveys information, provide an accessible alternative
- These scripting events are not inherently problematic, but their events may not be accessible to some users. Ensure there is an alternative if the events are important.
- If the [applet|object] requires a plugin, provide a link to one meeting Section508
- Section508 applies to non-HTML content, too! Don't assume your users have the same plugins, or even the same operating system or GUI, as you do.
- If this is a recurrent list of links, provide a means to skip it
- Some browsers - e.g. speech-based systems for the blind - can only read your page by linearising it. Users don't want to hear your navigation bar repeated on every page, so you should provide a means to skip it.
- If this is multimedia, ensure alternatives are synchronised
- When you include multimedia content, it should be comprehensible to people who can see but not hear it, or vice versa.
- Is this really a header?
- Use HTML
<Hn>elements for logical headings, not for presentational effect. - Provide a text alternative
- You should provide a text alternative for the benefit of users who cannot view your main content. A good text alternative will leave the page reading smoothly if the image/object/etc is removed altogether and replaced by the text.
- Provide an accessible alternative to SCRIPT elements
- Use
noscriptcontent to ensure your pages still work when a browser or user cannot use your scripting. - Provide clientside imagemaps where possible
- Clientside imagemaps enable browsers to present a list of active areas to users who need it. Serverside maps make this harder.
- Provide meaningful alternative (noframes) content in frameset
- When using frames, the
noframescontent should offer an alternative to the framed content. - Provide metadata to add semantic information to pages
- Metadata helps to place a page in the wider context of the site, and
even the web as a whole. It can be referenced using
linkor included inline withmeta, - Provide redundant text links for active areas
- Imagemaps and similar constructs may present problems to some users - eg those who cannot use a mouse. Alternatives should be provided.
- Provide summaries for tables
- A table summary should provide a brief description of the contents.
- Set a contrasting background colour when using TEXT attribute
- A reader may have configured their background colour to be the same as your text.
- Should this be a header?
- Use HTML
Hnelements, not emphasis such as <b> or <font>, for headers. - Table axes should be identified
- The purpose of the table structure should be clear.
- Table cells should be associated with headers
- Use HTML tables for tabular data, not for layout.
Use the
scopeattribute to th elements, or use theheadersattribute to the table cells. - Use BLOCKQUOTE and Q to mark up quotations, not for formatting
- Self-evident.
- Use CSS for layout and presentation
- Presentational HTML is deprecated. HTML and XHTML Transitional dealt with Legacy systems in 1998, and is now thoroughly obsolete. CSS offers the user more control, and is therefore less likely to give rise to accessibility problems. The logical separation of content and presentation also makes pages more maintainable.
- Use external stylesheets to create a consistent presentation
- A consistent style for your site helps your users, as well as making your site more maintainable.
- When using a background image, ensure you set a similar background colour
- Is all your text legible even when the background image isn't displayed?