Clone wiki

cloudengine / Accessibility_Report

This report is based on Cloudworks (June 2010), but mostly applies to CloudEngine too. Some of these issues have been fixed, though this isn't indicated yet. Formatting and images are missing!

Cloudworks accessibility report

Dr Chetz Colwell, June 2010.


Cloudworks has been tested using a range of different assistive technologies and computer settings.

In brief,

  • People who use a screenreader may have some difficulty navigating the content, and operating various features.
  • People who do not use a mouse may have some difficulties with some aspects.
  • People with visual impairments or dyslexia may find some text difficult to read due to low contrast with the background.
  • People who require large font size browser settings should find all content resizes appropriately.
  • People who require Windows high contrast settings will find some elements are invisible or indistinct.
  • People who use a screen magnifier will be able to access most content, but may have difficulty navigating the registration form due to the alignment of fields and labels.
  • People with severe hearing impairment will not be able to access the audio on site-related videos.
  • People who use voice recognition will have difficulty accessing some features.


An Introduction

Tested with IE7 (including largest font setting), under Windows XP, and with Jaws 11, ZoomText 10 (screen magnifier), and Windows High Contrast display setting (large font, white and yellow on black), Dragon 10 (voice recognition), and Colour Contrast Analyser tool version 2.2 (

The issues and associated recommendations are presented below.

The recommendations have been prioritized: issues which present an actual barrier to a specific group of people are High priority; issues which present some difficulties to a specific group are Medium priority.

Positive aspects for accessibility

Several positive accessibility points were noted during this testing.

  • Registration form contains appropriate markup
  • Headings are provided throughout, and are mostly nested appropriately
  • Table headers are provided where appropriate
  • Tables are not use for layout purposes
  • Links to the current page, and the current tab, are not active
  • Link text is meaningful (no ‘click here’, ‘more…’ or ‘>>’)
  • All content responds appropriately when browser is set to largest font

Accessibility information

Currently there is no statement about the accessibility of the site.

Recommendation: Provide an accessibility statement which includes an overview of what work has been done on accessibility, and details of any outstanding/known issues. This should include reference to the accessibility of user-generated content, embedded videos, and the editor. Medium priority.

User-generated content

The issue of accessibility of user-generated content is one that is being discussed in a wider context. The main questions are: where the responsibility lies for making content accessible; and how best to support users in making their content as accessible as possible. Various people have written about this issue, for example see, Sloan & Kelly (2008) summarised the position as follows,

“Even in today's Web 2.0 of 'user-generated content', the challenge remains of how best to address the accessibility of large quantities of content created by people without the knowledge or tools to ensure this content is created with accessibility in mind. What must be emphasised is that…holistic accessibility does not mean forgetting about those excluded because of the inherent accessibility barriers present, but that information with accessibility problems can be published so long as these barriers be identified, and appropriate steps taken to support people who may be affected.”

Recommendation: Users (content authors) should be provided with simple guidance on making their content as accessible as possible. This guidance cannot necessarily be enforced but offering it should encourage users to consider accessibility. I can assist with this if required. Medium priority.

The types of user-generated content that may have accessibility issues are: text (in comments, main content, and extra content), embedded video, embedded image, and header/logo image for Cloudscapes.


The text editor does not enable users to created headings, but supports bold and italics. Headings are useful to screenreader users in determining the structure of content. Users may not need to create headings in comments, but this may be useful in content. The lack of ability to create headings may lead to users creating headings using bold or italics which would not be useful for screenreader users. Recommendation: Enable the editor to offer headings, particularly when editing content. High priority.


Video accessibility is a complex area and the techniques needed for making them accessible depend on the nature of the video and are different for visually and hearing impaired people. [1] Currently in Cloudworks when embedding videos there is no field to enable authors to link to transcripts or descriptions of videos which may already exist, or they may wish to create them. Recommendation: Provide a field to enable authors to link to transcripts and/or descriptions. High priority.

[1] Techniques include captions (subtitles) or transcripts for hearing impaired people, and audio description (description of visuals) for visually impaired people. When a video is just a ‘talking head’ then a transcript can offer access to hearing impaired people as it is not important to synchronise the transcript of the audio with the visuals. However, when the audio refers to specific visuals, captions are needed to ensure the text is synchronised with the visuals. Similarly, with a talking head video it would be sufficient for visually impaired people to listen to the audio (assuming they can access the video player). However, when particular visual points are not conveyed by the audio track then a description is needed. Audio description is a technique for incorporating description of the visuals into natural gaps in the audio track. This can be an expensive process therefore a cheaper (but not as effective) alternative is to provide an overall description of the video.


Depending on the nature of an image and its role in the content, it may require a brief description, a longer description, or no description at all. (For more information on this see ‘Guidelines for describing visual teaching material’: Usually the author is the best judge of the role of an image and they should be supported in making this decision.

Currently on Cloudworks when images are embedded, e.g. from Flickr, alternative text is automatically created: “filename, Flickr username, on Flickr”, and the image is a link to the original on Flickr. The filename may or may not be meaningful, e.g. “img_1234.jpg” or “workshop_participants.jpg”.

When embedding images there is no field for authors to provide a description of the image. There is a field for a title (which renders as a heading) but this is currently optional. It is important to provide information for screenreader users but without repeating information more than necessary. It may be that the title field would mostly provide adequate description.

Recommendations High priority:

  • Consider making the title field required rather than optional.
  • Offer guidance on providing descriptions for visually impaired users.
  • Offer an optional field for link to a longer description.
  • Consider removing the filename from the alternative text.
  • Consider removing the username from the alternative text but continue to include the phrase “on Flickr” to indicate the destination of the link.

Keyboard access [2]

[2] Note on keyboard access: The usual method for keyboard access is to use the tab key and shift+tab to move forwards and backwards respectively through the links, and use either the enter key to operate links, or this or the space bar to operate buttons and form fields. An additional method is to use the Windows Mousekeys utility which allows the number pad keys to be used to move the mouse cursor and simulate mouse clicks. However this is a laborious process and while it would be feasible to use this for simulating the occasional mouse click it would not be feasible to use it for full interaction with a web site.

On the ‘featured cloudscapes’ on the Home page, when a keyboard user operates a link on the right hand side the keyboard focus is returned to the top of the page. This means the user has to tab through the page again to where they were. Recommendation: if possible enable the focus to remain within the ‘featured cloudscapes’ area; perhaps on the item that has just appeared. Medium priority.

On clouds which have an embedded link, the tab order goes from the embedded link to the username and then to ‘add extra content’ (see * Screenshot below). Recommendation: it may be preferable for the username link to be before the Follow button or after the Edit button. Medium priority.

  • Screenshot 1: tab order of username.

It is not possible to tab to the dates within the pop-up calendar (although it is possible to tab to the next/previous buttons). It is possible to insert the date manually instead. However, there is no guidance on the required format of this. Recommendation: provide an example of the date format required. Medium priority.

If the pop-up calendar button is operated with the keyboard the focus returns to the top of the page, which means it is necessary to tab through the page again. In continuing to tab through the page the Next/Previous buttons are after the ‘how to set up a cloud or cloudscape’ link in the tab order, and not after the Deadline field (see * Screenshot below). Recommendation: Ensure the focus remains on the calendar after the button is operated. Medium priority.

  • Screenshot 2: pop-up calendar.

When the editor is present there is an empty tab stop between the previous link and the ‘B’ button. Recommendation: remove this empty tab stop. Medium priority.

When the keyboard focus is on the Follow or Edit buttons the visual indication of the focus is not very distinct. This is partly because the dotted line surrounds the text rather than the button area. Recommendation: ensure that visual indication of focus is clearly visible on buttons. Medium priority.

On the Favourites feature there are separate tab stops on the star and on the text link. This creates an extra step for keyboard and screenreader users. Recommendation: combine the star and text link into one link with an empty alt text. Medium priority. e.g.

<a href="products.html">
<img src="icon.gif" alt="" />
 Products page

Screen magnifier access

The large gap between the form labels and the fields could make it difficult for screen magnifier users to associate one with the other (see * Screenshot below). This may be caused by the fact that a table is used to lay out the elements. Recommendation: investigate ways of reducing the gap. If this is not possible, consider using a ‘striped’ background to the table rows.

  • Screenshot 3: white space between form labels and fields.

Screenreader access

On the Cloudstream on the Home page the icons do not have text labels. This means a screenreader user would not be able to distinguish the different types of item in the list. (Icons in other contexts don’t require labels because the preceding heading indicates the type of item.) Recommendation: Provide text labels for these icons. It may be useful to look at the approach used for icons in the VLE study planner in which the icon is combined with the link and a class is used to hide the text label. High priority.

There is no ‘skip to content’ link provided. This means that screenreader users who read from the top of the page will hear all of the navigation links each time. This also affects keyboard-only users. Recommendation: provide a ‘skip to content’ link at the very top of the page. Ideally it should be invisible until it is tabbed to and then should become visible (the approach used on most OU web sites). Medium priority.

The issues described above regarding the pop-up calendar also affect screenreader users. Although the screenreader will read out the date numbers they are not read immediately after the date field. The same recommendations apply for screenreader users.

When a link is added to a Cloud’s content the url is displayed on the page. This can be tedious for screenreaders to hear, and doesn’t necessarily convey what the web site is. On the ‘add a link’ page there is a field for a title but this is optional. Recommendations:

  • For Cloud content provide a required field for text for the link, as well as for the url. High priority.
  • On ‘add a link’ make the title field required. High priority.


The Home page heading structure is as below. This implies that ‘preferred language’ is a child heading to ‘Cloudstream’, which I assume it is not. The same applies to other pages.

<H1>Cloudworks home page</H1>
<H2>Featured Cloudscapes</H2>
<H3>Preferred language:</H3>
<H2>Active Clouds</H2>
<H2>Cloudworks Blog</H2>

Recommendation: remove the heading markup from ‘preferred language’. It can then be styled as required. Alternatively, if it requires a heading, change it to H2. Medium priority.

On Cloud pages the Follow and Edit are within the heading (H1). This appears to confuse the screenreader as to where the heading ends, and reads it all as one chunk. Recommendation: place buttons outside of the heading markup. Medium priority.

Registration form

When an error occurs on the registration form, the error messages are usefully placed toward the top of the page, but they would be more useful for screenreader users if placed above the ‘join Cloudworks’ heading. In addition, there is no explicit indication for screenreader users that an error has occurred (see * Screenshot below). Recommendations: provide the phrase ‘error: the following information is required’ (or similar) prior to the error message(s) (High priority), and place all of this information above the heading (Medium priority).

  • Screenshot 4: error messages on registration form.

The form includes a visual captcha device. By definition such devices are not accessible to screenreaders. Although email registration is offered to those that cannot access the captcha tool, this is not ideal as it introduces a delay of unknown length in registration, and it may not be scalable. The difficulty of making captchas accessible is a known issue, as discussed at Recommendations High priority:

  • Consider whether a captcha is necessary, or whether other methods could be used instead (for suggestions see
  • If the captcha is required, consider alternative approaches. Given the intended users of the site a logic question could be suitable. (Audio captchas are not a feasible alternative as it can be difficult to make them out and they are not accessible to deaf-blind people). For an example of a text captcha see
  • If the captcha is retained as is, inform users of the approximate response time for email registration.

Profile form

The list of example interests is read after the Interests field (see * Screenshot below). This means a screenreader user may fill in the field before they read the examples. Recommendation: place the examples within the label above the field. Medium priority.

  • Screenshot 5: ‘Interests’ field.

Email preference form

The radio buttons on this form have appropriate labels but they are not explicitly associated with the questions. Recommendation: provide ‘fieldset’ and ‘legend’ tags on each question to associate the radio buttons. This will place a box around the legend and radio buttons which may have to be styled as needed. High priority.

Featured cloudscapes

On the ‘featured cloudscapes’ colour is used as the only method of associating the feature box with the text link and the screenreader does not read the information about the featured cloudscape until the end of the list of cloudscapes (see * Screenshot below). When a text link is selected the screenreader starts to read from the next link, rather than reading the content that has appeared. It can be difficult to make this type of changing content fully accessible. Recommendation: investigate ways of bringing the screenreader focus to the newly-appeared content. High priority.

  • Screenshot 6: featured cloudscapes area.

The screenreader user hears the phrase “view cloudscape” three times in this area: once from the alt text; twice from the two text links. It is accepted that it needs to be in the alt text, and in one text link. Recommendation: if possible, remove one of the ‘view cloudscape’ text links. Medium priority.


Tabs are difficult for screenreader users because there is nothing to suggest that different content will appear after selecting the link. The tabs on list of clouds and lists of cloudscapes could be particularly confusing for screenreaders because the focus does not remain on the tab when the link is selected. Recommendation: if possible enable the focus to remain on the tab or a link within the tab area. Medium priority.

‘About’ page

The video on About does not have any kind of description, although this may not be needed if the audio sufficiently describes the visual aspects. Recommendation: consider whether the audio track would be sufficient for understanding the video, and if not, provide an additional description. High priority.

Page titles

Page titles all begin with the word ‘Cloudworks’ which is then followed by the name of the actual page, e.g. “Cloudworks: Clouds”, “Cloudworks: Current and upcoming events”, etc. It is preferable for screenreader users to hear the name of the actual page ‘up front’, especially on pages other than the home page. Recommendation: ‘front load’ all page titles, e.g. “Clouds: Cloudworks”, apart from the Home page. Medium priority.

The Registration page does not have a full title: the title is “Cloudworks – “. Meaningful titles are important for screenreader users. Recommendation: include the word ‘Registration’ or ‘Join’ in the title. Medium priority.


In Discussions it could be difficult to tell whether a person’s name is related to the comment below or above, particularly for screenreader users, as there is nothing to separate a name from the following comment. The convention in some other communication/collaboration tools is to place the sender’s name prior to their message, which sometimes enables the name to be a heading for the message. Recommendation: Consider methods of separating comments. One approach would be to place the sender’s name prior to their message and mark the name up as a heading, but this change could have an impact on existing users. An alternative would be to provide an invisible heading at the beginning of the message, perhaps a number, or just the word ‘comment’. There may be other possible approaches. High priority.

In the results of searching for a person, the images have alt text containing the person’s name. This is repeated in the link to the person’s page. Elsewhere people’s images do not have alt text, which is appropriate. Recommendation: remove the alt text from these images. Medium priority.

Horizontal lines

In some cases horizontal lines are just divs and these are not announced by a screenreader. This means that it could be difficult to distinguish between sections. In some cases it could be particularly difficult to tell the difference between ‘user interface’ text and user-created content. For example in the * Screenshot below it would be difficult for a screenreader to distinguish between “Got extra information or live blog notes about this cloud? Add them here!” above the line, and “Another approach to learning design is…” below the line. Recommendation: replace the divs with <hr>. This will be read by a screenreader as “dash dash dash separator” (or a user-specified phrase) which will convey the separation of the sections. High priority.

  • Screenshot 7: horizontal line.

Embedded video

Embedded You Tube videos are difficult for screenreader users as there are several unlabelled or ambiguous invisible elements. It is technically possible to find the Play/Pause button but the user would have to be determined. Recommendation: Provide information on this in the proposed accessibility statement. This could include an explanation that this is user generated content. It could also include some basic guidance for screenreader (which I could assist with if needed). High priority.


The editor is very difficult to use with a screenreader because it is difficult to get the focus into the editing area in order to type. This appears to be the same editor used in the VLE[*], but that does not have this issue. Also the editing area does not have an explicit label so the screenreader user may not be sure where they are typing. In addition the toolbar buttons which are greyed out are not announced as greyed out. These latter issues are known in the OU VLE. Partly because of this the VLE offers users the option to switch the editor off and use plain form fields instead. This instance of the editor has the ‘path’ feature switched off/hidden. However, there is an (invisible) accesskey link to the path which is announced by the screenreader. Finally the accesskeys are not considered to be particularly useful.


  • Investigate what differences there might be between implementation of the editor in Cloudworks and the VLE which might be preventing screenreader access. High priority.
  • Consider offering the option to switch off the editor in the profile. High priority.
  • Investigate whether the accesskey to the Path can be removed. Medium priority.
  • If possible provide a label for the editing field. High priority.

[*] Editor: Cloudworks/CloudEngine currently used TinyMCE as its rich-editor. The Open University virtual learning environment (VLE), powered by Moodle, also uses TinyMCE.

List of person’s clouds

In the list of a person’s clouds there is no punctuation between the name of the cloud and the number of comments on it (see * Screenshot below). This makes it difficult to distinguish these two types of information. Recommendation: place a full stop or comma between the name of the cloud and the number of comments. Medium priority.

  • Screenshot 8: list of clouds.

Colour issues

The dark blue on light blue of the navigation links, Home, clouds, Cloudscapes, Events etc has poor contrast. However, it passes the test because it is a larger font. It is noted here so that this colour scheme is not applied to smaller text in future developments.

The white on green of the Follow button has insufficient contrast. Recommendation: increase contrast by using a darker green, e.g. #00822B. High priority.

On the registration page the contrast on the captcha fails the CCA test. Clearly it’s important that the captcha is not readable by robots, but ideally it should be as readable as possible by humans. Recommendation: if possible make the text darker or the background lighter. Medium priority.

On some monitors the tabs on the ‘featured cloudscapes’ may not be sufficiently visible to convey the presence of the tabs. This may particularly affect visually impaired people. Recommendation: provide an outline to the tabs and box to make them more distinct. (This will also benefit users of high contrast window settings.) Medium priority.

Windows display settings (high contrast)

Under these settings the ‘featured cloudscapes’ tabs are not visible, which could make interaction with this area confusing (see * Screenshot below). Recommendation: as recommended above, provide a border on these tabs and ensure it is visible under these settings. Medium priority.

  • Screenshot 9: featured cloudscapes under high contrast settings.

The editor toolbar is invisible under these settings (see * Screenshot below). This is a known issue with this editor. Users with these settings can still type in the box, and can see the tooltips of the buttons. Recommendation: this issue should be explained in the proposed accessibility statement. Medium priority.

  • Screenshot 10: editor toolbar under high contrast settings.

Buttons are displayed as text links under these settings which doesn’t distinguish them from other links (see screenshots below). In addition the arrow next to the username is not visible and so the drop down menu will not be expected. Recommendation: provide an outline or other styling to distinguish these buttons from other links. Medium priority.

  • Screenshot 11: username and 'sign out' buttons.
  • Screenshot 12: 'follow' button.
  • Screenshot 13: 'post comment' button.

Browser settings – large font

No issues found.

Voice recognition access [3]

Links that appear as urls are difficult to dictate. The recommendation above to require link text will benefit voice recognition users too.

Dragon cannot operate the pop-up calendar, but users can dictate a date in the field instead. Again the recommendation above to provide the required format will benefit this group.

Embedded You Tube videos cannot be operated by Dragon as the player is not recognised as a link, or button, or graphic. Also the editor toolbar is not recognised by Dragon. Dragon users will need to use the ‘mousegrid’ function to operate videos and the editor. Recommendation: the accessibility information recommended above should include these as known issues. Medium priority.

[3] Note on voice recognition access (Dragon): On web sites Dragon commands can be used to click links, images, buttons, and operate form fields, by either saying the name of the item, or selecting from a list of all the items on the page. An additional method is to use the Dragon mousegrid function which places a numbered grid on the screen and the user can focus down on a specific item by saying the number which is nearest the item they want. This latter method is suitable for some mouse clicks but would not be feasible for full interaction.

Access for hearing impaired users

On the About page there is a video demonstrating Cloudworks which does not have captions (subtitles) or a transcript.

Recommendation: Ideally this video should have captions because it is not just a ‘talking head’ and it is therefore important to be able to synchronise a text alternative with the visuals. If this is not possible, then at least a transcript should be provided. High priority.


The site does not incorporate Browsealoud. This is a text-reading tool to support people with low-vision or dyslexia, and people for whom English is an additional language. It is available free on most Open University (OU) web sites (see the ‘listen to this page’ link in the OU top bar). Recommendation: enable Browsealoud on the site. Medium priority.

Typos/errors/technical/usability/other issues.

Although this testing has focused on accessibility, a number of usability and technical issues were spotted along the way, and are noted here in the hope they are useful.

Help and guidance are found in different places throughout the site and are not all linked from one place. For example, the page ‘How to set up a Cloud or Cloudscape’ is only linked from the ‘Create a cloud’ page (so you have to go as far as wanting to create a cloud before seeing this). On the Home page there is a link to ‘Using Cloudworks cloudscape’, and on the About page there is a link to ‘An introduction to Cloudworks’. Also the FAQ page is only linked from the Home page. I suggest all of these resources should be linked to from one location, perhaps on the About page.

On the registration form, on the ‘create my account’ button there is extraneous ‘label’ markup (see below). This won’t do any harm but it is not needed on this type of control.

<label> <input type="submit" name="register" value="Create my account" class="submit" /> </label>

Suggestion: remove the ‘label’ attribute.

Suggestion: to avoid registration errors occurring, inform users that all fields on the form are ‘required’. In this case the phrase “all fields are required” would be sufficient, rather than the use of asterisks.

The green horizontal line on the home page seems to be overlapping content (see * Screenshot below). This occurs on other pages too.

  • Screenshot 14: green horizontal line on Home page.

On the Tags and About pages, the phrase “You can also search for people and institutions” appears below the ‘Log in’ and ‘Sign up’ buttons, whereas it would perhaps be better just below the Search field (see * Screenshot below).

  • Screenshot 15: Search

On one page I got the ‘trusted site’ warning (see * Screenshot below), but it’s not clear why. An issue is that the trusted site url is different from the url displayed in the address bar (see * Screenshot below). Also the message appeared every time I loaded that page.

  • Screenshot 16: trusted site warning.

The phrase “1 favourite” seems to imply that the favourite belongs to the page, rather than the page being a favourite of someone. Would ‘favourited by x people’ be more meaningful?

On a cloud page it seems that ‘comments’ and ‘discussion’ are the same thing. Under the ‘Comments’ heading there are two links: ‘x comments’ links to the ‘Discussion’ section; and ‘post a comment’ links to the ‘Contribute to the discussion’ section. Suggestion: use either ‘comment’ or ‘discussion’.

On the list of Clouds within a cloudscape, when the Discussions tab is selected but there are no items, the phrase “no events” appears (see * Screenshot below). The same occurs when there are no References.

  • Screenshot 17: “no events”.

The labels are misaligned on ‘create a cloudscape’ (see * Screenshot below).

  • Screenshot 18: alignment of form labels.

On the Create Cloud page, the url field does not have ‘http://’ default text, whereas the Add link page does.

The ‘recommend’ link has an extraneous space before it which extends the underline. Also perhaps this word should have a capital R?