Hello devs
I recently started to seriously work on accessibility improvements of the Roundcube UI which has been a long standing issue. As a start, I read through the W3C WCAG 2.0 and WAI-ARIA recommendations. From there, I picked the points that seemed relevant and important for Roundcube. I'm trying to collect all references in our wiki, from which I then want to define some guidelines and best practices for Roundcube developers. See the work-in-progress wiki page here: http://trac.roundcube.net/wiki/Dev_AccessibilityGuidelines
I found it particularly hard to apply the recommendations from WCAG to Roundcube because it's more an application than a website providing contents. But I assume that's where ARIA is meant to jump in. And here's my first question: are there tools available that actually implement these standards and actually make sense of all these aria-* attributes?
In a first attempt I started to make keyboard navigation work in the main email view. While not completely finished yet, you should at least be able to tab through all the button elements, operate the message list and the popup menus. Once the message list gains focus (that's not very visible yet but you can see a gray vertical bar on the left of the first row), the arrow keys move the cursor while <space> selects the row and <enter> opens the message. A descriptive block explaining the list navigation shall be added to the page. If that'll be sufficient for screen readers, I'm not very sure about but maybe you guys can give me some guidance here. Or should we finally add checkboxes to be on the safe side?
The plan is to finish the mail view first with all the necessary changes and then apply them to other parts of the application once the recommendations are complete.
The current state of development takes place in a separate branch of our github repository (dev-accessibility) and a copy is available for testing at: http://demo.roundcube.net/accessibility/ (user credentials are listed on demo.roundcube.net).
A major hurdle for me is also the lack of the right tools to verify whether the improvements I added really make sense and will work with the assistive tools out there. I'm currently using the Accessibility Evaluation Toolbar for Firefox but feedback seems rather limited.
I'd much appreciate feedback and review from the experts out there on both, the wiki page and the ongoing development as well as general suggestions or lessons one already learned regarding this topic. This is all pretty new to me but hopefully you can share your expertise and experience with us. So feel free to respond here or to extend the wiki page with recommendations and best practices.
Many thanks!
Thomas
On 14-05-07 11:24 AM, Thomas Bruederli wrote:
I found it particularly hard to apply the recommendations from WCAG to Roundcube because it's more an application than a website providing contents. But I assume that's where ARIA is meant to jump in. And here's my first question: are there tools available that actually implement these standards and actually make sense of all these aria-* attributes?
does it make much sense to even do this for roundcube? i assume that the guidelines mostly relate to websites because they are information repositories and it's important for the information on them to be accessible. but as you say, roundcube is more an application than a repository (IMAP being the true repository) - it seems like anyone with sight problems would be using an imap client designed specifically for that purpose and not trying to use a webmail client at all.
On Wednesday 7. May 2014 20.41.55 Brendan wrote:
On 14-05-07 11:24 AM, Thomas Bruederli wrote:
I found it particularly hard to apply the recommendations from WCAG to Roundcube because it's more an application than a website providing contents. But I assume that's where ARIA is meant to jump in. And here's my first question: are there tools available that actually implement these standards and actually make sense of all these aria-* attributes?
does it make much sense to even do this for roundcube?
Yes.
i assume that the guidelines mostly relate to websites because they are information repositories and it's important for the information on them to be accessible. but as you say, roundcube is more an application than a repository (IMAP being the true repository) - it seems like anyone with sight problems would be using an imap client designed specifically for that purpose and not trying to use a webmail client at all.
I'll let people with stronger opinions about accessibility speak for themselves, but one thing I was told by someone with a far greater depth of knowledge and experience on this topic than me was that people with greater accessibility demands than those of the average user do actually want to use the same applications as everybody else, or at least many of them do.
Another concern is that accessibility is used as an argument against Roundcube in cases of procurement, especially in public organisations. I briefly investigated this last year and found various things that might be improved, but at the same time it did seem like the various JavaScript libraries used by Roundcube do support various ARIA annotations. (I can dig out my list of findings, though.) I recently learned that various supposed accessibility deficiencies in Roundcube were eventually no longer a concern for one organisation whose procurement practices I had been tracking, but it appears that the uncertainty was sufficient to use as an excuse to migrate webmail (and indeed the entire e-mail infrastructure) to something else.
Having a strong accessibility reputation would be beneficial for Roundcube not just because it would ensure the solution's usability for the maximum number of potential end-users, but also because it would undermine the kind of whisper campaign that somehow manages to get it disqualified in favour of all- in-one proprietary systems in organisations like the one mentioned above. Such disqualifications and exclusions undermine both Roundcube adoption - not nice if you prefer Roundcube to other webmail solutions - as well as Free Software and open standards adoption, ultimately threatening the viability of those things and of Roundcube itself.
Sorry for the lengthy and slightly tangential response, but I strongly feel that sometimes the best way to counter the kind of misinformation that is spread when there is money to be made by aggressive proprietary software vendors - at the expense of great software like Roundcube (and often at the expense of users and taxpayers) - is to be able to demonstrate a robust and complete solution that can be shown to fully address all areas of potential concern. Accessibility is one of those areas.
Paul
On 14-05-07 04:51 PM, Paul Boddie wrote:
I'll let people with stronger opinions about accessibility speak for themselves, but one thing I was told by someone with a far greater depth of knowledge and experience on this topic than me was that people with greater accessibility demands than those of the average user do actually want to use the same applications as everybody else, or at least many of them do.
that's quite interesting. i assumed that the number of people wanting to use the same applications would be small, as it would seem that something designed for the sighted would be difficult to navigate with a screen reader - i find using a browser with only a keyboard to be a frustrating experience, i can only imagine it could be moreso with a screen reader.
now that i write that, it occurs to me i was being a bit too black and white - there are a lot of levels between sighted and non-sighted; i was only thinking about one case (fully non-sighted). and overlooking the desire of people to fit in, which i don't have any personal experience in here.
Another concern is that accessibility is used as an argument against Roundcube in cases of procurement, especially in public organisations. I briefly investigated this last year and found various things that might be improved, but at the same time it did seem like the various JavaScript libraries used by Roundcube do support various ARIA annotations. (I can dig out my list of findings, though.) I recently learned that various supposed accessibility deficiencies in Roundcube were eventually no longer a concern for one organisation whose procurement practices I had been tracking, but it appears that the uncertainty was sufficient to use as an excuse to migrate webmail (and indeed the entire e-mail infrastructure) to something else.
Having a strong accessibility reputation would be beneficial for Roundcube not just because it would ensure the solution's usability for the maximum number of potential end-users, but also because it would undermine the kind of whisper campaign that somehow manages to get it disqualified in favour of all- in-one proprietary systems in organisations like the one mentioned above. Such disqualifications and exclusions undermine both Roundcube adoption - not nice if you prefer Roundcube to other webmail solutions - as well as Free Software and open standards adoption, ultimately threatening the viability of those things and of Roundcube itself.
Sorry for the lengthy and slightly tangential response, but I strongly feel that sometimes the best way to counter the kind of misinformation that is spread when there is money to be made by aggressive proprietary software vendors - at the expense of great software like Roundcube (and often at the expense of users and taxpayers) - is to be able to demonstrate a robust and complete solution that can be shown to fully address all areas of potential concern. Accessibility is one of those areas.
not at all. you present an interesting and compelling case. this cleared up things for me, and hopefully for others as well.
i suppose even if there are better tools for an individual, an organization might still want to provide a tool that could be used (albeit perhaps less efficiently) by all just simply because it would make things easier to support.
European law also defines some web accessibility standards, which all government procurements have to abide by.
It certainly wouldnt hurt to make roundcube more accessible, andif a lot of work is being done to investigate and solve accessibility, please document this work and write a plugin guide so plugin authors can follow.
Cor
On Thu, May 8, 2014 at 8:49 AM, Cor Bosman cor@xs4all.nl wrote:
European law also defines some web accessibility standards, which all government procurements have to abide by.
It certainly wouldnt hurt to make roundcube more accessible, andif a lot of work is being done to investigate and solve accessibility, please document this work and write a plugin guide so plugin authors can follow.
That's the intention of the wiki page: http://trac.roundcube.net/wiki/Dev_AccessibilityGuidelines
~Thomas
That's the intention of the wiki page: http://trac.roundcube.net/wiki/Dev_AccessibilityGuidelines
Cool.
I emailed Thomas about this but im working on a full rewrite of the keyboard shortcuts plugin. This new version will allow for user-configurable keys and for other plugins to register key-selectable events as well. (as an example, use a key to report a mail as spam). This seems to augment the work Thomas is doing with keyboard navigation, but time will tell. Once I understand what I need to be doing im fine with making that plugin follow accessibility rules as well.
Maybe some of the core plugins could become showcases for how to implement accessibility in plugins.
Cor
On Thursday 8. May 2014 08.57.40 Thomas Bruederli wrote:
On Thu, May 8, 2014 at 8:49 AM, Cor Bosman cor@xs4all.nl wrote:
European law also defines some web accessibility standards, which all government procurements have to abide by.
It certainly wouldnt hurt to make roundcube more accessible, andif a lot of work is being done to investigate and solve accessibility, please document this work and write a plugin guide so plugin authors can follow.
That's the intention of the wiki page: http://trac.roundcube.net/wiki/Dev_AccessibilityGuidelines
For reference, my previous message on the topic can be found here:
http://lists.roundcube.net/pipermail/dev/2013-June/022640.html
I did try out various Roundcube features (mostly concerning the Kolab calendar plugin, however) in conjunction with the Fangs "screen reader emulator" [1]. Various other tools were recommended to me and these are already mentioned on the wiki page (Orca, NVDA), but I don't run a system that can use them effectively (or at all, given the Windows-only nature of NVDA).
From what I found, JavaScript Web applications should still be accessible, contrary to the established beliefs in the wider Web development community. Screen readers can be aware of the DOM and are able to notice changes in it. Even Fangs, which is supposedly very simple, is able to obtain a lot of information straight from the DOM. Whether screen readers need to be actually aware of JavaScript itself is debatable, but there's useful advice on such matters out there:
http://a11yproject.com/posts/myth-screen-readers-dont-use-javascript/
(Unfortunate that the charts are broken on that page, though!)
Fangs doesn't seem to be aware of ARIA annotations and isn't able to notice the significance of the controls in Roundcube, or at least this was the case last year. However, the jQuery output produced by Roundcube does seem to be usable by screen readers in principle. I did aim to evaluate other accessibility tools, but I ran out of time.
One weird and rather specific thing I encountered was the use of "CSS sprites", at least in the calendar plugin. Some people are skeptical about this technique [2], and I think its use might need reconsidering for properly accessible functionality. On other issues of recommended practices, it looks like the wiki page summarises the pertinent WCAG guidelines quite well. I know that I went and changed some of my own Web applications after reading some of those.
Paul
[1] https://addons.mozilla.org/en-US/firefox/addon/fangs-screen-reader- emulator/ [2] http://coding.smashingmagazine.com/2010/03/26/css-sprites-useful- technique-or-potential-nuisance/
On Thu, May 8, 2014 at 10:39 PM, Paul Boddie paul@boddie.org.uk wrote:
On Thursday 8. May 2014 08.57.40 Thomas Bruederli wrote:
On Thu, May 8, 2014 at 8:49 AM, Cor Bosman cor@xs4all.nl wrote:
European law also defines some web accessibility standards, which all government procurements have to abide by.
It certainly wouldnt hurt to make roundcube more accessible, andif a lot of work is being done to investigate and solve accessibility, please document this work and write a plugin guide so plugin authors can follow.
That's the intention of the wiki page: http://trac.roundcube.net/wiki/Dev_AccessibilityGuidelines
For reference, my previous message on the topic can be found here:
http://lists.roundcube.net/pipermail/dev/2013-June/022640.html
Hi Paul
Many thanks for the elaboration of the reasons why even Roundcube should be improved for users with special accessibility needs. In fact it's a request from a big public administration project that brought up this topic again and that made me finally start doing something about it.
The things you listed in the above mentioned post are all valid and are subject to be addressed now. And once we collected our guidelines and proved that the suggested improvements work on the email part of Roundcube, plugins like the Kolab calendar module will follow.
I did try out various Roundcube features (mostly concerning the Kolab calendar plugin, however) in conjunction with the Fangs "screen reader emulator" [1]. Various other tools were recommended to me and these are already mentioned on the wiki page (Orca, NVDA), but I don't run a system that can use them effectively (or at all, given the Windows-only nature of NVDA).
From what I found, JavaScript Web applications should still be accessible, contrary to the established beliefs in the wider Web development community. Screen readers can be aware of the DOM and are able to notice changes in it. Even Fangs, which is supposedly very simple, is able to obtain a lot of information straight from the DOM. Whether screen readers need to be actually aware of JavaScript itself is debatable, but there's useful advice on such matters out there:
http://a11yproject.com/posts/myth-screen-readers-dont-use-javascript/
That's what I was hoping, too.
Fangs doesn't seem to be aware of ARIA annotations and isn't able to notice the significance of the controls in Roundcube, or at least this was the case last year. However, the jQuery output produced by Roundcube does seem to be usable by screen readers in principle. I did aim to evaluate other accessibility tools, but I ran out of time.
Fangs seems like a nice development tool but I'm still uncertain if it actually represents what blind users perceive from real screen readers.
One weird and rather specific thing I encountered was the use of "CSS sprites", at least in the calendar plugin. Some people are skeptical about this technique [2], and I think its use might need reconsidering for properly accessible functionality.
I think sprites are still a good way to implement graphical buttons and don't necessarily contradict accessibility guidelines as long as there's a textual representation of the UI element that is styled using sprites. There are certain elements in Roundcube's UI that need to be fixed regarding this.
On other issues of recommended practices, it looks like the wiki page summarises the pertinent WCAG guidelines quite well. I know that I went and changed some of my own Web applications after reading some of those.
Perfect, thanks!
Kind regards, Thomas
[1] https://addons.mozilla.org/en-US/firefox/addon/fangs-screen-reader- emulator/ [2] http://coding.smashingmagazine.com/2010/03/26/css-sprites-useful- technique-or-potential-nuisance/
Here's a link to an article from one of the guys at Mozilla regarding accessibility and WAI-ARIA. This was sent to me from one of my visually-impaired employees who was quite impressed with the article.
http://www.marcozehe.de/2014/05/03/wai-aria-for-screen-reader-users-an-overv...
On 5/7/2014 11:24 AM, Thomas Bruederli wrote:
Hello devs
I recently started to seriously work on accessibility improvements of the Roundcube UI which has been a long standing issue. As a start, I read through the W3C WCAG 2.0 and WAI-ARIA recommendations. From there, I picked the points that seemed relevant and important for Roundcube. I'm trying to collect all references in our wiki, from which I then want to define some guidelines and best practices for Roundcube developers. See the work-in-progress wiki page here: http://trac.roundcube.net/wiki/Dev_AccessibilityGuidelines
On Sat, May 10, 2014 at 8:21 PM, Robert Du Gaue rdugaue@calweb.com wrote:
Here's a link to an article from one of the guys at Mozilla regarding accessibility and WAI-ARIA. This was sent to me from one of my visually-impaired employees who was quite impressed with the article.
http://www.marcozehe.de/2014/05/03/wai-aria-for-screen-reader-users-an-overv...
Hi Robert,
Many thanks for sharing that with us! It seems that Marco’s accessibility blog is a perfect source for real-world facts and suggestions regarding accessibility. Something that goes beyond the specs and exactly the kind of information I was looking for. I just added it to our wiki page as a must-read for developers. Of course, I'll read it carefully and try to apply the suggestions to our accessibility improvements.
Kind regards, Thomas
On 05/07/2014 08:24 PM, Thomas Bruederli wrote:
I recently started to seriously work on accessibility improvements of the Roundcube UI which has been a long standing issue.
The work is now finished and merged into master branch. While Thomas is on vacation anyone interested please test this.
There's a ticket I opened for pending issues I've found. Feel free to add your bugs to the list or create new tickets.
http://trac.roundcube.net/ticket/1489929
-
A.L.E.C -
Brendan -
Cor Bosman -
Paul Boddie -
Robert Du Gaue -
Thomas Bruederli