Skip to end of metadata
Go to start of metadata

Rice Accessibility

What is Accessibility?  

Making something accessible means that all people, including those with disabilities, can use it (perceive, understand, navigate, and interact with it). Disabilities involve limitations to visual, aural, physical, vocal, or cognitive/neurological senses.

As more of the world's information and access to government, education and commercial services has moved online, it is increasingly important that they be accessible to all, not to disenfranchise any class of people.

Accessibility Standards and Government Requirements

Today, accessibility is a code standard, supported through the W3C guidelines and ISO standards, with reporting required by many countries, including the US, Canada, the EU, Australia, and Japan, as well as by many states within the U.S.  

In the 1980s, governments began to take the lead in codifying and mandating accessibility criteria and attention, through requiring commercial suppliers to self-declare their status. By the late 1990s worldwide standards groups began to take the lead, in further codifying and refining the technical code-level aspects supporting improvement across technology.      

Worldwide Standards

The Web Content Accessibility Guidelines (WCAG) and the Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) are worldwide standards activities, developed under the auspices of W3C.

WCAG 1.0 

  • Accessibility standards developed with web documents (static content) in mind.  WCAG 1.0 were published in 1999 and have now been superceded by WCAG 2.0 (expanded to rich web content, a more "application-like" / interactive experience, not passive reading).  
  • Included requirement for websites to be accessible with scripting turned off (for example, no javascripts running).  This is not included in WCAG 2.0 (2.0 includes techniques for client-side and server-side scripting, aimed to be technology-agnostic).
  • Priority 1 (must satisfy) is described as level A conformance.  Priority 2 (should satisfy) is described as level AA conformance.  Priority 3 (may satisfy) is described as level AAA conformance. 

WCAG 2.0 and ARIA 1.0

Accessibility standards developed more recently with web applications in mind (assuming use of dynamic content, JS).  

  • WAI-ARIA 1.0 -- the draft is published and the public comment period ended in June 2011.  The working committee will review and respond to all comments and issue their "candidate recommendation" draft, expected to be next spring.  Because this process is open and technology producers have been integrally involved, many of the browsers across the industry have already built in support for these coming standards, and older browsers will not "break" on the new tags/roles (will ignore them).    

Government Statutes - examples

Section 508

Section 508 is a U.S. Federal Government statute that preceded the W3C activity, originally added as an amendment to the Rehabilitation Act of 1973 (added in 1986).  Other countries around the world have similar legislation, as do several states within the US.  

The Section 508 statute originally required federal procurement agents to include accessibility status in their purchase decisions, to give precedence to the most accessible solutions, and to provide a work-around where no full solution could be found.  All technology vendors wanting to be considered in federal bids must complete a self-declaration checklist, called the Section 508 Voluntary Product Accessibility Template (VPAT). 

The Section 508 VPAT checklist and most other governments' self-declaration forms are being "harmonized" with the worldwide standards/guidelines that are now in place and underway through the W3C. 

Section 504

Section 504 was also added as an amendment to the Rehabilitation Act of 1973 (added in 1977), which requires federal agencies and those receiving federal funding to provide equal opportunity for all to access their programs and services, specifically equal access for employees and members of the public who have disabilities.  

Originally, it was interpreted and applied to physical access, and buildings were retro-fitted with sidewalk curb/ramps for wheelchairs, enlarged doorways, elevators,and handicapped stalls in restrooms.  With the advent of electronic access to information content, services, and tools, it is now interpreted to include all.

Current social/legal climate

Though it is not currently a law that all websites and software BE fully accessible,  it is 1) required to report your accessibility status to be selected into federal and state institutions (those states that require that reporting), and 2) required that government and educational institutions and other organizations receiving federal funding provide accessible work-arounds where their main-stream websites and software are not fully accessible.  

There is work underway in the Department of Justice to make it a law that all websites BE fully accessible ("advanced notice of proposed rule-making" was issued in July 2010).  And class action suits are currently enabled under the current Section 504 and Section 508 statutes.  For example, see the below for a few activities in the current social/legal climate regarding accessibility requirements.

