Skip to content

Accessibility Analysis

Jump to bottom
Matthieu Aubry edited this page Jan 11, 2018 · 1 revision

Accessibility improvements are discussed in this issue: #4167

Introduction

This analysis has the goal to point WCAG 2 AA level Piwik errors. Errors have been automatically checked with www.validatore.it (an Italian AChecker version) and after, the interface has been manually analyzed with Firefox 27 on WinXP PC.

The target of analysis is Piwik 2.15.0 as seen on Demo Website. The task is about development ticket 4167

This document structure tries to replicate the Evaluation report written by Matthieu Aubry and based on Chris Hofstader blind user test with NVDA Win 8.1 and Firefox https://github.com/piwik/piwik/wiki/Accessibility-report.

Any error, is marked with corresponding WCAG 2 success criterion, in order to facilitate understanding and correction. In fact for any criterion are well documented techniques http://www.w3.org/WAI/WCAG20/quickref/.

General

As a general requirement an accessible page must be Compatible so its code must be validated according to 4.1.1 criterion and if is an interactive component (ex. a menu a select, etc.) should be also conform to 4.1.2.

This means that an accessible application, must have all valid pages. For an application, using elements that come from external plugins, means that all of them have to follow a quality check or a production guide-line conformance, they can't just work. This could mean a rigid quality (accessibility) testing and releasing, at least of official plug-ins.

Accessibility of data visualization and interfaces

Piwik is a tool to collect analyze and show data. Showing data is related with accessibility problems. Because people has different limits in view some kind of things. Visually impaired people are not only blind, they cold not distinguish color, see text too small and many other issues. So color alone must me not be the only way to convey information (like "I'm a link" or blu bar represents Explorer users, red Firefox etc.).

To blind people could be hard to read graphs or maps, they could prefer tables and ways to filter or export data. For first glance understanding, giving all users a summary (in text) of what represents data is always a good idea. This already happens for example in Visitors>Overview at Report section. Making this section easily reachable avoiding passing through inaccessible content can be The Accessibile Solution: making all elements accessible in some cases could make the important information less evident.

A tag cloud representation may have the usual visualization, but an underlying code that expresses better the order. A tag cloud can be coded as a simple <ol> with the BIGs at first and smalls at the end. Accessibility is finding an alternative, usually just for what can be seen by all the other users.

This is true for blind people but also for people with movement disability, so skip link for jumping section must be sown to keyboard users.

Other user need to enlarge font, zoom so responsive layouts can help, but must be tested in many conditions, not only changing browser size, but zooming while changing font size.

Easy interfaces and easy solutions have to be preferred, with the right scripting and behaviors they could be more graceful than complex ones.

#Dashboard Dashboard can vary from user to user, installation, widget chosen etc. so we will analyze single elements of interface.

Menu

Admin and User Menu

  • 2.1.1. Language selector can't be operated with keyboard. Seen the hidden <select> of languages could be but is hidden, and the visible language menu is used for autocomplete which is disabled. A simple solution could be to restore defaults or using a WAI-ARIA roles menu.

  • 2.4.1 Bypass blocks a menu is a repetitive element on pages, usually after choosing an item, a user needs to access content on linked page. So a way to skip menu is required.

  • 2.4.7 Focus visible: when tabbing between elements (or passing hover with mouse) focus is slightly or not visible. Browser default when tabbing is barely sufficient, and there are many techniques to improve it. http://webaim.org/ has a good one to do so via a simple script. The same site has also a non obtrusive way to give a solution to point 2.4.1.

###Main Menu

  • [ ] 2.4.7 Focus visible PR #9193
  • [ ] 4.1.2 menu and site selector must be WAI-ARIAzed Merged PR #9149

Site selector

  • 2.1.1. It can't be reached by keyboard
  • 2.4.7 Focus visible
  • 4.1.2 menu and site selector must be WAI-ARIAzed

WAI-ARIA, HTML5 and Menu

Seen Piwik uses HTML5, menu items should be also included in correct elements. <header> for the part containing the menu and <nav> is for main navigation.

