@mattab opened this Issue on September 20th 2013 Member

We spent really interesting time with Julius, an accessibility specialist who is blind and agreed to test the piwik.org website and the software.

How it works

Using a special Screen Reading (Text Reading) software that lets him browse the page, he can go from heading to heading (and optionally go within to read text), go through menus and nested lists, each time the voice will read the label of the element (and read 'link' if the label is clickable), including hidden elements (that would normally display on hover etc).

The screen reader will also read the title of the window, let him look at the list of all links within the page and quickly access one, among many features (all accessible via keyboard shortcuts).

Improving the accessibility of Piwik platform

  • turn the following fake buttons into real links: Calendar + All visits segment + Widget & dashboard
  • let's link to relevant user documentation from within the software report pages (or within the report inline doc)
  • Column description doc should be more accessible, eg. alt text of that column
  • the Report documentation should also be labeled as such and easily accessible within markup
  • Use headings only for real headings: could we use them better within Piwik software?
  • general tip: let's not write "click here" and click proper labels to all links

Summary

The website piwik.org had fairly good standards of web content usability. The Piwik platform was also quite understandable and usable, despite a few improvements to make.

In general, if we write clean HTML markup (use Heading properly, use alt text, proper lists markup, etc.) the UI will be rather accessible by default. Also he mentioned that, if the app can be used with the keyword only, then it is a great start!. We also make great use of table markups (Table Heading th) and alt image text, which were big bonuses for accessibility.

We hope to keep learning about making Piwik more accessible and implement these improvements above so that more people around the world including blind users and people with special needs, can enjoy the power of Piwik, the open analytics platform!

@mattab commented on March 11th 2014 Member

Chris Hofstader has kindly reviewed Piwik from accessibility point of view, and has created a detailed report highlighting what we should improve in the interface: https://github.com/piwik/piwik/wiki/Accessibility-report

@tassoman commented on March 21st 2014 Contributor

Ciao!
I've just updated Github Wiki Pages adding our accessibility analysis written by Mr. Jacopo Deyla (@jdeyla).

In the mean time I've discovered there is a javascript tool called HTML_CodeSniffer that helps measuring pages a11y against accessibility standards. There's also a cool tool based on it, using NodeJS and Phantom. It's called Pa11y.

@mattab commented on March 24th 2014 Member

Thanks for the report guys! we will read and act on it when we can start working on this.

If anyone reading this is interested in accessibility and could help us, please get in touch!

@tassoman commented on March 24th 2014 Contributor

I'll could work on it starting this week, I've just read the developer guide about core contributions so I hope to be helpful soon, let's keep in touch

@tassoman commented on April 17th 2014 Contributor

Ciao, I've discovered just now PayPal Accessibility team developed a plugin that lets AMcharts HTML5 JS library writing accessible charts. Maybe interesting also because of #4969 ticket.

@mattab commented on April 17th 2014 Member

interesting also because of #4969 ticket.
it's true that accessibility of graphs is a challenge for an analytics app like Piwik.

Just looked and it's an interesting concept, but we cannot use it because AMCharts is not free/libre software.

@tassoman commented on April 17th 2014 Contributor

Oh, what a shame. I agree with you and the project about floss. I've downloaded their software looking for licensing notes and I've found "linkware" ... What the heck is?

BTW I've found also credits to 3rd parties software, so maybe they could switch to a "real" and floss licence if they would feel good an integration with Piwik.

@StommePoes commented on August 25th 2014

Re clickables to links: the general idea is, if it goes somewhere then make it a link. However if it simply activates something on the page, make it a button. With CSS there should be no issues with using buttons where needed. Another advantage of using buttons is you automatically get button roles, spacebar activation etc for free.
Re keyboardability: going quickly through the 3MT Piwik analytics page, two places hit me the hardest: I can't keyboard through the menu (though I tab through invisible submenu items but can't tell what they are because the URLs are ginormous and weird), and I can't see the information in the jplot chart because the data only appears on mouse over.

I'm also going to read the dev guides posted by tassoman and maybe would like to start on the menu, since I hit it first and getting to the page itself it Thousand Tabs of Death. :P

@mattab commented on August 25th 2014 Member

We've published on social media a call that we are looking for an accessility expert contractor would could help us analyse the accessibility reports and implement changes. If you know anyone please get in touch!

