How We Test

This site takes the view that check-lists and tests for usability and accessibility are not an ideal way to address the issue of how easy it may be to use on-line learning materials or software in general, and that a more holistic approach is needed (see Reflections on the Development of a Holistic Approach to Web Accessibility).

Web 2.0 Services Applications

Testing Form (DOC) 51KB, PDF 24KB.

Criteria for Tests (DOC) 60KB, PDF 80KB.

Testing documents are coming soon!

Web 2.0 Service Tests

  1. Login, Signup and Other Forms Accessible

    This covers all aspects of registering with a service or site, then returning to sign-in and finally to work with forms. Those who use screen readers and keyboard access need to be able to reach the forms and exit to the rest of the site. There is a need for good labelling to enable users to understand the type of contents required. (W3C WCAG 2.0 2.1, W3C WCAG 2.0 2.4, CAPTCHA W3C WCAG 2.0 1.1 and W3C WCAG 2.0 3.3 ).

  2. Image ALT Attributes

    Images need to have what is commonly known as an 'alt-tag' or text alternative so that a screen reader user can hear about the image - some screen readers will just read the file name or some say 'image' if the attribute is omitted. (W3C WCAG 2.0 1.1).

  3. Link Target Definitions

    Where links are used for menus and navigation or to send users to a different site or area on the page the text for all links needs to be understandable when used without a surrounding sentence or button. (W3C WCAG 2.0 2.4, W3C WCAG 2.0 4.1 and W3C WCAG 2.0 3.2).

    Alternative navigation elements, such as a bread-crumb bar, sitemap or search facility are beneficial (WCAG 2.4.5).

  4. Frame Titles and Layout

    The layout of the contents of a web page can be set into frames rather like a picture or even a frame within a frame (an iframe) so that more information can be carried within a single page. If the frames do not have a title the screen reader user may not know where they are in the page or which piece of content to read next. It is preferable to use Cascading Style Sheets rather than frames. (W3C WCAG 2.0 1.3, W3C WCAG 2.0 2.4 and W3C WCAG 2.0 3.2).

  5. Removal of Stylesheet

    Cascading Style Sheets can be used to provide layout for many aspects within a set of web pages without the use of tables or frames. They allow web page designers to set out the presentation for a web site separately from the content. It makes it much easier to control the main items on web pages such as navigational elements. If the structure is well done it can help accessibility by allowing the user to change colours, fonts and read the site in a linear manner. It is important to check how a site looks with and without style sheets. (W3C WCAG 2.0 1.3 and W3C WCAG 2.0 3.2).

  6. Audio/Video Features

    For those who have sensory disabilities such as deafness or a hearing impairment and for those who may have cognitive learning disabilities offering alternatives for videos with audio, podcasts or audio files for download is essential. With the increase in download speeds the amount of multimedia on the web has increased so additional text transcripts, captioning, and sign language can be very helpful. (W3C WCAG 2.0 1.2).

  7. Video/animations - audio descriptions

    For those who have visual impairments offering alternatives for animations or videos where there are long scenes with no descriptive dialogue is essential. This is particularly true if they are an important part of the web service content. Additional text transcripts and audio descriptions can make this type of media accessible. (W3C WCAG 2.0 1.2).

  8. Appropriate use of Tables

    The layout of the contents of a web page can be set in tables but this can mean that a screen reader user has to listen to what comes first as the software reads across the page from left to right. It may not read down individual columns before crossing to the next row so it is best to keep tables very simple or just for data. The order of content within the table and the use of row and column headers is important. (W3C WCAG 2.0 1.3 and W3C WCAG 2.0 3.2).

  9. Tab Orderings Correct and Logical

    When you cannot use the mouse the order in which the main navigational elements and links appear in a webpage is very important. It is possible to specify this order but it is best to ensure that the code for the webpage results in a logical automatic tabbing order down a page in the same way that a page would linearise without any structural elements such as style sheets, frames or tables. (W3C WCAG 2.0 1.3, W3C WCAG 2.0 2.1, W3C WCAG 2.0 2.4 and W3C WCAG 2.0 3.2).

  10. Page Functionality with Keyboard

    It would seem logical that if the log-in page is inaccessible one should stop checking any further, but because this was an evaluation of interactive user participatory web services and sites, it was felt important to check other aspects of navigation and functionality within the site. (W3C WCAG 2.0 2.1, W3C WCAG 2.0 2.4, W3C WCAG 2.0 1.1 and W3C WCAG 2.0 3.2).

  11. Accessibility of Text Editors

    Many of the sites that allow users to contribute text, images and other multimedia also provide an editor that allows users to change the look and feel of their text as they would in a wordprocesser application. The problem is that not all editors are accessible when using a keyboard or screen reader. TinyMCE appears to be the best option at present. If a user cannot reach the editor with the use of the keyboard then a plain text form should be offered. (W3C WCAG 2.0 2.1, W3C WCAG 2.0 2.4, W3C WCAG 2.0 1.1, W3C WCAG 2.0 3.2 and W3C WCAG 2.0 4.1).

  12. Appropriate Feedback with Forms

    Once a user has submitted text or an answer to a question or multiple choice items it is important that correct feedback is received to prevent confusion. There should be no time restrictions and clear methods for pausing items or returning to a page to correct an error. (W3C WCAG 2.0 2.2, W3C WCAG 2.0 2.4 and W3C WCAG 2.0 3.3)

  13. Contrast and Colour Check

    It is important for everyone to have an enjoyable experience when reading web sites and content should have good levels of colour contrast and no distracting elements. Symbols and other items should not be provided in various colours without there also being other obvious differences to help those with colour deficiencies (colour blindness). (W3C WCAG 2.0 1.4).

  14. Page Integrity when Zooming

    Most browsers allow text and images to be enlarged through a zoom feature or text-resize. This has become more and more useful as web developers appear to be reducing the general size of fonts used which can affect those with visual acuity difficulties and older people. Zooming can improve readability but there are times when it also affects the layout of websites. (W3C WCAG 2.0 1.4).

  15. Text size, style, blinking elements and Readability

    Items that flash or blink at a certain rate can cause seizures and should be avoided. They can also be very distracting and make other elements on a page hard to read. Complex small text and serif fonts can also make text harder to read for some people with cognitive learning disabilities and specific learning differences including dyslexia. The language used needs to be understandable for all users including those who have been deaf since birth or for whom English is not their first language. (W3C WCAG 2.0 2.3 and W3C WCAG 2.0 3.1).

Hybrid Application Tests

  1. Built in accessibility checks

    Application can be used with built-in system assistive technologies or accessibility options e.g. Narrator or VoiceOver, sticky keys, sound sentry, onscreen keyboard, Zoom or Magnifier. The built in assistive technologies vary across the systems and vary as to how much they can help when working with different applications. (CEUD 1.1, IBM 1.2, VPAT section 1194.21 (b)).

  2. Application works with External Assistive Technologies

    Just as the software application needs to work with the operating system built-in assistive technologies and accessibility options so it must work with other assistive technologies. This means that an additional screen reader, alternative input device such as a switch or specialist keyboard should be able to access menus etc. Text to speech software should be able to read text that is added as content and magnification work with all elements. (CEUD 1.2, IBM 2.2, IBM 4.1, VPAT section 1194.21 (b), (c), (d), (l)).

  3. Text or other alternatives for image elements.

    Where images are used for menu or operational elements text alternatives are offered or other alternatives are available. It is important to ensure that colour alone is not used and text it easy to read. (CEUD 1.6, IBM 2.2, VPAT section 1194.21 (d)).

  4. Keyboard / Alternative input with focus

    When you cannot use the mouse the order in which the main toolbars and menus are accessed is very important. Fields, dialog boxes and focal points should all be reached in as logical a manner as possible so that the screen reader, keyboard and switch user can reach all the features in the application. It should also be possible to see where the focus lands with an outlined or highlighted object. (CEUD 1.4, IBM 1.1, IBM 1.2, IBM 2.1 , VPAT section 1194.21 (c)).

  5. Labels for objects, fields or controls

    Labels are linked to controls, objects, icons, and images so that screen reader users are aware of these elements within the application. (CEUD 1.6, IBM 2.2,2.3, 2.4,VPAT section 1194.21 (d)(e)).

  6. Audio alerts have visual cues

    Audio alerts have visual cues plus ability to use sounds sentries or show sounds. Audio options have volume control. (CEUD 1.7, IBM 3.1, IBM 3.2,VPAT section 1194.21 (h)).

  7. Alternatives for Video / Animation

    Software applications may have video or animated help files or tour guides etc. All video or animations need to be provided with alternatives for sound such as transcripts or captions for those with hearing impairments. For those who have visual impairments offering alternatives for animations or videos where there are long scenes with no descriptive dialogue is essential. (CEUD 1.7, IBM 3.2, IBM 4.6,VPAT section 1194.21 (h)).

  8. Media events offer user control

    The user should be able to control events such as video or animation playing, audio and blinking /flashing notification events. There should be no part of the screen that flashes at rates between 2Hz and 55/60Hz. (CEUD 1.8, IBM 3.3, IBM 5.2,VPAT section 1194.21 (k)).

  9. Textual Information for screen reader

    The screen reader user gains access to content, navigation and all actions via audio feedback that is based on textual information. This means the user can hear when the action of say 'copying and pasting' text occurs and font changes are made to text within an application or even when a dialog box appears on the screen. If text is displayed in a none standard way it may not be accessible to a screen reader user. (CEUD 1.6, IBM 4.1, VPAT section 1194.21 (f)).

  10. Keyboard shortcut keys offered

    Standardised shortcut key strokes are important for many users and there must be no interference from other applications to these features. An example would be keys used for copying text or graphics, Ctrl + C for Windows or Command (Apple Key) + C for Mac OS. These keystrokes can speed access and data entry and where a program has its own access keys or shortcuts they must be clearly stated. (CEUD 1.4, IBM 1.2, VPAT section 1194.21 (b)).

  11. Save user preferences for style and zoom

    It should be possible to save the user's style of text, font size and colour within an application and use a zoom or magnification feature. There should also be the choice to inherit the system settings as described under 'Built in accessibility checks' For those with visual impairment and visual stress it may be important to be able to adapt the view of the application and content. (CEUD 1.6, IBM 4.5, VPAT section 1194.21 (b), (g)).

  12. Timed events can be altered

    There should be options to adjust any timed events so the user can work at their own speed. There may be issues with this test in relation to games and some assessments and this must be taken into account where the user is unable to work quickly. (CEUD 2.2, IBM 4.5, VPAT section 1194.21 (l)).

  13. Change colours and contrast

    Ability to change colour and contrast levels to support those who find the default settings unhelpful. There should also be the choice to inherit the system settings as described under 'Built in accessibility checks' For those with visual impairment and colour deficiencies it may be important to be able to adapt the view of the application and content. (CEUD 1.6, IBM 4.2, IBM 4.3,VPAT section 1194.21 (g)).

  14. Uniform and standardised presentation

    If the application does not present a standardised way of interacting with elements within the program it can be confusing for some users. Consistency of navigation and task procedures is important. Standardised placement of elements on the screen, such as well known menu items and dialog boxes helps users. (CEUD 2.2).

  15. Documentation

    All instructions and help files should be clear, easy to read and available in accessible electronic format. This documentation should also be designed so that it can be printed out or embossed (Braille). (CEUD 1.12).