| Info | ||
|---|---|---|
| ||
This is a draft of a plan to target WCAG 2.0 Level AA in uPortal that we hope to complete, discuss, and ratify in the community. Following that, we plan to convert this document to Markdown and commit it to the main uPortal repo in Github. |
| Table of Contents | ||||
|---|---|---|---|---|
|
At minimum, new sites or web sites that have undergone substansive change will also comply with WCAG 2.0 Level AA. Whenever possible, we should comply with the even stricter standard of WCAG 2.0 Level AAA.
...
General Guidelines (for level A and AA)
Here are a few guidelines, from http://webaim.org/standards/wcag/checklist, to follow.
Guideline 1.1
Text Alternatives: Provide text alternatives for any non-text content (more info|http://www.w3.org/TR/WCAG20/#text-equiv-all)
- All images, form image buttons, and image map hot spots have appropriate, equivalent alternative text.
- Images that do not convey content, are decorative, or contain content that is already conveyed in text are given null alt text (alt="") or implemented as CSS backgrounds. All linked images have descriptive alternative text.
- Equivalent alternatives to complex images are provided in context or on a separate (linked and/or referenced via longdesc) page.
- Form buttons have a descriptive value.
- Form inputs have associated text labels.
- Embedded multimedia is identified via accessible text.
- Frames are appropriately titled.
Guideline 1.3
Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure
...
- Semantic markup is used to designate headings (<h1>), lists (<ul>, <ol>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>, for example), etc. Semantic markup is used appropriately.
- Tables are used for tabular data. Where necessary, data cells are associated with their headers. Data table captions and summaries are used where appropriate.
- Text labels are associated with form input elements. Related form elements are grouped with fieldset/legend.
Guideline 1.4
Distinguishable: Make it easier for users to see and hear content including separating foreground from background
...
- If the same visual presentation can be made using text alone, an image is not used to present that text.
Guideline 2.1
Keyboard Accessible: Make all functionality available from a keyboard
...
- All page functionality is available using the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard (e.g., free hand drawing).
- Page-specified shortcut keys and accesskeys (accesskey should typically be avoided) do not conflict with existing browser and screen reader shortcuts.
Guideline 2.4
Navigable: Provide ways to help users navigate, find content, and determine where they are
...
- It is visually apparent which page element has the current keyboard focus (i.e., as you tab through the page, you can see where you are).
Guideline 3.2
Predictable: Make Web pages appear and operate in predictable ways
...
- Elements that have the same functionality across multiple web pages are consistently identified. For example, a search box at the top of the site should always be labeled the same way.
Guideline 3.3
Input Assistance: Help users avoid and correct mistakes
...
- If an input error is detected (via client-side or server-side validation), provide suggestions for fixing the input in a timely and accessible manner.
Guideline 4.1
Compatible: Maximize compatibility with current and future user agents, including assistive technologies
...
- Markup is used in a way that facilitates accessibility. This includes following the HTML/XHTML specifications and using forms, form labels, frame titles, etc. appropriately.
Tools
Here are some useful Accessibility tools
...
- chrome extension: https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb
- chrome extension code: https://github.com/GoogleChrome/accessibility-developer-tools
HTML Code Sniffer / Pally
- HTML_CodeSniffer is a client-side script that checks HTML source code and detects violations of a defined coding standard. HTML_CodeSniffer is written entirely in JavaScript, does not require any server-side processing and can be extended by developers to enforce custom coding standards by creating your own "sniffs".
- website / bookmarklet: http://squizlabs.github.io/HTML_CodeSniffer/
- source: https://github.com/squizlabs/HTML_CodeSniffer
- Pally - your automated accessibility testing pal. It runs HTML CodeSniffer for programmatic accessibility reporting.
- website: http://pa11y.org/
- Dashboard: Web interface for automated accessibility reporting and graphing. https://github.com/nature/pa11y-dashboard
web service: A simple JSON web service for automated accessibility reporting. https://github.com/nature/pa11y-webservice
command line: Run one-off accessibility reports from the comfort of your command line. https://github.com/nature/pa11y
...