The goal of this project is:

  • Read the two accessibility reports linked above
  • Establish list of sub-tasks
  • Order tasks by importance and ease of implementation
  • Get tasks done using Pull requests
  • Iterate until Piwik becomes much more accessible!
@tassoman commented on August 25th 2014 Contributor

Ciao Matt,
I've already informed our organization's officiers about this plan, personally I could manage sending pull requests and getting hands dirt in the code. Mr @jdeyla could help me with the first two tasks, would be easier for him because he's the main author of the latest document.

You see "Italy is closed in August" :palm_tree: so we need some days to plan resources and agree with our organization's goals.

@mattab commented on August 26th 2014 Member

@tassoman that's really great news! we shall wait for your follow up in September and we look forward to working with you :-)

@StommePoes commented on August 27th 2014

I am a member of 3 Mouse Tech as well, but I feel at this point that I can't speak on behalf of anyone but myself :)

One thing I don't want to do while juggling a full-time job and insane commuting is make some kind of commitment that would then stop someone else from participating. What I do want to do is, after I get through looking at the code I just cloned, see what's within my grasp. I couldn't rate many tasks without seeing how the code implements said thing, for example. But I assume once we have some kind of list going, there would be separate issues like what Twitter Bootstrap does now with individual accessibility issues? You know who's working on something or what the current problems are and how severe they're rated. I wouldn't want to spend time in an area that, for example, @tassoman has already decided to look at.

Anything more complex than "this field needs a label" however will need feedback from you (Piwik) guys, because there are usually multiple ways of making something accessible both with and without you losing/changing some functionality. I'm thinking the menu, it's driving me nuts as a keyboarder and I love coding menus...

@mattab commented on August 27th 2014 Member

Hi @StommePoes,

Thanks for the message, and glad to hear you also maybe able to help!

I assume once we have some kind of list going, there would be separate issues like what Twitter Bootstrap does now with individual accessibility issues?

Yes definitely, we will create new github issues with a new label eg c: Accessibility to keep track of all tasks.

Anything more complex than "this field needs a label" however will need feedback from you (Piwik) guys

Of course we will be here to help as much as possible and review changes: using Pull requests makes this process natural.

@StommePoes commented on August 27th 2014

Well is this the best place for things before the pull request? Or is there also an irc channel etc?

@mattab commented on August 27th 2014 Member

What I suggest is that we create several issues in github for each sub-task, and then we can discuss each task in its issue. Then developer can create pull request and write refs #xyz where xyz is the issue number.

Btw there is a IRC channel for Piwik but core developers don't hang in there.

@tassoman commented on August 27th 2014 Contributor

@StommePoes in the two analysis documents there are already plenty of small ui things to retouch. I think retouching could be grouped by "page" as seen in the main menu.

A deal could be not breaking tests, the best way I think starting just with test then following test driven development.

Using the Accessibility label we could set an issue, for example "a11y on login page" or chosing all the ordered/unordered lists and parse all entire the UI.

During this UI refactoring we must document things or update outputting APIs so that core developers and contributors working on new feature are awared of the right way to output html, or calling APIs outputting accessible html

@StommePoes commented on August 27th 2014

@tassoman yeah right now setting up nginx and composer to run all this, Piwik is even more complex than I thought : ) I like the group-by-page idea to start, though later it should become more specific (esp as we fix the low-fruit).

@tassoman commented on October 1st 2014 Contributor

Ciao all :smile:,
I'm now on other tasks until the end of year 2014 :snail:. Officers planned going on with Piwik's a11y in the beginning of year 2015. I hope to start asap pushing code.

In the mean time I ask all the developer's community if you agree we add some rule or best practice in the developer documentation for what concerns new forms and new UI creation, that must adhere with WGAG 2.0 ruleset, for rich UX improvements we should also follow WAI ARIA. Doing both we'll have an high chance to do things well.

I would mean, coding for a11y is also a behavior approach, not only a unit test pass, there are kinda of decisions must be taken by the human (developer) and must agree the two best practice noted by W3C. Fortunately the boring unit testing tasks are already covered by HTML_CodeSniffer software. There is also a web service based on it, called Pa11y that automate most of the accessibility tests.

@StommePoes commented on October 1st 2014

Sounds good, could be a reference for developers adding new things/widgets, and as a sort of checklist for those code-reviewing new things/widgets.

@mattab commented on January 14th 2015 Member

