Website Accessibility Report

Website Accessibility Report
Site Reviewed: / Select pages from BCC development site
Consultant:
Date: / 2nd December 2009

Contents

This report is the result of an audit of the in-development Birmingham City Council website, focusing mainly on the form elements. Whilst the content was audited to WCAG1, additional recommendations are also made for achieving WCAG2 compliance.

Table of Contents

Contents

Image list

WCAG 1 Issues and Recommendations

1.1Images and alt text (Priority 1)

2.1 Color (Priority 1)

3.5 Headings (Priority 2)

13.1 Link purpose (Priority 2)

3.1 Validation (Priority 2)

3.4 Relative v Absolute size attributes (Priority 2)

10.2 \ 12.4 Provide labels for form controls

WCAG 2 Issues and Recommendations

Skip links

Assistive Technology Review

Screenreader (JAWS)

Voice recognition (Dragon Naturally Speaking)

Screen magnification (ZoomText)

Keyboard only

Windows high visibility colour scheme

Image list

Figure 1 Image used as a link

Figure 2 Image as link

Figure 3 e-subscribe button

Figure 4 Image alt text duplicates link text

Figure 5 Images as bullet points

Figure 6 Missing alt text

Figure 7 Links identified by colour alone

Figure 8 Sole H1 heading

Figure 9 No headings on page

Figure 10 Link may not make sense out of context

Figure 11 Validation errors

Figure 12 Largest text size selected

Figure 13 Smallest text size selected

Figure 14 Checkpoint missing label

Figure 15 Radio buttons missing labels

Figure 16 Link unreadable

Figure 17 Birmingham City Council link has insufficient contrast

Figure 18 Example of insufficient contrast

Figure 19 Page title

Figure 20 Progress bar at no zoom

Figure 21 Progress bar viewed at 8x magnification

WCAG 1 Issues and Recommendations

There were very few WCAG 1 issues found across the site, and those that were found were consistent across all pages tested. Whilst some examples are given here, the results really need to be extrapolated across the whole site and the recommendations here used as guidance when addressing the issues raised.

1.1Images and alt text (Priority 1)

Why is it important? And who does it affect?

The use of alternative text (also known as ‘alt tags’) for pictures, text as graphics, decorative graphics, spacer gifs, form buttons and graphical links is fundamental to accessibility – it is responsible for around 30-40 percent of all problems affecting a range of disabled people accessing the web.

All graphics on a page need to be labelled correctly for a number of reasons. Blind users accessing the website via a screen reader will have only the information in the alt tag to gauge the importance of a particular image. In addition, missing alt text on graphical links and form buttons will impede the usability of the website for users accessing via voice recognition software. The usability of the website will also be significantly reduced for users with cognitive impairments or dyslexia as software packages that they use to assist them (e.g. Text Help’s Read and Write) will speak the content of the page including pictures and graphical links. Therefore, if no alternative text is provided, this would reduce the readability and their understanding of the content.

Issues

Unsuitable image alt text

Several pages contained the highlight image shown below

Figure 1 Image used as a link

This was coded up as:

ahref="/CwsWeb/flow/serviceguidance?type=content&reference=OnlineAccount">

imgsrc="/CwsWeb/images/campaign-council-account.gif" alt="right side image 1" />

</a

Note the alt text for this image ‘Right side image 1’. The alt text for an image should describe either the contents of an image, or if the image is a link, the link destination.

In this case, the alt text should read similar to the image text e.g. ‘Making the most of your council account’.

This is important for several reasons:

  • Blind users, using screenreading technology, will hear image alt text read out to them by their screenreading technology.
  • Users with literacy difficulties may use assistive software to read out portions of web pages to them. For images, as above, the alt text will be read out.

In both these cases, image alt text is relied on by the user to be both present and descriptive. And in both cases, the above link would be read out as “Right side image 1”

A good rule of thumb is to imagine browsing the page with images turned off in your browser, seeing only the alt text instead – does the page still make sense?

Solution

In this case the image alt text needs to be changed, as stated, to ‘Making the most of your council account’ or similar.

Incidentally, you can turn of image display in Internet Explorer via Tools > Internet Options. IE will then display the alt text of any image in place of the image.

Unsuitable image alt text

Similar to the above example is this the alt text for this image \ link

Figure 2 Image as link

In this case, the code for this link\image is:

ahref="/CwsWeb/flow/common/security/upgradeAccount"<spanclass="image_left"<imgalt="left advert 1"src="/CwsWeb/images/icin-upgrade-account.gif" /</spanUpgrade Account</a

This is slightly different to the first example; the link element contains both an image and some text. Again, note the alt text (bolded above) ‘Left advert 1’.

A screenreader user would hear this link read out as ‘Left advert 1 Upgrade account’.

