We want CloudEngine and Cloudworks to be as accessible as possible to people with disabilities. Earlier this year, we had some help from Chetz Colwell, an accessibility expert here in the Institute of Educational Technology at The Open University in reviewing the software from an accessibility perspective.
On the whole I would say that we are more clued up about accessibility than average, and apart from a few ‘bugs’ that slipped through the net, we avoided the most common accessibility pitfalls that you come across. Nonetheless, we still learned some new things, proving how useful it is to have your software reviewed in this manner, and I thought it might be useful to share them. We are still working on fixing some of these (and now that the code is open-source, you are very welcome to help!) and have time marked out in next year’s roadmap for accessibility improvements.
Ten things that we learned from the accessibility review
1) Check any third-party code carefully for accessibility issues
One important lesson that we learned from the review is that we need to become meticulous about checking the accessibility of any third party code that we decide to use. The chief culprits here were the text editor and date picker, but this also extends more broadly to any front-end code written by other people.
This is tricky though because sometimes choice is very limited particularly when you also have non-accessibility requirements that you want to fulfill. It is also often difficult to get good information without doing the testing yourself. However, it is still something that we need to be much more alert to and if we do find ourselves in the position of having to use code that is less accessible code than ideal, we need to at the minimum e.g. let users switch off the text editor, or give them sufficient information to add dates without using a date picker.
2) Test with high contrast settings
We had used a Colour Contrast analyser to test our pages, but we didn’t realise that we should also test with high contrast display settings. Lots of parts of the pages such as the borders of tabs and buttons became invisible or nearly invisible with these settings on.
3) Make sure you logically order the elements of pages in HTML
- The Cloud page is organised into two visual columns. The first column of the page contains the title and contents of the Cloud. The name of the person who created the cloud is in the second column, so this comes after the entire contents of the cloud which might be quite long. It would make more sense for the name of the creator of the cloud to come after the title of the cloud.
- In the comments on clouds, we put the name of the person who put the comment after the comment, whereas it would be more helpful to somebody using a screenreader if it came before.
- On some of our form fields, as well as a field label we had some extra help text e.g. giving examples of the type of content people might want to include in the field. It is more useful if this comes before the form field rather than afterwards where we had put it.
4) Use the <hr /> tag for horizontal lines that divide up sections
I had learned to shy away from using the <hr /> tag for horizontal lines because I associate it so much with being used when CSS should be used instead. But the <hr /> tag when used semantically actually makes it easier for screenreader users to know when one section ends and another starts.
4) For HTML page titles, put the title of the page first and name of the site second
It’s easier for screenreader users if the title of a page in the HTML is e.g. ‘Create Cloud – Cloudworks’ rather than ‘Cloudworks – Create Cloud’. This way screenreader users hear the name of the actual page upfront. Although I have to say that even the BBC Website does it the other way round!
5) Make it as easy as possible for people to make user generated content accessible
User generated content always poses interesting accessibility challenges. However, we could have done much more to make it as easy as possible for people to make their content accessible. This is partly in terms of raising awareness of accessibility and providing information for people on how to make their content accessible, but there is also functionality that we could provide. For example
- When people add embeds, we should give them option of providing an accessible alternative
- When people add URLs, we should insist they also add a title
- When people add images, we should make it easy for them to add alt text.
- We need to make sure that the text editor makes it as easy as possible for people to make their content accessible
6) When using tabs, make sure the keyboard focus remains on the tab when clicked.
Tabs, such as the alphabetical tabs on the Clouds and Cloudscapes pages or the tabs for different items types on the Cloudstream pages, are difficult for screenreader users, but it is still easier if the focus remains on the tab rather than goes back to the top of the page.
7) Avoid captchas altogether on registration forms
We knew that captchas were an issue and we have always offered to register people manually. However, instead of just doing this or looking into e.g. audio captchas, we really ought to at least try turning them off altogether and trying other anti-spam measures. We haven’t tried removing the captchas on our registration form yet, but have added functionality to easily turn captchas on and off, so we might try it at some point to see to what extent captchas do actually reduce spam. Most of the spam we get is currently human-generated rather than robot-generated, but that may be because we have captchas!
8) Make sure there is not too much whitespace between a form label and form field
This makes the form difficult to navigate for users of screen magnifiers. This can easily happen if you have your form as two visual columns with the form labels in the first column and form fields in the second column (as is the case on our current registration form). It is generally better to put the form label above the field rather than to the left of it for this reason.
9) Put form validation messages above the page heading
If there is a form validation error message, it is much easier for screen reader users if the message is above the main page heading, rather than just above the form where you might more obviously put it.
10) Be careful not to use whitespace as ‘punctation’
It can be very tempting to use whitespace to mark gaps and to forget that a screen reader will not realise this. For example, in one place we had lists of clouds with the cloud title of each cloud followed by some whitespace and then the number of comments, making it difficult to distinguish between the title and number of comments. Putting a dash, full stop or comma, instead makes it easier for screenreader users.