Skip to end of metadata
Go to start of metadata

Introduction and Goals

To better understand the status of the Kuali toolset on compliance with accessibility standards, the Rice team began a research phase in July 2011. The objective was to enable us to identify and size the work needed in  Rice 2.2 or beyond, and KS, to set and achieve a target level – as well as to fix blockers in KRAD 2.0 if possible.   

For additional background information, see https://jira.kuali.org/browse/KRRM-3 and https://jira.kuali.org/browse/KULRICE-6092.

For a summary of the research findings, see the Kuali Days 2011 presentation, that we expanded to report out on the solutions for items that require new approach.

What was covered

As a part of this research phase, the Rice UX architect conducted a baseline heuristic evaluation of the development build of Kuali Rice  (M6/M7).  The evaluation consisted of the following.

Test Platforms:

  • 2 test PCs with Microsoft Windows operating systems:
    • 2 operating systems:  Vista and XP
    • 2 browsers:  Firefox 5.0 and Internet Explorer8
    • 2 Screen-readers:  JAWS 12.0 (screen reader from Freedom Scientific, that has the largest market share today in screen-reading) and NVDA (free, opensource screen reader that is growing in market share)
    • 2 DPIs (affects font sizing, recommended in Windows instead of changing screen resolution – regular and 200%)
    • 2 contrast settings – regular and high contrast (white on black)
  • 1 test MAC with the Apple OS
    • Apple’s LION operating system (new in July 2011)
    • 2 browsers:  Firefox 5.0 and Safari
    • 1 screen reader:  VoiceOver (built into the MAC OS)
    • 2 screen resolutions (1440 x 900 and 800 x 600)
    • 2 contrast settings – regular and high contrast (white on black)

KRAD content:

A sample of the Kuali Rice UI:

  • The Kuali portal UI
  • The KRAD Testing - KNS L&F forms, in particular:
    • The BO Class Tests:
      • Travel Account Inquiry page
      • Travel Account Maintenance (New) page
      • Travel Account Maintenance (Edit) page
    • Non BO Class Tests:
      • Fiscal OfficerInfo Inquiry 2
  • The KRAD Testing - KS L&F forms, that are developing, in particular:
    • The Screen Element Testing
      • Uif Components (Kitchen Sink) –

Evaluation Procedure:

Evaluation conducted by Rice UX architect (csoders@uw.edu):

  • Conducted a heuristic evaluation using the WCAG 2.0 Level A and AA criteria, accessing our software under the following  alternative conditions (successive passes, not all in a single pass):
    • Large fonts (browser settings for font size, and OS settings for screen resolution/DPI (required for low vision users)
    • High contrast settings (required for some low vision conditions)
    • Keyboard-only access (required for low mobility and no vision users)
    • Screen-reading (required for no vision users, who also require keyboard-only or speech access). Tested multiple navigation schemes:
      • Virtual mode, where screen reader simply reads all on the page (e.g., “say-all” in JAWS) while user is passive/listening (not interacting with keyboard)
      • Actively exploring the page with the keyboard, for example in JAWS:
        • with the down-arrow key (“say-next”) and up-arrow key (“say-previous”) - which moves successively forward or backward on the page, reading each element that is visible
        • with the tab key and shift-tab keys (in Forms mode) - which moves successively forward or backward on the page, but moves only through the user-manipulable parts of the page (for example, the entry fields, buttons, combo boxes, expand/collapse controls, links, etc.)
        • with a sample of the other functions JAWS provides for exploring content:
          • the headings list, Insert+F6 (which enables users to understand all headings on the page and then jump directly to the one of their choice)
          • the links list, Insert+F7
          • a sample of the navigation quick keys (e.g., "A*" to move to next anchor, "B*" to move to next button, "C*" to move to next combo box, "R*" to move to next radio button, "T*" to move to next table, F to move to next form control, H to move to next heading
  • Logged Accessibility bugs in JIRA (component= accessibility, Rice module=KRAD, project=Kuali Rice Development, Issue type=Improvement, Fix version=2.1, Application Req=KS).
  • Observed Dan Comden,  manager of the Access Technology Center at the University of Washington, using a sample of KRAD screens with JAWS and NVDA and captured his insights, feedback, and validation of non-compliant areas (incorporated into the JIRAs logged).
  • Reviewed the initial list of problems found (JIRAs logged) in a call with Terrill Thompson,  Technology Accessibility Specialist at the University of Washington, and William Washington, UX architect for Kuali Student and KRAD 2.0.  Provided insightful feedback/validation and pointers to code-structure methods.

(Note, this heuristic evaluation of our software on the WCAG 2.0 accessibility criteria represents a good step forward in understanding where we are (as a baseline), and integrating this step in a QA and user experience process.   It doesn’t, on the other hand, serve in place of evaluations by real non-sighted users of screen-readers.  Over the next year, we will be working to pull together a small set of these end users to engage with us in the process.)

What was found

JIRAs were logged and are being triaged by the Kuali Rice KRAD team.   The full report, that includes where we stand on the WCAG 2.0 criteria, is at this Google doc.

We next researched and reported out (at Kuali Days 2011 and in this report out to the Rice 2.0 team leads.

Next Steps:

  • Discussed with developers the best way to organize issues w/in JIRA:
    • By page/location?  By component?  By theme?
    • How to cluster JIRAs?
  • Triage the JIRAs, determine which can be fixed in KRAD 2.0
    • Code hygiene, no new invention required? -- try to get into 2.0.
    • New design or research or training or technology needed? -- consider sizing/timing -- move into 2.2 those items that can't be fixed in 2.0.   See Rice 2.2 - KRAD requirements
  • Report the accessibility status to the TRC and ARC on the WCAG 2.0 template.  (Report is completed using the WCAG 2.0 template - See WCAG 2.0 criteria - report template and the current status completed in this googledoc).
  • Recommend WCAG 2.0 target level for Rice 2.2 - (Must fix all WCAG 2.0 level A problems first, then target level AA problems).  See the Rice 2.2 - KRAD Requirements and Rice 2.2 - KRAD JIRAs.
  • Research solutions for items that require new approach.  (Interim notes also are available here.)
  • Form small group of non-sighted users who can engage with us in evaluating and having input into our software designs and code structures. 
  • No labels

1 Comment

  1. I've been reviewing the html output from KRAD and found quite a few code/semantic issues that can cause both accessibility and browser formatting issues.  Some of the issues may even contribute to performance limitations.

    It's great to see the WCAG 2.0 target for Rice 2.1.  I was also curious if there's a target for code to validate to W3C HTML standards?  e.g. a goal that everything on the kitchen sink will validate against standards for HTML 4 trans?