National Foundation of the Blind's (NFB's) recent activities:

  • June 2009, NFB sued Arizona State University (regarding Kindle accessibility), settled Jan 2010
  • November 2010 - NFB filed complaint against Penn State University (inaccessible library web site, departmental websites, financial services, and classroom technologies). 
  • March 2011 - NFB filed complaint against Northwestern University and New York University (regarding Google Apps accessibility).
  • May 26, 2011, the Department of Education's Office of Civil Rights sent "Dear Colleague" letters to University presidents, to remind educational institutions of their obligations under Section 504 and the ADA.

Personas - What do we know about special needs users?

Those of us who work with technology creation, don't typically represent the users who have special needs, for example, those without vision.  If we don't use a screen reader, do we know how most blind users do?   For example, how they do they use and navigate through software to get their tasks done?  What approaches do they like and dislike, what are their biggest usage frustrations?  If we don't know our end users, we end up designing for ourselves, which could be a particular problem if we are nothing like one of our end user sets.

We'll be learning more about how special needs users, beginning with those who can't see, interact with our software through screen readers.  We'll post additional information here.

In the meantime, below are some useful resource material links:

Following the code standards that are already codified and being developed further puts us in good position to be accessible, and is necessary to reporting compliance levels.  See information below.

Evaluating and Reporting Accessibility Compliance Level

By law, we must be able to report on our accessibility status.  Because attention to accessibility is still maturing across the world, it may be some time before everything is fully accessible, but forthright reporting is expected.  Vendors who can show a quality process in evaluating and managing accessibility, and who can show progress in implementation, put their organizations at less risk than others who have no process or who "over-claim" their accessibility level.

Our first step is to evaluate and report our support level. Our next step is to determine the timing and plan for improving our support level (assuming we are not already at a AAA conformance level ceiling, described in material below). 

Over the next months, we will be establishing our test conditions (which code checker, which OS, browser, and AT combinations) and target dates, in a comprehensive test plan.

Evaluation Process

Evaluating level of accessibility compliance is not as simple as running an automated code checker, but it isn't a mystery either.  Below is a high-level outline of best-practice in this area.  A fully mature organization goes through all the steps (maturing = crawl, walk, run - with running being the aspirational target):

  • First:  Running a code checker is a necessary step (not sufficient).  Best practice includes this step, with each developer checking own code before we release a milestone (determine which milestone), using one of the code checkers available across the industry.  These code checkers enable developers to see if their UI constructs can be recognized by the standard accessibility API/bridges. For example, it will list all the combo boxes found, all the headers, etc. -- if it doesn't list them, the dev knows something is missing in the code. (We need to establish which code checker to use.)  See section below for a list of code checker tools.
  • Second:  Next step is to manually check to ensure all user-manipulable aspects can be accessed without a mouse, using keyboard only.  For example, can you tab or arrow-key to each entry field, can you tab back and then forward again, can you use the standard browser shortcut keys to get to the window/menu bar controls, etc.?  There should also be no focus stops to elements that are not visible on the screen, and no places where the user is "trapped" (unable to move focus away).  Best practice includes this step, with each developer checking own code before we release a milestone (determine which milestone).   Other organizations centralize this assessment.  
  • Third:  Next step is to select a high contrast theme in the operating system and check that your code inherits the visual treatments.  And select large fonts through the browser settings and/or operating system settings and check that your code inherits the visual treatments.  Try the standard screen magnifiers (test platform definition should specify which).  Best practice includes this step, with each developer checking own code before we release a milestone (determine which milestone).   Other organizations centralize this assessment.
  • Fourth:  Next step is to manually check to find out if all UI affordances can be spoken/alerted by a screen reader, for users who have low or no vision.  You can do this by turning off your monitor and trying out your code with a screen reader.  Many organizations centralize this evaluation since it takes some learning to get used to screen reader controls.
    • Make sure to test in "virtual" mode and "forms" mode in the screen reader. The newest screen-readers automatically enter forms mode when encountering a form, and signal shifts between the two with a sound/tone.  
    • In a time of rapidly developing technologies and standards, most screen readers are constantly playing catch-up, so finding a problem doesn't necessarily mean you are inaccessible. Evaluating each problem will determine whether the standard is supported in the code, but the AT technologies haven't yet been updated, or whether the code is lacking a tag/attribute, etc..  This is the step that depends on the browser and assistive technology chosen.  (For example, Firefox and the free NVDA screen reader have been fastest to support ARIA in the Windows operating system, though JAWs is still the screen reader used by the most people in Windows.  Safari and the Voice-over screen-reader come with the MAC .)  
  • Fifth:  Next step is to manually check to see if all UI aspects that can be selected/modified by a user can be accessed with speech input (e.g., with Dragon Naturally Speaking).  Most teams have not yet gotten to this level of maturity in testing accessibility support, but this is an aspirational goal.
  • Sixth: Best practice includes evaluating with one or more users from the appropriate special needs populations (e.g., blind users).  This enables teams to ensure the usability of the support for these users, in addition to the binary compliance stance (yes/no). Most teams have not yet gotten to this level of maturity in testing accessibility support, but this is an aspirational goal.    
  • Seventh:  Reporting accessibility status.  This depends on the level of accessibility targets, for instance, the levels of WCAG 2.0 (A, AA, or AAA).

