Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: added additional accessibility scanners, added screen reader section for common screen readers
Info
titleWiP

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
maxLevel4

Target WCAG 2.0 Level

At minimum, new sites or web sites that have undergone substantial 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.

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:

...

IssueTechniqueNotes
This text input element does not have a name available to an accessibility API. Valid names are: label element, title attribute.TechniqueH91The 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.TechniqueH91The 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: G18This 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.

Common Operable issues

IssueTechniqueNotes
Iframe element requires a non-empty title attribute that identifies the frame.TechniqueH64See technique for ways to solve issue.
Check that there is at least one mode of operation where the keyboard focus indicator can be visually located on user interface controls.Technique: G149See technique for ways to solve issue.

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.

Common Understandable issues

IssueTechniqueNotes
Form does not contain a submit button (input type="submit", input type="image", or button type="submit").TechniqueH32See technique for ways to solve issue.
The html element should have a lang or xml:lang attribute which describes the language of the document.TechniqueH57 See technique for ways to solve issue.

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.

 

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.
Target: WCAG 2.0 AA

WCAG

Web Accessibility Initiative (WAI) (http://www.w3.org/WAI/)
WebAIM’s Introduction to Web Accessibility (http://webaim.org/intro/)
WebAIM’s Resources page (http://webaim.org/resources/)
WebAIM’s WCAG 2.0 checklist (http://webaim.org/standards/wcag/checklist)
508

...

Common Robust issues

IssueTechniqueNotes
This fieldset element does not have a name available to an accessibility API. Valid names are: legend element.TechniqueH91See technique for ways to solve issue.
Duplicate id attributeTechniqueF77 See technique for ways to solve issue.
This text input element does not have a name available to an accessibility API. Valid names are: label element, title attribute.TechniqueH91  See technique for ways to solve issue.
This checkbox input element does not have a name available to an accessibility API. Valid names are: label element, title attribute.TechniqueH91  See technique for ways to solve issue.

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

1.4.1 Use of Color (Level A)    

...

  • 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

2.1.1 Keyboard (Level A)    
  • 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

2.4.2 Page Titled (Level A)    

...

  • 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

3.2.1 On Focus (Level A)    

...

  • 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

3.3.1 Error Identification (Level A)    

...

  • 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

4.1.1 Parsing (Level A)    

...

  • 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 
(there is a Chrome Extension for this as well) 

...

HTML Code Sniffer / Pally

...

Accessibility tools and scanners

Manually sifting through code to determine accessibility issues is a long drawn out process. Thankfully, there are tools to help you on this endeavor!

 

  • 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
    • This was the tool used for the Oct 2016 uPortal accessibility audit. (Github source)
    • Pa11y - 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
      • (Github source)
      • web service: A simple JSON web service for automated accessibility reporting.
     https://github.com/nature/pa11y-webservice
      • (Github source)
      • command line: Run one-off accessibility reports from the comfort of your command line.
     https://github.com/nature/pa11y

     

    Tanaguruopensource
    • open source software (AGPL licensed) for web sites
    assessments 
      • a page audit
    entire
      • , 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
      • and scenario audit
    (
      • which is a user path over a given website
    )
    website: 
      • .
    • aXe tools is an extension for Chrome and Firefox, that enhances the developer tools panel with an accessibility view.

    Screen Readers

    NamePlatformSiteLicensingCost
    ChromeVoxChrome Browserhttp://www.
    tanaguruorg/
  • source: https://github.com/Tanaguru/Tanaguru
  • discussion forum: 
    com/ProprietaryFree
    NVDAWindowshttp://
    discusstanaguruIt looks like this would be technically feasible. See 
  • Jenkins Plug-in: http://tanaguru-jenkins-plugin.readthedocs.org/en/latest/
  • Crawling with credentials

    Open SourceFree
    TalkBackAndroidhttps://
    webarchivejirawikidisplay/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>

    Useful links and additional information

    WCAG