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

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.

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!

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

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.

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.

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.

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

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!

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" 🌴 so we need some days to plan resources and agree with our organization's goals.

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

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...

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.

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

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.

@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

@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).

Ciao all 😄,
I'm now on other tasks until the end of year 2014 🐌. 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.

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.

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).

Got it, thank you!

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

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
.

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!

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
.

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

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!

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

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 👍

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

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"

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

We changed this back on purpose, see discussion in #9007

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