Because the link text already describes the link destination, there is no need for the alt text here. However, rather then remove the alt text attribute altogether, it should specify a blank alt text value e.g. alt=””. Doing this tells the screenreader that there is nothing to read out for the image. If the alt text attribute is missed out altogether, a screenreader will try and be clever, and will read out the image’s pathname – often entirely useless to the user.

Solution

Specify blank alt text for the image e.g. alt=””. This applies whenever an image and text are used within the same link element – the link text should describe the link destination\function, and the image should be given a blank alt text attribute.

Unsuitable image alt text

Similar to the first issue mentioned, is the e-subscribe button:

Figure 3 e-subscribe button

This button is a link and is coded as:

ahref="#"imgalt="subscribe button"src="../images/e-subscribe-button.gif"</a

Whilst the alt text is better here; it describes the link destination partially. However a user just hearing the text ‘Subscribe button’ would wonder what it would subscribe too.

Solution

Expand the alt text to read the same as the image text e.g. alt=‘Subscribe to Birmingham bulletin’

Duplicate image alt text \ button text

The image below shows the logout link, which is both an image and text contained within a single link:

Figure 4 Image alt text duplicates link text

This is coded as:

<a href="/CwsWeb/logout">
<img src="/CwsWeb/images/logout.gif" alt="logout" />
<span class="bold">Logout</span>
</a>

Note that the image has been given an alt text attribute of “Logout”, the same as the link text. A screenreader will read out both the image alt text, and then the link text, in this case it would read out “Logout Logout”

Solution

Because the link text already describes the link function, the image alt text can be set to blank e.g. alt=””. In this way, there is no unnecessary duplication for the user.

Unsuitable image alt text

Whilst the above examples dealt with functional images, this example is about cosmetic images.

Figure 5 Images as bullet points

The above figure shows 3 highlighted images. The alt text for each of these image is alt=’Bullet point’

Where images are cosmetic images, that is they do not convey any useful information to the user, they should be assigned a blank alt text value e.g. alt=””

Doing this prevents audio clutter – what happens when a screenreader user encounters, and reads out, lots of content that conveys no information to the user.

Solution

Where cosmetic images are used, always provide a blank alt text attribute. So, each of these bullet point images would need to be coded as <img src=”bullet.gif” alt=”” /> or similar

Missing alt text

After logging in, all pages contained the image highlighted below

Figure 6 Missing alt text

This image is coded up as:

imgclass="myaccount" src="/CwsWeb/images/avatar-default.gif" />

Note that there is no alt text attribute for this image.

Solution

As the image is essentially cosmetic, as with the bullet point images previously, it can be supplied with a blank alt text attribute e.g. <img src=”account-avatar.gif” alt=”” />

Alt text best practice

Here are some key pointers when writing alternative text to ensure it is as relevant as possible:

  1. Keep alt textconcise and brief - avoid verbosity.
  1. If the image is a link, you must describe the destination or purpose of the link not a description of the image itself.
  1. For link images do not add the phrase ‘click here for’ and for picture images do not add the phrase ‘picture of …’
  1. Where possible, start the alt text with a keyword, for example simply use ‘Weather’ rather than ‘the weather’. This benefits screen reader users who can bring up all the links on a web page into a ‘links list’ - hitting ‘W’ will jump them to the first item on the list that starts with ‘W’.
  1. Empty alt (alt=””) text should only be put on images that do not convey any useful information to the content of the page such as spacer and decorative graphics or images wrapped in the same anchor tags as the equivalent text link so both screen readers and text readers ignore them making the page a more pleasant experience to read.

2.1 Color (Priority 1)

This checkpoint states that colour alone should not be used to identify elements

This is primarily aimed at colour blind users (who may be unable to distinguish similar colours), users with poor vision or users of monochrome screens.

Figure 7 Links identified by colour alone

The above image shows some links within a paragraph that are only distinguished through their colour.

To ensure links are visible to all users, use another feature in addition to colour, for instance, underlining. Note that this really only applies to links within body text on the page. Links within recognisable navigation bars, such as the left hand navigation, can be determined due to their context.

3.5 Headings (Priority 2)

Why is it important? And who does it affect?

Correctly structured headings enable users to gain a feel for the structure of the document - making content more readable. Screen reader users can listen to a list of headings to find out which section of the page interests them instead of listening to the entire content.

This issue affects all users but it specifically affects, screen reader users and users with a cognitive disability.

Issues

Many of the pages tested either had no, or too few, headings.

Insufficient headings

The login page contains just one H1 level heading (highlighted in below figure):

Figure 8 Sole H1 heading

In this case, there is a potential heading above the left hand menu ‘Not registered yet’. This would logically be a level 2, H2, heading, coming as it does, subsequent to the main heading.

