Jump to: navigation, search

Difference between revisions of "Horizon/WebAccessibility"

Line 16: Line 16:
 
* Screen readers
 
* Screen readers
 
I'm still looking into screen readers that will be useful in our environments.  I'm thinking specifically of  
 
I'm still looking into screen readers that will be useful in our environments.  I'm thinking specifically of  
−
** [http://www.nvaccess.org/]
+
** http://www.nvaccess.org/
−
** [https://wiki.gnome.org/Projects/Orca]
+
** https://wiki.gnome.org/Projects/Orca
  
 
* Underlying components
 
* Underlying components

Revision as of 22:31, 7 May 2014

  • Testing Techniques

A simple way to start testing for accessibility problems is to set aside your mouse and use the keyboard to navigate the interface. You should be able to reach and activate all of Horizon's functions this way. You should always be able to see the focus. The tabbing should happen in a logical order. I expect that Horizon will generally be impacted by http://www.w3.org/TR/WCAG20/#keyboard-operation sections 2.1 and 2.4.

http://css-tricks.com/accessibility-basics-testing-your-page-for-color-blindness/ An informative article that helps understand guideline 1.4.3 (http://www.w3.org/TR/WCAG20/#visual-audio-contrast). Includes links to tools to interactively view web pages with filters to help understand how the page might be perceived by various users. Also includes a calculator to help determine if specific foreground/background combinations have sufficient contrast.

  • WAI-ARIA
WAI-ARIA is a specification that lets rich web applications (Like the Horizon Dashboard!) specify the meaning of HTML elements when they are used in a manner that isn't automatically implied by the tag being used. So if you are displaying a button and you are using a <button> or <input type="button"> html element no extra work is needed. However, if you are displaying a button and its constructed out of
elements you're going to need to use WAI-ARIA tagging so that assistive technology - especially screen readers can use it. Here's a useful introduction: http://rawgit.com/w3c/aria-in-html/master/index.html
  • Screen readers

I'm still looking into screen readers that will be useful in our environments. I'm thinking specifically of

  • Underlying components

One of our challenges with Horizon is that some of the components we build on may not be accessible. This will likely show up more clearly in our testing with keyboard + screen readers. I expect the process will be that we will find some problem. We willl look at where the improper markup/CSS is generated, and find its not generated directly by Horizon but maybe by django, bootstrap, or some other outside code.

I see that bootstrap claims accessibility (well bootstrap 3 does anyway) [1] but I find it curious that there is a bootstrap accessibility plugin [2]. Not sure if we are going to need it.

Our calendar widget is clearly not accessible. (I think this widget has i18n problems too)

For each component we find problems in we'll have to determine if there is another suitable component that supports accessibile, if we can workaround the problem, or if this is best handled by contributing to the component itself.

  • Known Issues:

We inspected the Horizon (Havana release) for web accessibility and found the following problems.

  • 1.1.1 Non-text Contents
    • A few non-text contents such as Network Topology (for Neutron) and Resource Usage (for Ceilometer) have no text alternatives.
  • 1.3.1 Info and Relationships
    • There is no caption element, summary attribute in tables such as instances, volumes, images, so on.
    • There is no scope attribute in th elements.
  • 1.4.3 Contrast (Minimum)
    • text color and background color in the left menu
    • text color and background color in the top menu
    • link color and background color in the main content area
    • text color and background color of the some buttons
  • 2.1.1 Keyboard
    • It's not easy to handle the layered message window by keyboard only.
    • It may be difficult for a blind person to notice this layered error message.
  • 2.4.1 Bypass Blocks
    • There is no mechanism to skip repeated contents such as menu. For example, we can add a link at the top of each page that goes directly to the main content area.
  • 2.4.3 Focus Order
    • The order of navigation doesn't match the visual order in some cases.
    • The focus movement is not restricted to the layered pop-up window.
Retrieved from "https://wiki.openstack.org/w/index.php?title=Horizon/WebAccessibility&oldid=51653"