national library of australia australian newspapers

Vision Australia was formed by the merger of the Royal Blind Society of NSW, the Royal Victorian Institute for the Blind, Vision Australia Foundation, the National Information & Library Service, Royal Blind Foundation of Queensland and Seeing Eye Dogs Australia.

Web Accessibility Consultancy Service

National Library of Australia

Australian Newspapers website

Accessibility Review April 2009

Prepared for: Bobby Graham Web Content Manager National Library of Australia Address: Canberra, ACT 2600 AUSTRALIA Phone: +61 2 6262 1542 Email: BGRAHAM@NLA .gov.au

Australian Newspapers beta Web Site Accessibility Review April 2009

Vision Australia - Web Accessibility Solutions of 55

Contacts:

Josh Crawford Web Accessibility Consultant Phone: (03) 9864 9257 Email: [email protected] Gaynor Eccleston Senior Web Accessibility Consultant Phone: 03 9864 9282; Fax: 03 9864 9370 Email: [email protected]

Registered Office Vision Australia 454 Glenferrie Road Kooyong Victoria 3144

Mailing Address Vision Australia PO Box 860 Hawthorn Victoria 3122 ABN: 67 108 391 831 ACN: 108 391 831



Version control Version Author Version Description

0.1 Josh Crawford April 1, 2009 Technical review commenced

0.2 Gaynor Eccleston April 3, 2009 Technical review

0.3 Gaynor Eccleston April 17, 2009 Screen reader user testing

0.4 Pierre Frederiksen April 22, 2009 Quality assurance

1.0 Josh Crawford April 22, 2009 Report finalised



Table of contents National Library of Australia........................................................................................ 1

Australian Newspapers website.................................................................................. 1

Accessibility Review ................................................................................................... 1

Report summary ......................................................................................................... 5

Priorities for redevelopment .................................................................................... 5

1. Introduction............................................................................................................. 6

1.1 Scope................................................................................................................ 6

1.2 Methodology ..................................................................................................... 6

1.3 About the Web Content Accessibility Guidelines 2.0......................................... 7

References .......................................................................................................... 7

1.4 Who benefits from accessible design?.............................................................. 8

2. Findings ................................................................................................................ 11

2.1 Summary tables .............................................................................................. 11

Conformance level summary............................................................................. 11

Summary by success criteria............................................................................. 11

2.2 Detailed findings ............................................................................................. 13

Guideline 1.1 Text alternatives .......................................................................... 13

Guideline 1.3 Adaptable .................................................................................... 21

Guideline 1.4 Distinguishable ............................................................................ 24

Guideline 2.1 Keyboard accessible ................................................................... 30

Guideline 2.4 Navigable .................................................................................... 34

Guideline 3.1 Readable ..................................................................................... 44

Guideline 3.2 Predictable .................................................................................. 48

Guideline 3.3 Input assistance .......................................................................... 49

Guideline 4.1 Compatible .................................................................................. 54



Report summary We reviewed the accessibility of the Australian Newspapers web site in April 2009.

Many features that meet accessibility requirements have already been implemented into this site however, the site does not conform to level A of the Web Content Accessibility Guidelines 2.0.

The report details our findings and recommended solutions.

Priorities for redevelopment Our assessment of the most immediate priorities for redevelopment is shown below. This is based on considering the accessibility benefits, technical complexity and effort required to address the problem, frequency with which the problem occurs, and the importance of the function or content where the problem occurs.

• Info and Relationships – 1.3.1

• Bypass blocks – 2.4.1

• Focus order – 2.4.3

• Labels or instructions – 3.3.2

As this site provides interactive features, many of the issues in this report are related to specific user processes such as creating a user account and editing an article. As we do not report on every instance of an issue, we recommend further checks by the developers to identify whether the same issues occur on other pages, particularly during other user processes.



1. Introduction We were asked to review the Australian Newspapers to identify any potential accessibility problems and suggest solutions. We reviewed the site in April 2009, and our findings and recommendations are detailed in this report.

1.1 Scope Our review includes:

• Main Australian Newspapers web site at http://ndpbeta.nla.gov.au/ndp/del/home

Out of scope for this review:

• All pages not falling under the URL specified above • Accessibility assessment of downloadable documents

1.2 Methodology

Expert review The site was reviewed for conformance to the Web Content Accessibility Guidelines 2.0 by one of our experienced accessibility consultants. The consultant:

• Selected a sample of 1000 pages to review

• Ran a script across this sample set to identify problems that can be found with an automated checking tool (e.g. images with missing ALT attributes)

• Checked the mark-up of the problem pages identified by the script

• Checked for other issues using the Vision Australia Web Accessibility Toolbar Web Accessibility Toolbar (www.visionaustralia.org.au/ais/toolbar)

• Considered solutions to problems and where needed, tested the solutions using Firefox version 3 and Internet Explorer version 6 running on Windows XP service pack 2 and Internet Explorer version 7 running on Windows XP service pack 3.

Assistive technology review