No headings

The My Council page has no headings coded up. Below is a screenshot that shows the proposed heading structure of the page.

Note that there is a single H1 heading, with all child headings of this being level 2 headings. Were these sections to have sections within them, these child sections would then be headed with H3 level headings, and so on.

Figure 9No headings on page

Headings best practise

  • Generally speaking, a page should contain a single level 1, H1, heading
  • Headings should be nested in sequence, so below the H1 heading on a page can only come H2 headings. Below these H2 headings can be either another H2 heading (if the heading is at the same logical level), or a H3 heading if it is a child of the H2 heading, and so on.

13.1 Link purpose (Priority 2)

This checkpoint stipulates that links must make sense if read out of context. This is primarily aimed at screenreader users who will often bring up a list of all the links on a page to browse through.

Figure 10Link may not make sense out of context

The figure above shows the username as a link. Visually, I may make the assumption that because of the ‘not’ qualifier, that the link will log me out. However, because the link text is the username only, a screenreader user may well just hear the link out of context e.g. “Christian Cage”. If this is the user, it is likely (following conventions) that the user would expect this link to go to their profile on this website – not log them out.

Solution

As there is already a logout link already displayed on the right hand side, it is recommended that this link is either removed or replaced with text ‘Not Christian Cage? Log out” With “Log out” as the link text. There is no real harm in having duplicate logout links, and users will be aware of the link function, even if read out of context.

3.1 Validation (Priority 2)

Why is this important \ who does it affect

Having code that validates ensures that user agents (browsers) and assistive technologies (screenreaders) are given the best possible chance of correctly interpreting and displaying web content.

Issue

None of the pages validated:

Figure 11 Validation errors

Solution

Use the W3 validator at to find validation errors, and correct them.

3.4 Relative v Absolute size attributes (Priority 2)

This checkpoint relates to css size attributes. Elements, particularly fonts, can be sized using numerous different attributes e.g. px, pt, %, EM.

It is important that elements, particularly fonts, are sized using relative units such as % or EM values. This allows content to resize for the user when they choose a different font size in their browser (In IE this is by selecting Text Size from the view menu).

Issue

Whilst the majority of content was set using relative size units, there were some input elements that did not resize along with the rest of the page when a larger or smaller text size was selected in IE.

The two images below show the login form both with largest, and then smallest text size selected in IE.

Figure 12 Largest text size selected

Figure 13 Smallest text size selected

Note that whilst the majority of the text resizes, the input fields, and input labels, do not resize.

This is likely because the font size for each of these element is set using an absolute size unit such as pt or px.

Solution

To ensure input field contents resize, set the css font-size property to font-size: 100% or similar. Similarly, for the field labels, ensure that the font size is set using a % or EM value.

10.2 \ 12.4 Provide labels for form controls

All input fields must be provided with labels. For smaller controls, such as radio buttons or checkboxes, the label itself can be used to activate that particular control. This is useful where the input element itself provides a small target for mouse users, who may find it difficult to click on an individual radio button.

There were two issues found that breached this checkpoint.

Figure 14 Checkpoint missing label

The above image shows a checkbox with no label. In this case, the text immediately to the left is ideally suited to be the checkboxes label, and this could be coded as follows:

<label for=”privacyCheckbox”>I have read and agree for my information to be used in accordance with Birmingham City Council’s privacy policy</label>

input type=”checkbox” id=”privacyCheckbox” name=”privacyCheckbox” />

Note that the labels for attribute matches the input field’s id attribute. This creates an explicit association between the two elements

The second issue was found on the address selection page.

Figure 15 Radio buttons missing labels

In this case, the number\street data could be used as the radio buttons label. This would be coded in the same way as the checkbox above e.g.

<label for=”address1”>Beauty box, Corporation Street</label>

...

<input type=”radio” id=”address1” name=”address” />

As before, the labels for attribute matches up with the input field’s id attribute, creating an association between them. This would allow a user to select a radio button by clicking on the associated street\number value on the table.

WCAG 2 Issues and Recommendations

The following are issues and recommendations based on achieving WCAG2 compliance. These are in addition to the previous issues and recommendations based on WCAG1.

Skip links

On all pages, whilst a skip link was provided, there were three issues with the skip link:

  • There was no corresponding named anchor tag, meaning the link did not work
  • The skip link was only accessible to blind, screenreader users, as it was not visible
  • The skip link was not the first item on the page
Issue: Skip link and named anchor tag

On each page, the skip links are coded as:

atabindex="0"id="Content"href="#content"class="content-link"title="skip to content"</a

However there was no corresponding named anchor for these links to jump to.

Solution

At the beginning of the page content, and after the page navigation, place a named anchor: