WiP
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.
The four principles
The overall goal for accessibility is to create web content that is perceivable, operable and understandable by the broadest possible range of users and compatible with their wide range of assistive technologies, now and in the future. These principles have numerous "techniques" that describe how to implement web accessibility. The basic principles include:
Perceivable
Information and user interface elements must be presentable to users in ways they can perceive. This means that users must be able to perceive the information being presented. I cannot be invisible to all of their senses.
Common Perceivable issues
Issue | Technique | Notes |
---|---|---|
This text input element does not have a name available to an accessibility API. Valid names are: label element, title attribute. | Technique: H91 | The technique for this issue tells us that a label element is missing. Add a label or title attribute to the element to address this accessibility issue. |
Img element missing an alt attribute. Use the alt attribute to specify a short text alternative. | Technique: H91 | The technique for this issue tells us that an alt attribute is missing to describe the img in question. |
This element has insufficient contrast at this conformance level. Expected a contrast ratio of at least 4.5:1, but text in this element has a contrast ratio of 3.63:1. Recommendation: change text colour to #317ab9. | Technique: G18 | This technique tells us that the element(s) in question have contrast issues that need to be addressed. |
Operable
User interface elements and navigation must be operable. The user interface cannot require an action that a user cannot perform.
Understandable
Information and the operation of the user interface must be understandable. That means the user must be able to understand the information as well as the operation of the user interace. The content cannot be beyond their understanding.
Robust
Web content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies (AT). This means that users must be able to access web content as technologies advance. Software updates to user agents and AT should not matter when it comes to web content and accessibility.
WCAG
General Guidelines (for level A and AA)
Guideline 1.1
- 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
- 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
- Color is not used as the sole method of conveying content or distinguishing visual elements.
- Color alone is not used to distinguish links from surrounding text unless the luminance contrast between the link and the surrounding text is at least 3:1 and an additional differentiation (e.g., it becomes underlined) is provided when the link is hovered over or receives focus.
- Text and images of text have a contrast ratio of at least 4.5:1.
- Large text (over 18 point or 14 point bold) has a contrast ratio of at least 3:1
- The page is readable and functional when the text size is doubled.
- If the same visual presentation can be made using text alone, an image is not used to present that text.
Guideline 2.1
- 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
- The web page has a descriptive and informative page title.
- The navigation order of links, form elements, etc. is logical and intuitive.
- Page headings and labels for form and interactive controls are informative. Avoid duplicating heading (e.g., "More Details") or label text (e.g., "First Name") unless the structure provides adequate differentiation between them.
- 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
- When a page element receives focus, it does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user.
- When a user inputs information or interacts with a control, it does not result in a substantial change to the page, the spawning of a pop-up window, an additional change of keyboard focus, or any other change that could confuse or disorient the user unless the user is informed of the change ahead of time.
- Navigation links that are repeated on web pages do not change order when navigating through the site.
- 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
- Required form elements or form elements that require a specific format, value, or length provide this information within the element's label.
- If utilized, form validation errors are presented in an efficient, intuitive, and accessible manner. The error is clearly identified, quick access to the problematic element is provided, and user is allowed to easily fix the error and resubmit the form.
- Sufficient labels, cues, and instructions for required interactive elements are provided via instructions, examples, properly positioned form labels, and/or fieldsets/legends.
- 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
- Significant HTML/XHTML validation/parsing errors are avoided. Check at http://validator.w3.org/
- 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
- 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
Tanaguru
- Tanaguru is a free/opensource software (AGPL licensed) for web sites assessments
- Audits include:
- page audit
- entire website audit (Heritrix crawler embedded) - you can uses this to crawl an url from a VM on your laptop which works great for the drupal pages, but cannot access most authenticated pages for those you need to be logged in. See thoughts in "Crawling with credentials", below.
- offline file audit
- scenario audit (user path over a given website)
- website: http://www.tanaguru.org/
- source: https://github.com/Tanaguru/Tanaguru
- discussion forum: http://discuss.tanaguru.org/
- Jenkins Plug-in: http://tanaguru-jenkins-plugin.readthedocs.org/en/latest/
Crawling with credentials
- It looks like this would be technically feasible. See https://webarchive.jira.com/wiki/display/Heritrix/HTML+Form+GET+or+POST
- Here is the place in the tanaguru code where you would add the credentials. https://github.com/Tanaguru/Tanaguru/blob/master/engine/crawler/src/test/resources/full-site-crawl-conf/tanaguru-crawler-beans-site.xml#L439, or maybe if that doesn't work try here: https://github.com/Tanaguru/Tanaguru/blob/master/engine/tanaguru-resources/src/main/resources/conf/context/crawler/tanaguru-crawler-beans-page.xml#L452.
So something like this (with a valid login/password):
<bean
id
=
"credential"
class
=
"org.archive.modules.credential.HtmlFormCredential"
>
<
property
name
=
"domain"
value
=
"example.com"
/
>
<
property
name
=
"login-uri"
value
=
"https://example.com/login"
/
>
<
property
name
=
"form-items"
>
<
map
>
<entry key
=
"login"
value
=
"mylogin"
/
>
<entry key
=
"password"
value
=
"mypassword"
/
>
<entry key
=
"submit"
value
=
"submit"
/
>
<
/
map
>
<
/
property
>
<
/
bean>