Screen reader testing The reviewer identified pages or design elements that might cause problems for people who are blind and use screen readers to read web pages.

An expert screen reader user then tested these pages, using JAWS version 9 running with Internet Explorer version 7 on Windows XP service pack 3.



Screen magnifier testing The reviewer identified pages or design elements that might cause problems for people with low vision who use screen magnifiers to enlarge the text and images on a page.

An expert screen magnifier user then tested these pages, using Zoomtext version 9.1 running with Internet Explorer version 7 on Windows XP service pack 3. The screen resolution was set at 1024x768, with magnification at 400 per cent.

Quality assurance A second accessibility consultant reviewed the first draft of this report and checked:

• The suggested solutions.

Changes were discussed and incorporated into the final report.

1.3 About the Web Content Accessibility Guidelines 2.0 On 11 December 2008 the World Wide Web Consortium (W3C) released the Web Content Accessibility Guidelines 2.0 (WCAG 2.0) as a W3C recommendation.

These guidelines are an international standard that:

• Define how to make web sites more accessible to people with a range disabilities

• Consists of 12 guidelines supplemented by 61 success criteria—testable standards that web sites should meet. These are arranged in three levels with level A (the lowest), being the most fundamental and essential.

The more success criteria a site meets, the more accessible it is likely to be. However, it is still possible that people with some types, degrees or combinations of disabilities might still have problems using the site.

The Australian Human Rights Commission has endorsed version 1.0 of the Web Content Accessibility Guidelines. We anticipate the Commission will endorse version 2.0 during the first half of 2009.

The Commission believes the guidelines will help organisations meet their obligations under the Disability Discrimination Act 1992 with respect to web accessibility.

References Web Content Accessibility Guidelines 2.0 http://www.w3.org/TR/WCAG20/

Understanding conformance to the Web Content Accessibility Guidelines 2.0 http://www.w3.org/TR/2008/WD-UNDERSTANDING-WCAG20-20080430/conformance.html

World Wide Web Access: Disability Discrimination Act Advisory Notes http://www.hreoc.gov.au/disability_rights/standards/www_3/www_3.html



1.4 Who benefits from accessible design? There are many benefits in developing a site that conforms to the guidelines.

Improved usability for all users Accessible web pages tend to be more usable, particularly for older people whose vision, motor or cognitive skills have begun to decline. They are also more likely to be:

• Compatible with a range of devices people use to access the web, including mobile phones and older browsers

• Faster to download and display

• Better when printed.

Benefits for your organisation Accessible web content can benefit your business because it is likely to be easier to maintain and ranked better in search engines. Accessible design is also the hallmark of an organisation with a social conscience.

Benefits for people with disabilities For many people with disabilities, the web offers the potential for them to be more independent and participate more actively in social, work and education activities. Accessible design removes the barriers to independence and participation.

Vision impairments People who are blind use screen reader software to read the text on the page. They use the keyboard to move around a web page. They cannot use a mouse because they cannot see the screen.

People with low vision—a range of conditions that glasses or contact lenses do not correct—may use screen magnifier software to enlarge the text and images on the page. Some use a screen reader as well. Many will also need to change the colours or increase the font sizes used on a page.

About 8% of men and some women are colour-blind. They do not usually use any special software to access the web.

Motor skill impairments Injury or disease can cause a range of motor skill impairments, from paralysis to tremor or weakness of the limbs. People with these types of impairments may not be able to use the mouse, or control the mouse or keyboard well. Some may use voice-activated software. Others may use head wands or other devices to help them interact with your web site.

Cognitive impairments There are many type of cognitive impairment including dyslexia, attention deficit disorder, and learning disabilities. People with cognitive impairments may have



difficulty with memory, problem-solving, attention, reading, visual comprehension or mathematical comprehension.

Hearing impairments Hearing impairments include a range of levels and types of hearing loss, from mild to profound. Those with lower levels of hearing loss may use a hearing aid.

Seizure disorders People with seizure disorders may be affected by certain types of strobing, flickering or flashing effects of content on the web.

How some people use the web

Screen reader users A screen reader is software used by blind, visually impaired and dyslexic users. It reads out the text on a web page and announces the structure. For example:

• Images: the screen reader will say “Graphic” and then read the alt-text

• Headings: the screen reader will say “Heading level ...” and then read the text in the heading

• Lists: the screen reader says "List of ... items". For a nested list the screen reader says "List of ... items, nesting level 1"

Screen readers also provide keyboard shortcuts to help users move through the page. For example:

• H key: moves from heading to heading

• L key: moves from list to list

• T key: moves from table to table

• F key: moves between form fields.

• Insert + F7: provides the user with a list of all links on the page so they can navigate quickly

Screen magnifier users A screen magnifier is software used by people with low vision. It magnifies the screen, enlarging all the content on a page. Some users scale the content as much as 6 times.

Using a screen magnifier means:

• Much more moving around the page—sideways as well as up and down – using the mouse to move the viewport

• Not all of the information on the web page is visible at the one time



Keyboard-only (no mouse) users Some users cannot use a mouse because they cannot:

• See the screen to point to anything on it

• Use their arms or hands at all or for very long

• Control their arms or hands well enough to use a mouse.

Some of these users might use pointing sticks or other devices to hit keys on the keyboard.

Various keys allow users to use the page:

• Tab key: jumps between links, form controls and other interactive elements

• Enter key: clicks on links

• Space bar: ticks checkboxes in forms.

References Auditory disabilities http://www.webaim.org/articles/auditory/

Cognitive disabilities http://www.webaim.org/articles/cognitive/

Motor disabilities http://www.webaim.org/articles/motor/

Seizure disorders http://www.webaim.org/articles/seizure/

Visual disabilities http://www.webaim.org/articles/visual/

Developing a web accessibility business case for your organisation http://www.w3.org/WAI/bcase/Overview



2. Findings

2.1 Summary tables

Conformance level summary

WCAG 2.0 conformance Success criteria failed

Level A 1.1.1, 1.3.1, 1.3.3, 1.4.1, 2.1.1, 2.4.3, 2.4.4, 3.2.2, 3.3.1, 3.3.2, 4.1.2

Level AA 1.4.3, 1.4.4, 2.4.6, 2.4.7, 3.3.3

Level AAA 1.4.6, 1.4.8, 2.4.8, 2.4.9, 2.4.10, 3.1.4, 3.1.5, 3.3.5

Summary by success criteria

Guideline Success criteria failed

Conformance level

Discussed on page(s)

1. 1 Text Alternatives 1.1.1 A 13-21

1. 3 Adaptable 1.3.1 A 21-23

1.3.3 A 23-24

1. 4 Distinguishable 1.4.1 A 24-25

1.4.3 AA 25-26

1.4.4 AA 26-28

1.4.6 AAA 28

1.4.8 AAA 28-30

2. 1 Keyboard Accessible 2.1.1 A 30-33

2. 4 Navigable 2.4.3 A 34-37

2.4.4 A 37-39

2.4.6 AA 39-41

2.4.7 AA 41-42

2.4.8 AAA 42-43

2.4.9 AAA 43

2.4.10 AAA 43-44

3. 1 Readable 3.1.4 AAA 44-45

3.1.5 AAA 45-48



3. 2 Predictable 3.2.2 A 48-49

3. 3 Input Assistance 3.3.1 A 49-50

3.3.2 A 50-51

3.3.3 AA 51-53

3.3.5 AAA 53-54

4. 1 Compatible 4.1.2 A 54



2.2 Detailed findings Our findings are grouped by guideline and success criterion (note: our wording of the guidelines is sometimes paraphrased).

Guideline 1.1 Text alternatives Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, Braille, speech, symbols or simpler language

1.1.1 Non-text content Level A All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

• Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)

• Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)

• Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.

• Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.

• CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.

• Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

Issue 1 Image has no alt attribute

Example

Header

Description

This image does not have an alt attribute.

Code used <img border="0" src="/static/ndp/images/nla_logo-header.gif"/>



Implications

Screen reader users are unlikely to be made aware that this image is the National Library of Australia logo. Screen readers often announce the URL of the image, when no alt attribute is provided. The image is also a link and although a title of “National Library of Australia and partners” is provided in the link, this is not announced by the screen reader. For example in this instance, JAWS announced “link graphic nla_logo-header”.

Solution

Include an alt attribute for this image. It should have the alternative text “National Library of Australia – logo” as this includes the exact text included in the image and shows users that it is the logo.

For example: <img border="0" src="/static/ndp/images/nla_logo-header.gif" alt="National Library of Australia - logo" />

Note

The ‘Discard changes made to this line’ button in the article editing feature also has this issue.

Issue 2 Labels not marked up as labels and associated with text fields

Example

Login page (ndpbeta.nla.gov.au/ndp/del/auth)



Description

The Username and Password labels are not marked up as labels and associated with the corresponding text fields using the “for” and “id” attributes.

Code used <td>Username</td> <td><input type="text" size="32" name="userid"/></td> </tr> <tr>

<td>Password</td> <td><input type="password" size="32" name="password"/></td>

Implications

Some screen reader users may have trouble understanding which label goes with each text field. They may also not know that the text is a form label.

Solution

Always mark-up form labels and associate them with the corresponding input controls using the “for” and “id” attributes.

For example: <label for=“userid”>Username</td> <td><input type="text" size="32" id=”userid” name="userid"/></td> </tr> <tr>

<label for=”password”>Password</label> <td><input type="password" size="32" id=”password” name="password"/></td> Notes

1. This issue will apply to other form fields on the site such as on:

• http://ndpbeta.nla.gov.au/ndp/del/forgotPassword

• http://ndpbeta.nla.gov.au/ndp/del/signup

• http://ndpbeta.nla.gov.au/ndp/del/search?searchTerm=&facet=category:Advertising

2. This issue also applies to the search box located in the top right corner across the site. In this instance a title attribute can be added to the code (which will be announced to screen readers) rather than being required to change the design of the page by adding a visible label to the form.



Existing Code <div> <span class="text"><span><input class="text" name="searchTerm" id="searchbox" type="text"></span></span><input class="button" value="Search Articles" type="submit">

Solution Code <div> <span class="text"><span><input class="text" name="searchTerm" id="searchbox" type="text" title="Enter search term here"></span></span><input class="button" value="Search Articles" type="submit">

3. On the advanced search page (http://ndpbeta.nla.gov.au/ndp/del/search?adv=y) labels have been provided for some form fields.

Issue 3 No alternative text for scanned newspaper images

Example

Homepage

Description

The images of the scanned newspapers do not have alternative text.

Code used <div class="well">



<img class="tile" src="/ndp/imageservice/nla.news-page470449/tile3-4-9" style="width: 256px; height: 256px; top: 139.15px; left: -213.25px;"/> <img class="tile" src="/ndp/imageservice/nla.news-page470449/tile3-4-10" style="width: 256px; height: 256px; top: 395.15px; left: -213.25px;"/> Etc..

</div>

Implications

On the homepage, screen reader users are not made aware of the images as there is no text announced to describe the content of the image.

Solution

To satisfy this success criterion a text alternative of the article title contained on the homepage is required. For example, the articles that appear when a newspaper is viewed have headings:

The text in the left-hand column provides the text alternative for the image with a link to the full article.

On the homepage include the title of the featured article above the image and make it a link to the full article.

Notes Ideally, for the content to make the most sense to the user on the homepage, the content would be in this order:

1. On this day (heading)

2. The Canberra Times, Thursday 15 April 1954 (newspaper info)

3. Thursday’s Weather Chart (Article title)

4. Read this article button

See issue 2.4.3 for more on focus order.



Issue 4 CAPTCHA image

Example

Help fix this text – Edit immediately

Description

The CAPTCHA image of characters has no alternative text.

Code used <img src="/ndp/del/captchaImage?t=1240094045077"/>

Implications

Screen reader users cannot access the content of this image. Screen readers often announce the URL of the image, when no alt attribute is provided.

An alt tag is required to prevent screen readers from reading the path of the image i.e. “="/ndp/del/captchaImage?t=1240094045077”.



Solution

Include an alt attribute for this image as follows: <img alt=”characters” src="/ndp/del/captchaImage?t=1240094045077"/>

Notes on CAPTCHA

Alternative versions of the CAPTCHA should be provided such as the audio version provided on the ‘Sign up’ page.

A ‘Help’ link on this page located after the image is required to provide assistance to users who do not understand and cannot use the CAPTCHA function.

As there are accessibility issues with the audio CAPTCHA, further assistance such as a human customer service representative must be provided to enable users who cannot use this feature to complete the registration task.

Audio CAPTCHA

The audio captcha feature on the ‘Sign up’ page is a link to an audio clip (.wav file). See 3.3.2 Labels or Instructions Level A for accessibility issues with this feature.

Issue 5 Charts do not have adequate alt text

Example

About (ndpbeta.nla.gov.au/ndp/del/about)



Description

This chart does not provide adequate alternative text.

Code used <img alt="Lines corrected by month" src="http://www.nla.gov.au/ndp/project_details/images/Linescorrectedbymonth_000.jpg"/>

Implications

Screen reader users will miss out on the information in the chart in addition, users who have trouble reading chart graphs may have trouble comprehending the chart.

Solution

Include an alternative version of the chart in the form of a table. Alternatively, provide a text summary of all the important information communicated by the chart.



Guideline 1.3 Adaptable Create content that can be presented in different ways (for example simpler layout) without losing information or structure

1.3.1 Info and Relationships Level A Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Issue 6 Heading level skipped

Example

Home page (ndpbeta.nla.gov.au/ndp/del/home)

Description

The heading levels skip a level from <h1> to <h3> on this page.

Code used <h1><a href="/ndp/del/home">Australian Newspapers <span>beta</span></a></h1> …omitted code… <h3 id="homeSearchPrompt">Find an Article</h3>

Implications

Screen reader users rely on heading mark-up to assist with understanding and navigating the page. When a heading level is skipped, they may start to mistrust the mark-up, or look for where that heading may be.



Solution

Ensure that the heading mark-up does not skip a level. Change the <h3> level heading to a <h2> level heading.

For example: <h1><a href="/ndp/del/home">Australian Newspapers <span>beta</span></a></h1> …omitted code… <h2 id="homeSearchPrompt">Find an Article</h2>

Note This issue appears on other pages such as ‘Reset your password’

Issue 7 Heading not marked up as a heading

Example

The Canberra Times (ndpbeta.nla.gov.au/ndp/del/article/2900968/702162?zoomLevel=3)

Description

The Canberra Times heading on this page is not marked up as a heading in the HTML structure.

Code used <div class="box title">

<strong>The Canberra Times</strong> <span class="about">(<a href="/ndp/del/title/11">about</a>)</span>

</div>

Implications

Screen reader users may struggle to find the heading for this page.

Solution

Mark this heading up as a <h2> level heading.



For example: <div class="box title">

<h2>The Canberra Times</h2> <span class="about">(<a href="/ndp/del/title/11">about</a>)</span>

</div>

1.3.3 Sensory Characteristics Level A Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.

Issue 8 Instructions using a visual location to describe the location of content

Example

Searching for Images

Description

The instructions in this section describes a section of the page using a visual location, in this instance using ‘left’ as follows:

“Once you have your search results, on the left hand side of the results list there is a 'refine' area with pre-defined groups for refining your search.”

Implications

This cannot be easily understood by screen reader users.

Solution

Include further information in the text to allow the content to be identified without the knowledge of it’s visual location.

For example:

“Once you have your search results, on this page there is a 'Refine Search' feature with 5 pre-defined groups for refining your search.”



Guideline 1.4 Distinguishable Make it easier for users to see and hear content including separating foreground from background

1.4.1 Use of Color Level A Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

Issue 9 Link not clear on the page

Example

Homepage ‘On This Day’ section

Description

The title of the featured newspaper (The Canberra Times, Saturday 19 April 1952) on the same line the heading is a link but this isn’t clear to users looking at the page.

Implications

Users may miss this feature.

Solution

Style the newspaper title to distinguish it as a link, separate from the heading of the section.

This can be done by changing the colour of the text to have a colour contrast of at least 3:1 with the heading text along with making the colour of the text link change on keyboard and mouse focus.



1.4.3 Contrast (Minimum) Level AA The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1; • Incidental: Text or images of text that are part of an inactive user interface component, that are pure

decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

• Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Issue 10 Colour contrast is less than 4.5:1

Example

Navigation links

Description

The colour contrast between the text and the background colours of the above text is less than 4.5:1.

Screen capture of Colour Contrast Analyser tool results:

Implications

Some users may have trouble reading the text.



Solution

Change the colours so that the contrast is greater than 4.5:1.

A free Contrast Analyser can be downloaded from here:

http://www.paciellogroup.com/resources/contrast-analyser.html

Note

Various other instances of this issue were found with text, links and buttons across the site.

1.4.4 Resize text Level AA Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Issue 11 Button text not resizing

Example

Sign up (http://ndpbeta.nla.gov.au/ndp/del/signup)

Description

The text in the ‘Sign up’ button on the ‘Sign up’ page does not resize in Internet Explorer (View, Text Size).

Screenshot of the button in Internet Explorer with the text size set to ‘largest’:

Code used

CSS: body, input, select, textarea {

font-family: 'segoe ui',tahoma,arial,sans-serif; }



Implications

Sighted users who need to increase the font size in Internet Explorer via the text size settings cannot do so. Internet Explorer 7 features a zoom function that works regardless of font size settings, however, Internet Explorer 6 does not. As long as Internet Explorer 6 is widely used (say 5% or above in browser stats), content should resize in response to font size settings.

Solution

Specify font size in relative units explicitly for form controls. This includes both form controls which are:

• Text based, such as text input, select boxes and buttons.

• Non-text based, such as radio buttons and checkboxes: These need a width and height with relative unit for the form control. Note that typically a value of "1em" will not result in a visible difference when the font size is changed. A value of "1.2em" works.

Example generic CSS: label, input, textarea, select, legend, button {

font-size: 1em; } input.geomsize {

width: 1.2em; height: 1.2em;

}

Example generic (X)HTML: <input type="text" maxlength="32" size="25" id="t1" /> <input type="radio" name="r1" value="r1" id="r1" class="geomsize" /> <input type="checkbox" name="c1" id="c1" value="c1" class="geomsize" />



1.4.6 Contrast (Enhanced) Level AAA The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following:

• Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1; • Incidental: Text or images of text that are part of an inactive user interface component, that are pure

decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

• Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Issue 12 Colour contrast less than 7:1

Example

Refer to Issue 1Issue 10 Colour contrast is less than 4.5:1

Solution

For Level AAA conformance, ensure that the ratio is at least 7:1.

1.4.8 Visual Presentation Level AAA For the visual presentation of blocks of text, a mechanism is available to achieve the following:

1. Foreground and background colors can be selected by the user. 2. Width is no more than 80 characters or glyphs (40 if CJK). 3. Text is not justified (aligned to both the left and the right margins). 4. Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing

is at least 1.5 times larger than the line spacing. 5. Text can be resized without assistive technology up to 200 percent in a way that does not

require the user to scroll horizontally to read a line of text on a full-screen window.

Issue 13 Line spacing not a space-and-a-half

Example


Description

The vertical spacing between lines of text and paragraphs is too small.



Code used

CSS: body {

font-family: sans-serif; font-size: 62.5%; font-size-adjust: none; font-style: normal; font-variant: normal; font-weight: normal; line-height: 1.4;

}

p, pre, blockquote, label, ul, ol, dl, fieldset, address { margin: 1em 0; max-width: 50em;

}

Implications

Some users with vision impairments may have trouble following the text

Solution

Use the “line-height” and “margin-bottom” CSS properties to control the line spacing and set the spacing to be at least a space-and-a-half.

For example: p {

line-height: 150%; margin-bottom: 1.5em;

}

Alternatively supply a button that applies the above settings. This gives the user the choice of display.



Guideline 2.1 Keyboard accessible Make all functionality available from a keyboard

2.1.1 Keyboard Level A All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not. Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

Issue 14 Read an article page – ‘Help fix this text’ tool

Examples

‘Help fix this text’ functions

• Select a line of text to edit



• Discard changes

Description

Mouse users can hover over a line of text in the article and see a ‘help fix this text’ link then click on the link to use the feature.

Implications

Keyboard users including screen reader users cannot use this feature as they cannot highlight a line of text to bring up the ‘help fix this text’ button.

Once a line of text is selected there is a button to discard changes. This also cannot be accessed by a keyboard.

Solution

Enable keyboard users to use the editing feature by making the line highlight feature and discard changes button work for both mouse and keyboard.

Otherwise provide an alternative editing method that keyboard users can access.



Issue 15 Read an article page – select article from scanned newspaper

Example

Selecting an article from the newspaper image

Description

When mouse users hover over the scanned newspaper image sections of the page are highlighted to outline the different articles on the page. Then when the mouse user clicks on a highlighted section a small popup appears with the title of the article and a link to read the article.

Keyboard users cannot access these features.

Note

As the visual focus feedback in both Internet Explorer and Firefox is not very bold it is difficult to tell which items are attaining keyboard focus.

See 2.4.7 Focus Visible Level AA for more on this issue.

Implications

Keyboard users cannot access this feature so in order to read an article they have to select from the full list of articles shown in a frame on the left of the web page.



Solution

Provide the ability for keyboard users to highlight and select an article from the scanned image.

Otherwise, inform keyboard users how they can select articles to read.

2.1.3 Keyboard (No Exception) Level AAA All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.

Refer to issues under 2.1.1 Keyboard Level A



Guideline 2.4 Navigable Provide ways to help users navigate, find content and determine where they are

2.4.3 Focus Order Level A If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

Issue 16 Content not following the correct focus order

Example

Homepage

Description

The National Library of Australia logo image appears on the top-right of the website:

This logo shows that the Australian Newspapers website is produced by the NLA and the logo links to the NLA website.

In the code order this image is placed after the ‘Advanced Search’ link.

Screenshot showing how the page appears without CSS, and showing the code order of the content:



Code used <li> <a href="/ndp/del/search?adv=y">Advanced Search</a> </li> </ul> </div> </form> </div> <div style="position: absolute; top: 0pt; right: 0pt; padding-right: 7px;"> <a title="National Library of Australia and partners" href="http://www.nla.gov.au"> <img border="0" src="/static/ndp/images/nla_logo-header.gif"/> </a>

Implications

The focus order goes from top banner down to the search area, up to the top banner again then down to search area again. This is illogical.

Solution

Move the code for the NLA logo image so that it is just before the top navigation menu as follows:

(Simplified code with corrected alt tag)



<h1> <a href="/ndp/del/home"> Australian Newspapers <span>beta</span> </a> </h1> <div class="tagline">

Historic Australian Newspapers, 1803 to 1954 </div> <div> <img border="0" src="/static/ndp/images/nla_logo-header.gif" alt="National Library of Australia - logo" /> </div> <div class="nav">

<ul class="navbox">

Etc..

Note

Check for other instances of this issue such as the search tool in the search results page. In this instance the radio button options related to the search appear in the code after the search button therefore users may not discover these options before submitting the form.

Screenshot of the form with CSS disabled to show the incorrect focus order:

Issue 17 Content not following the correct focus order

Example

‘Lightbox’ style pop-up’s on article pages:



Description

These pop-up style effects do not retain the correct reading/focus order for keyboard users.

The content of the pop-up is located after the rest of the content in the page.

Implications

Keyboard users have to tab through the rest of the links in the page before they can access the links in the pop-up.

Screen reader users will not know that the additional content has appeared on the page.

Solution

Position the content of the pop-up in the HTML to appear directly after the link that loads it. This way all users access the content in the correct order.

2.4.4 Link Purpose (In Context) Level A The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.



Issue 18 Link not providing enough information

Example

Homepage

Description

The ‘Read this article’ link on the scanned newspaper image does not provide specific information of which article it will link to.

Code used <a href="javascript:showArticle(3998740, 470670, 3);">Read this article</a>

Implications

Users with poor visibility and screen reader users will not know which article they will be taken to if they click on the link.

Solution

Provide a text link of the article title on the page.

Issue 19 Homepage

Example

Day of the month in the calendar

Description

When a user hovers the mouse over a day of the month in the calendar, a tooltip appears that shows the user the name of the newspaper.



Code used <a href="/ndp/del/issue/88" title="The Sydney Gazette and New South Wales Advertiser">2</a>

Implications

Keyboard users cannot access this information so will not know the name of the newspaper unless they visit the page.

Solution

Add a feature in the calendar to allow keyboard users to see the full link information before they click on the number.

2.4.6 Headings and Labels Level AA Headings and labels describe topic or purpose.

Issue 20 Unclear article heading

Example

Article pages.

Description

The single article pages do not have a clear indication of where the article text starts.

Screenshot showing the ‘view entire page’ page article section with headings highlighted on the page. The article heading is correctly tagged as a heading:



Screenshot showing the single article page article section. The same article heading is not marked up using a heading tag:

Implications

It isn’t clear for users on the single article page which is the heading of the article. In addition to this, the heading “Electronically Translated Text” isn’t very clear that this is the start of the article.

Solution

Include the article heading on the page marked up with a heading tag. It may also be useful to say “Electronically Translated Article” rather than text – the issue being screen reader users are likely to look for ‘Article’ for the start of the article text.

Additional Note

Instances of ‘Sign Up’ on the site are misspelled ‘Signup’. This creates confusion, particularly for screen reader users as this not make sense when announced as one word. Therefore, ensure all instances are corrected to include a space between the two words.



2.4.7 Focus Visible Level AA Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

Issue 21 Keyboard focus not visible

Example

Article page

Description

The ‘search articles’ button and the ‘previous’ and ‘next’ arrows do not have any visible keyboard focus:

This image shows the keyboard focus around the ‘about’ link. This is sufficient to meet the requirement of this success criterion:

Implications

Keyboard users will not know where the keyboard focus is on the page and will find it difficult to use these buttons.

Solution

Ensure these elements have a clear keyboard focus indicator. For instance, the ‘ ‘search articles’ button colour can change using the CSS properties.

The arrow image can also change colour on focus – this image should not be included as a background image. Include the image within the link and provide alternative text for it as follows: <a class="prev" onclick="gopage(483240); return false;" href="/ndp/del/page/483240"><img src=”/static/ndp/oxideDesign/img/template/arrows.gif” alt=”Previous issue”></a>



Notes

The focus indication on the site depends on the default browser keyboard focus indicator that is a thin dotted line around the element, these can be hard to spot. It would be useful to provide clearer focus indicators where possible.

2.4.8 Location Level AAA Information about the user's location within a set of Web pages is available.

Issue 22 No identification of where a user is in the website

Example

Site wide.

Description

Although this website doesn’t have deep levels of navigation it is useful to provide identification of where they are in the site.

Implications

A user may not understand how to get around the website and they may not know where they are.

Solution

Add at least one of the following to the site to aid navigation:

• Site map

• Breadcrumb navigation

• Indicate the current location within the navigation menu by distinguishing it from the other links. For example this can be done by changing the background colour.



2.4.9 Link Purpose (Link Only) Level AAA A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general.

Screen readers can generate a dialog box listing all the links on a page. Users then access the links via the dialog box as a means of quick navigation. For this reason it is important that link text is descriptive and does not rely on the surrounding content to make sense (for example, do not use "click here" and "more" as link text).

In addition, do not use:

• URI's as link text as they are not announced well by screen readers.

• Link text that do not include format and size information when the destination is a non-HTML format (e.g. PDF).

Note that the 'title' attribute in links cannot be used to supply information to screen reader users because screen readers generally do not announce link titles.

Issue 23 Links not making sense out of context

Refer to 2.4.4 Link Purpose (In Context) Level A

Implications

Screen reader users who use a links dialog box or tab from link to link do not know where the links points.

Solution

Use descriptive link text to make links make sense when taken out of context of the rest of the web page.

2.4.10 Section Headings Level AAA Section headings are used to organize the content.

Note 1: "Heading" is used in its general sense and includes titles and other ways to add a heading to different types of content. Note 2: This success criterion covers sections within writing, not user interface components. User Interface components are covered under Success Criterion 4.1.2.

Issue 24 Heading not marked up as a heading

Refer to 2.4.6 Headings and Labels Level AA



Guideline 3.1 Readable Make text content readable and understandable

3.1.4 Abbreviations Level AAA A mechanism for identifying the expanded form or meaning of abbreviations is available.

Issue 25 Abbreviations used on calendar

Example

Homepage

Description

The calendar links use abbreviations for the days of the week:

Implications

Abbreviations may confuse users who cannot decipher what information is displayed.

Solution

Provide a clear explanation of the information. Also, use two letters instead of one for the days of the week such as TH for Thursday.

For example: <th>TH</th>

It is also recommended that a table summary be included.

For example: <table summary=”A calendar containing the days of the selected month. Each date of the month is contained in a column under the day of the week it falls on. Click on a number that is a link to view a random newspaper from this date.” class="calendar days disabled">



3.1.5 Reading Level Level AAA When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.

Issue 26 Reading level too high

Example

Help page (http://ndpbeta.nla.gov.au/ndp/del/searchTips)

Description

This page contains text that has a grade level of 11.5 on the Flesch-Kincaid reading grade level scale for measuring text readability. This measurement was taken with the reading level tool in Microsoft Word.

Implications

Users with cognitive disabilities can have difficulty in reading and understanding the content.

Solution

Use any of the techniques suggested by WCAG to make the text more readable:

• Ensure text has Grade level 9 or lower reading level

• Supply text summary that has Grade level 9 or lower

• Supply visual illustrations that explain the content

• Supply spoken version of the text

• Supply sign language version



Reading grade level

The reading level can be tested in Microsoft Word. Ensure that "Check grammar with spelling" and "Show readability statistics" are checked in the Options dialog box.

Perform a spell check (F7 button) and dismiss the spelling correction suggestions. When spell checking is completed, a dialog box displays the reading level:

Reference on reading level tools:

Which readability testing tool should we use? (deyalexander.com/publications/readability-testing.html)

Note

Reading level measuring tools can give a good indication of the reading level rather than a precise measurement. It is more important to bring the reading level close to 9 (say 9.88) rather than making it 9.0 instead of say 9.20.



Guideline 3.2 Predictable Make Web pages appear and operate in predictable ways

3.2.2 On Input Level A Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component.

Issue 27 Read an article page

Example

Dropdown box to select page number:

Description

The page number drop down menu uses the onchange JavaScript method to update the page when a user selects an option. Keyboard users browse a drop down menu such as this one by using the down and up arrow keys. The JavaScript activates the first time a keyboard user changes the option by hitting the down arrow key, and prevents them from selecting another option.

Code used <select onchange="gopage(this.value);" name="id">

Implications

Keyboard only users will have trouble selecting an option.

Solution

Instead of using the onchange JavaScript method, include a “Go” button beside the drop down menu that activates the change when a user hits it.



Guideline 3.3 Input assistance Help users avoid and correct mistakes

3.3.1 Error Identification Level A If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.

Issue 28 Insufficient error suggestion provided

Example




Description

The error message on this form is insufficient as it only mentions the Terms of Service error.

Implications

Users with a vision impairment may find it hard to work out which fields they haven’t completed.

Solution

Include a list at the top of the form of all fields that have errors or need to be completed.

3.3.2 Labels or Instructions Level A Labels or instructions are provided when content requires user input.

Issue 29 Instructions and expected data not given before form

Example


Description

The ‘Sign up’ form has instructions to assist users to complete the form correctly. These instructions are positioned after the form input fields.

Implications

Screen reader users will not be given the information before the relevant form field and may not understand how to complete the form correctly.

Solution

Provide the instructions before the input fields.



Issue 30 Insufficient assistance provided for CAPTCHA

Example


Description

The audio CAPTCHA link does not provide sufficient instructions to enable users such as screen reader users to understand how to use it.

For example, in testing on the consultant’s PC the link to the audio CAPTCHA opened the audio file using QuickTime in a new page and the file started to play automatically. The controls of the QuickTime player was not accessible by a keyboard and not all of the letters announced count be identified correctly. It took 3 plays to identify all the letters. The 6 letters had to be remembered after this in order to go back and complete the relevant form field. During further tests the audio file did not play in full meaning only one or two letters were announced. On returning to the form on the previous page the two password fields that had been completed were empty.

During screen reader testing on a different PC, the link launched another audio player to play the file. When Windows Media Player was used to play the audio the screen reader announced over the entire audio file. When the user attempted to pause the screen reader as quickly as possible when the audio file started, it was still difficult to understand what letters were being announced and it was a long slow process to try to complete the task. The task was eventually abandoned.

Implications

Users may not understand how to use the feature and may not then be able to complete the form.

Solution

Further detailed instructions are required to enable users to use this feature. As it is extremely difficult to remember the 6 characters and figure out how to play the audio file and then return to the form it is likely to be very beneficial to provide live assistance on the page or via email or telephone.

3.3.3 Error Suggestion Level AA If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.



Issue 31 Insufficient error suggestion provided

Example


Description

Error suggestions are not provided for this form. For example, if an email address doesn’t have an ‘@’ symbol in it.

Implications

Users with a vision impairment may not understand what they have entered incorrectly.



Solution

Include suggestions where applicable with error messages. For example, the email field could alert users if they have not included an ‘@’ symbol in the email address.

3.3.5 Help Level AAA Context-sensitive help is available.

Issue 32 Instructions and expected data not given before form

Refer to 3.3.2 Labels or Instructions Level A



Guideline 4.1 Compatible Maximize compatibility with current and future user agents, including assistive technologies

4.1.2 Name, Role, Value Level A For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

Issue 33 Shaded table cells used to communicate newspaper coverage

Example

About (ndpbeta.nla.gov.au/ndp/del/about)

Description

Shaded table cells are used to communicate newspaper coverage.

Implications

Screen reader users, and users who have trouble following the table cell to table column header may have trouble comprehending the coverage dates.

Solution

Include an alternative text version of this table. Include the coverage dates as text in this table.



For example:

The Maitland Mercury,... 1840 to 1853, 1880 to 1884

The Sydney Gazette and... 1803 to 1843

national library of australia australian newspapers

Documents