Hi guys,
FYI we are working on Accessibility at the moment. We've created some issues linked here (you can see just above this comment).

@tassoman commented on January 14th 2015 Contributor

Got it, thank you!

@mattab commented on January 15th 2015 Member

FYI we had a 1 hour session with Julius, a user who is blind, and showed us the experience of using Piwik with screen reader, and it really helped us understand the difficulties in using Piwik! Let's make Piwik accessible.

Photo of session at: https://www.flickr.com/photos/4nitsirk/16251955566

@jdeyla commented on January 15th 2015

Hi
I will face tickets in the next few days.
I’m very glad you had the chance to put your ears  in a blind guy screen reader,
it’s the only way to understand.

But think he’s just one user, with his expertise with technologies and web: just only one. 
Listen to him, but filter suggestions: you are the architect,

Jacopo Deyla

On Jan 15, 2015, at 5:49 AM, Matthieu Aubry notifications@github.com wrote:

FYI we had a 1 hour session with Julius, a user who is blind, and showed us the experience of using Piwik with screen reader, and it really helped us understand the difficulties in using Piwik! Let's make Piwik accessible.

Photo of session at: https://www.flickr.com/photos/4nitsirk/16251955566


Reply to this email directly or view it on GitHub
.

@mattab commented on February 6th 2015 Member

Hi everyone, we have made some progress on some of the most obvious and useful accessibility improvements. List of closed issues :
accessibility progress

(this was done with the help of high school students and Piwik team as part of the Catalyst academy)

we will release a beta in the next few days which will include those improvements. in the meantime you can test Piwik from Git and let us know here any feedback!

@jdeyla commented on February 6th 2015

Great job!

Jacopo Deyla

On Feb 6, 2015, at 11:29 AM, Matthieu Aubry notifications@github.com wrote:

Hi everyone, we have made some progress on some of the most obvious and useful accessibility improvements. List of closed issues : 

(this was done with the help of high school students and Piwik team as part of the Catalyst academy ) we will release a beta in the next few days which will include those improvements. in the meantime you can test Piwik from Git and let us know here any feedback! — Reply to this email directly or view it on GitHub .
@jdeyla commented on February 26th 2015

Hi @mattab I'd like to check #a11y issues on the latest beta release. Is there a public url and a demo user I can use in order to verify what's benn done? thx

@mattab commented on February 26th 2015 Member

Hi @jdeyla sure - you can test the latest version of Piwik on this demo: http://demo.piwik.org/

it would be great to hear from you and the results of your tests!

@jdeyla commented on February 27th 2015

I thought it was the last stable,
not the last beta. 
Good and thank you!

@mattab commented on April 7th 2015 Member

Hi guys,

What do you think should be our next improvement regarding Accessibility?

Basically I'm asking anyone that need Piwik to be accessible to comment here with the most important next thing to fix. I'm sure there are plenty of annoyances of the product and it would be great to focus on the urgent ones :+1:

@tassoman commented on April 7th 2015 Contributor

Ciao @mattab , I'm aware of the work you're doing in the lateral navigation menu refactoring. Maybe another important step could be the calendar accessibility improvement and the select combo box used for switching websites.

Nowadays we're going to get rid of PHP 5.3 in our testing server so we can switch to a current Piwik installation. After this we could start pushing some code on a11y tasks. But this couldn't happen before issue's 7181 solution

@tassoman commented on November 4th 2015 Contributor

I'm reporting a strange behavior of the new sidebar menu: when you click a onepaged level1 (es: Dashboard, Goals) you get a page load. When you click a multipage level1 (es: Visitors, Actions) you only toggle its second level menu.

So now I'm unsure if the multipaged level1 links should have a "Actions widget" page, or if the onepaged level1 link "Goals" should toggle its menu only.

My choice would be the first case, so we should have routing for multipaged menus, routed to its first level2. For example I should land on "Overview" 2level page just by clicking "Actions"

@mattab commented on November 5th 2015 Member

For example I should land on "Overview" 2level page just by clicking "Actions"

We changed this back on purpose, see discussion in https://github.com/piwik/piwik/issues/9007

@mattab commented on January 16th 2017 Member

It would be awesome to continue our work on Accessibility. If you want to help please take a look at all issues tagged with Accessibility here: https://github.com/piwik/piwik/labels/c%3A%20Accessibility

This Issue was closed on January 16th 2017
Powered by GitHub Issue Mirror