For HTML5 pages, WAI-ARIA can be used to improve future accessibility and interaction with assistive technology. Both are not officially a standard but they are well supported. Using WAI-ARIA is a small effort, it means to add a few attributes to HTML elements, in order to clarify its role and behavior in the application.

A good and complete guide could be http://dev.opera.com/articles/view/introduction-to-wai-aria/

A simple explanation of how to use correct WAI ARIA attributes on tabbed menu can be found here

Controls

###The Calendar Control (js bug? 1.4.4 Resizing text (CTRL++) makes this control overlap first widget in Dashboard. Sometimes the javascript isn't loaded correctly, so this control content is mixed with the underlying one. This may be a bug: doesn't always happen - WIN XP & FF 27)

  • 2.1.1. It can't be reached by keyboard by a non blind user: the widget can't be opened nor closed. Once opened with mouse, the calendar isn't easily operable with just keyboard, and is not possible to do some operations. Chris' suggestion of normal combos or fields may be subscribed. The Period Radio group is operable, also if focus is on the next element (this means that I activate month, when the cursor is flashing on Year's radio!)

Other errors are minimal or not influent because of this previous one. For example prev and next month, are link made by an empty span. this means a blind person can't understand. But if an alternative to calendar is found, there is no need to fix all the errors in this control.

  • 2.4.3 and also Usability note Meaningful sequence. To use the calendar and choose different periods, you first have to click on right the radios to choose (week, month etc.) and after on the left to choose the period. In countries where writing is from left to right, the sequence of actions must be from left to right. So radios should be put on the left of the calendar or date combos. This is also an accessibility requirement.

The Segment Control

  • 2.1.1. It can't be reached opened or closed with keyboard. This is true also for its content.

This control has also many problems in visualization of the "Add sequence" window. At small resolutions (1024px wide) is over boarding. Select list of segments can be opened, read and closed, but no element can be selected. The visibility of segments menu are also not reachable by keyboard.

The Widget Control

  • 2.1.1. Same as all previous control. Can't be opened, closed, and content is not selectable with just keyboard.

  • 2.4.3 Sub-menus (in code) are far from the item that's been chosen. There is a list for firs level items, and after another list. Sub-menus must be nested.

	<ul>
		<li class="selected">item
			<ul>
				<li>submenu item</li>
				...
			</ul>
		</li>
		<li>item...

The Information Widget

  • 1.4.4 At 1024 and a Zoom+2 this panel is hidden by the ones on its left. Absolute positioning can be a problem when resizing.

  • 2.1.1. as usual. Can't be opened nor content used.

Dashboard content: Widgets

Before fixing accessibility of widgets, is importaznt to consider if it is worth the effort: same information of widgets is present in corresponding pages. Maybe fixing page accessibility could be enough, at list in the beginning of accessifying process

HTML5 gives attributes to define page regions, using them helps to satisfy forward compatibility. It could help also use <main> <header> and <footer> elements to structure page. This is true form dashboard page, but also for all the other ones. We don't know if a widget must be considered an <aside> or a <section> of the page, in any case using an H1,2 or 3 for its title could help user to find them.

In general, widgets have common elements, like title, buttons to refresh, minimize etc. Some of widgets' components are also found in other parts of the application, like widgets containing tables that have controls to export data or change visualization. We'll avoid repeating for all widgets same issues, or list all of them here. We'll do it later, when analyzing pages.

  • Widgets have the option to rearrange them with drag'n'drop, also if this can be "accessified" this is not a Piwik core function so it can be ignored.

  • 1.1.1 Alternatives on buttons must be put first of all in ALT attribute, not on TITLE. Important If an image is the icon of a text that immediately follows the icon, the ALT text should be empty (we refer for example to browser table)

  • 2.1.1 like many parts of Piwik, content is hardly operable with keyboard (minimize, refresh but also export, show rows drop-down etc.) especially those who appear only on mouse over. Without mouse, they are not visible!

...

#Visitors

  • 1.3.1 menu check-box are non explicitly associated. See this is an option useful only to blind user. The solution can be postponed, seen it has effect on graph which is not the main way to access data used by blind people. http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140311/H44

  • 2.1.1 ? or H1 can't be clicked with Keyboard, and link doesn't move focus on Help paragraph. Once the help link will be operable, the help paragraph should have an id, so that the link can bring focus on it. Metrics menu, can't be accessed (opened, closed or check-box inside) Annotations under graph can't be added.

  • 2.4.6 There is no <h1> this is missing everywhere. This is not a vital question but headings are not correctly nested.

###Export menu This function is in many widgets and could be very useful for those data and graphs that are not directivity accessible. Using other software to access data could always be the alternative while Piwik team fixes accessibility. Think about prioritize this fix. Think also about not opening it horizontally, but under the icon. In some cases the use could be difficult because it shifts commands on the right. In some other cases when used in widgets may not adapt to all resolutions and columns arrangement

  • 1.1.1 Alternative missing, TITLES are used, ALT are required on icons. RSS icon has no ALT. Export as image also is missing ALT, but can be left blank.

  • 1.3.1 Menu item should be put in HTML list element <ul>

  • 2.1.1 No access with keyboard. Export has image can't be operated neither the pop-up.

  • A function that directly asks to save image, would be more accessible as alternative, image in pop-up "Export as image" must have a TABINDEX

  • 1.4.3 Contrast of red on gray is not valid, a substitution could be #991E16 on #D9D9D9

###Rows to display (select) This select could just be a simple select, if not so, much work must be done, especially with WAI-ARIA http://www.w3.org/TR/wai-aria/complete#list

As usual the most relevant error is:

  • 2.1.1 No access with keyboard

This control is issued in Chris' analysis at https://github.com/piwik/piwik/wiki/Accessibility-report#visitorsvisitor-log

Visitors/Visitor Log

  • 1.1.1 ALT on icons in visitors column, no alt on footer icon "View detailed visitor log"

  • 1.4.1 Link can be distinguished from simple text only because of their color. An underline is needed at least for links that are in content. Menus, or so don't need underline

  • 2.1.1 No access with keyboard on NEXT list link, under table and on "View detailed visitor log" in the footer. Same happens to limitSelection select, but said once forever in previous paragraph (Rows to display (select))

Visitors/Custom Variables

  • 1.1.1 ALT on sort arrow is absent. There is also no alternative that indicates by which column the table is sorted. Must have an alternative both the state and the command. Can't percept data that appear only with mouse over (percentage)

  • 2.1.1 Can't open rows, row evolution or sort with just keyboard. If you "mouseover" a row than the keyboard can reach visible command (live row evolution) This problem affects all data tables, so data analysis could be very poor. ###DataTableFooterWrap This footer like others is not accessible with keyboard, command have no ALT text. This is true both for visualization icons on the left and Table configuration icon.

Visitors/Devices

This section looks like the Dashboard home page, as previously said, widgets, widget headings, and widget footer have many problems already described. Just one note: icons in these widgets (browser, plugin, system,...) for the very first time, have both ALT and TITLE attribute. This is maybe the most correct and compatible way to add alternative text.

Seen all the other pages present the same kind of widgets, further analysis is useless.

Actions

Pages table had been covered by previous table analysis. In this specific case, table rows should have a [+] sign to open row data. In our installation we didn't have the choice to see if it was working with keyboard, but we assume that it still is not working as it happened in previews Piwik releases.

Transitions, Overlay and Evolution are functions that can be considered "advanced" and more difficult to fix. We'll avoid to analyze them in this document.

Administration's accessibility

This analysis is focused only on users accessibility just because users are more than admins! But a Piwik admin can also be a disabled people so at least must be fixed users and site management. We will not analyze user and admin sections deeply but, we suggest to fix

  • Website management
  • User management
  • General settings

where labels are missing or are not always explicitly associated, some colors in highlighted text or notes are color on color (ex. blu on light blue) but more important command like Edit or Delete are non accessible.

Clone this wiki locally