Code Checkers

There are many free code checkers available across the web and software industry.  A comprehensive list is available here.  And below is a subset that several sources have pointed to.

Tools mentioned:

ARIA Hackathon
w/JQuery team @
Ontario College of Design

Mentioned By Hans Hillen
(The Paciello Group)

Mentioned By Terrill Thompson
(University of Washington)

1.  FAE (U of I)

      X

      X

      X

2.  AChecker

      X

 

      X

3.  Total Validator

 

 

      X

4.  WAVE

 

 

      X

5.  Adesigner

 

      X

 

6.  ACCprobe

 

      X

 

7.  Open Ajax
       Alliance

 

      X

 

  8.  Ainspector

      X

 

 

  9. Fire-eyes

      X

      X

 

10. Firefox AC
     Extension

      X

 

 

11.  W3C validators:
      HTML
      CSS
      Mobile

 

 

      X

12.  HTML Tidy

 

 

      X

13.  Aviewer

 

      X

 

14.  Web AC toolbar

 

      X

 

15.  Inspect32
    (part of MS SDK)

 

      X

 

Rice 2.0 baseline results

We evaluated the Kuali Rapid Application Development (KRAD) builds for 2.0, to set the baseline, during this accessibility research phase for Rice.  KRAD is new to Kuali Rice, in the 2.0 release.  You can think of KRAD as the user interface layer for Rice, and it includes the classic Kuali Nervous System (KNS) look and feel as well as a rich-web-UI look and feel that is new with Rice 2.0 and will be extended and enhanced in Rice 2.2.   

For additional background on this effort, see https://jira.kuali.org/browse/KRRM-3.  

JIRAs were logged under Component = Accessibility. For example, see Accessibility JIRAs.

After completing the evaluation, reporting and fixing the bugs that possible to fix in 2.0, we'll summarize our status on WCAG 2.0 accessibility levels, for example, whether there is anything that blocks us from Level A compliance - the "must have" criteria; which items block us from Level AA (should have) and AAA (may have).  For a summary of the WCAG 2.0 criteria, see

For a summary of the KRAD baseline evaluation work to-date, see https://wiki.kuali.org/display/KULRICE/KRAD+Accessibility+-+Baseline+evaluation.

Target Level for Rice (future)

The accessibility standards are well documented in WCAG 2.0 (see http://www.w3.org/WAI/WCAG20/quickref/Overview.php), and the baseline evaluation conducted for Rice 2.0 KRAD identified areas we need to fix and then continue to attend to for future compliance.

The Rice target level and criteria are documented here, and this spreadsheet can be used across Kuali projects to manage and track progress  (All A level criteria and a subset of the AA level criteria.  Target will become more aggressive as we progress.)

See the list of the Rice JIRAs logged on accessibility.

See the list of Rice 2.2 - KRAD requirements, which include accessibility items.

Links to other Kuali accessibility information

      Kuali Rice accessibility information:

       Kuali Student accessibility information:

  • No labels