-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accessibility improvements to Piwik #4167
Comments
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! 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 |
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. 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:
|
Ciao Matt, 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!
Yes definitely, we will create new github issues with a new label eg
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 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 😄, 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, |
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 But think he’s just one user, with his expertise with technologies and web: just only one. Jacopo Deyla
|
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
|
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, |
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" |
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 |
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
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!
The text was updated successfully, but these errors were encountered: