This report aims to establish accessibility issues within The Lowry website. Accompanied will be recommendations that the organisation would benefit from utilising within their website, and examples of technical solutions.
The Lowry is a modern gallery and theatre complex, situated within Salford Quays in the North of England. It is primarily famous for housing a 2000m² gallery, which contains 350 paintings by the artist L. S. Lowry. Its online presence is located at the web address www.thelowry.com. Visitors to the site can register an account, purchase tickets to shows, and browse information regarding various amenities.
The Lowry is a dynamic, database-driven website and therefore it relies on numerous users inputting and editing content on multiple pages. However, this can cause interoperable problems as the website’s accessibility is likely to decrease as the site is modified.
Within the UK alone, 14% of the population are registered as disabled (OXLink: 2008). Accessibility affects persons who may be blind, deaf or have physical disabilities. Often overlooked, issues can affect the elderly, as well as those who suffer from learning difficulties. Collaboratively, this community combines an annual spending power of approximately £80 billion (Department for Work and Pensions: 2006).
Within the UK, the Disability Discrimination Act (1995) makes it unlawful to discriminate against disabled persons in relation to facilities and services (such as The Lowry website). Using the Web Accessibility Initiative’s (WAI) Web Content Accessibility Guidelines 2.0 (WCAG), the website was tested in the areas of general accessibility, visual, hearing and physical disability, neurological and learning conditions.
The results indicated that the site failed to reach complete WCAG Priority Level 1 (A) compliance across all categories bar hearing. Currently there are numerous accessibility issues with The Lowry website relating to assistive technologies (special devices for disabled users to browse the site), and the use of obsolete web languages. The website has an archaic site design, navigational problems and issues relating to page comprehension and accessibility.
For an organisation that takes pride in offering facilities to disabled users within its theatre, it comes as a surprise that The Lowry has neglected its responsibility in creating an accessible website. Web standards have progressed dramatically, yet the website still contains depreciated coding semantics and inaccessible web scripting languages.
Making a website wholly accessible is not a simple task, and involves both knowledge and training within an organisation. However, the benefits are numerous – not only will The Lowry be responding to an ethical practice, and omitting the risk of legal action, there are also financial incentives.
Making a website more accessible can improve its technical performance. For example, it can reduce server load, an important factor for a high-traffic website like The Lowry. In turn, this has added financial benefits in the reduction of bandwidth needed to facilitate the website. Reduced development and maintenance costs can also be obtained by implementing accessibility features. By adhering to new developments and making the website accessible, The Lowry website will become future proof.
Web accessibility is a social responsibility for The Lowry – one that if adhered to, will create a positive public image. Accessibility improvements will also bring usability benefits. Browsing the website will become a more pleasurable experience, increasing the likelihood of people re-visiting the site and recommending it ‘virally’ to their friends. Promoting and championing web accessibility can also have a positive impact on employees of the organisation, as well as investors and collaborators. A new initiative would display The Lowry’s commitment to providing equal opportunity for its staff, customers and visitors.
If The Lowry improves its website architecture it will appear higher in search engine results – in turn driving more traffic to the site. A rise in visitors will see a projected increase in online shop sales. Demand for theatre tickets is also likely to rise. This is very important as The Lowry only receives a 16% public subsidy and relies on these sales in part, to fund the organisation. It is therefore crucial that disabled users are not alienated in the process of browsing events. Currently, some users are restricted from purchasing tickets as they cannot access the user login facility.
If the Lowry website conforms to Level 2 Priority (AA) under the WCAG 2.0 guidelines, then it is highly unlikely that the organisation would be liable for prosecution under the DDA. Guidance towards reaching Level 2 can be found in Section 4. Website Recommendations.
Organisations such as The Lowry should adopt a holistic approach to web accessibility. By integrating accessibility into its web site development, the organisation will be better prepared to deal with current issues and any future ramifications.
Accessibility is about making websites more perceivable, operable and understandable. This rationale presents information on current web accessibility guidelines and legislation, and how these relate to persons with disabilities who will be viewing The Lowry website. It also outlines the methodologies used to evaluate the website, specifying tests that will be carried out under various disability categories.
The World Wide Web Consortium (W3C) is the leading standards organisation for the World Wide Web. The W3C’s Web Accessibility Imitative (WAI) has five primary areas of interest: technology, guidelines, tools, education and research. The WAI is responsible for publishing the Web Content Accessibility Guidelines (WCAG), which provides guidance to web designers and developers in regard to making web content accessible to all.
"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." -- Tim Berners-Lee, W3C Director
The most recent guidelines (published in December 2008) are WCAG 2.0. This document is available to all and is structured into three levels of priority: A, AA and AAA. Although there is a lack of legal precedence surrounding web accessibility – many leading figures argue that websites should achieve Priority 2 (AA) compliance.
“Priority 2: Web developers should satisfy these requirements, otherwise some groups will find it difficult to access the Web content. Conformance to this level is described as AA or Double-A.”
Within the UK, the Disability Discrimination Act (DDA) seeks to prevent discrimination against disabled persons. Although the act does not specifically address website accessibility, there is strong evidence to suggest that it could be applied to, and referenced in legal action taken against a website.
To improve accessibility, it is important to state in depth the existing issues that The Lowry needs to respond or improve upon. Reasonable adjustments to the website should be made as a policy of inclusion not exclusion.
A common mistake in relation to accessibility is that it only affects people who suffer from physical disabilities. This however, is a statement far form the truth. In an age where communications devices are converging, and internet content is being displayed on numerous devices, such as PDAs, mobiles phones, and via TV sets, it is important that markup languages are valid and efficiently coded. Therefore it is important that web developers are user agent agnostic and do not rely on users accessing content the same way. As a result of this, it is important that The Lowry is functional in all web browsers and across multiple operating systems.
The central focus however, is on the audience that may be browsing the website. They may suffer from reduced mobility or dexterity difficulties. They may be blind, or have vision impairments or disorders such as colour blindness. The nature of The Lowry means that its target audience is more likely to be elderly and therefore have an increased likelihood of suffering from these ailments. Therefore, the organisation’s website accessibility strategy must be of high importance.
Statistics are an effective way to evidence the serious consequences that an inaccessible website may have on the audience:
· 8.6 million people (14% of the UK) are registered as disabled (OXLink: 2008)
· Within the UK, there are 1.6 million people who are registered as blind, and 4% of the population have vision problems (RNIB: 2008)
· 3.4 million people have disabilities that prevent them using a standardised mouse, keyboard or monitor (OXLink: 2008)
· 8 million people suffer from a hearing detriment or loss (Monmouthshire Hearing Center: 2007)
· 1.5 million people have a form of learning disability (Mencap: 2008), and over 7 million have problems relating to literacy (Carelink: 2006)
It is important to acknowledge and understand the varying conditions faced by disabled users and how they will adapt and interact with The Lowry website. The internet is pre-dominantly a visual medium and therefore designing for those who have vision impairments or are completely blind is vitally important. Persons with mobility impairments such as those who suffer from cerebral palsy or arthritis rely on assistive technologies such as specialist trackball mice or other alternate switching devices. Those that suffer from auditory impairments have traditionally had accessibility problems in regard to multimedia applications within websites, and rely on captioning to follow the narrative of a video.
To carry a thorough testing evaluation of the website, it is imperative that assistive technologies are used, combined with automated testing tools and manual user testing.
Assistive technologies are pieces of specially designed hardware or software that are used to assist and convey a natural web browsing experience for disabled users. Examples of such tools include screen readers and screen magnifiers. Screen readers convert text on a monitor screen into a synthesised audible output - giving descriptions of visual elements on a webpage.
It is also crucial that manual evaluation testing occurs, as automated methods, such as W3C’s Validation tools are only amenable to a small section of the WCAG accessibility guidelines. They cannot analyse semantics, and therefore human judgement via user testing is imperative. To increase the accountability of this report, two students who suffer from both physical and neurological disabilities were invited to help evaluate The Lowry website. This is because it is impossible to recreate or replicate these conditions to a realistic degree of accuracy without suffering from them personally.
Rebecca Dommett
Undergraduate English Literature student (University of Leicester)
Conditions: Dyslexia, Dyspraxia, Scotopic Sensitivity Syndrome
Kirsty Edwards
Undergraduate Computer Science student (University of Hertfordshire)
Conditions: Motor impairments (use of trackball assistive mouse)
Automated testing tools used:
· W3C Validator from WC3 · (http://validator.w3.org)
· BrowserShots from Browsershots.org · (http://www.browsershots.org)
· Functional Accessibility Evaluator from University of Illinois · (http://fae.cita.uiuc.edu)
· WAVE 4.0 (BETA) from WebAIM · (http://wave.webaim.org)
· Web Developer Toolbar by Chris Pederick · (http://chrispederick.com/work/web-developer)
· Readability Test from Juicy Studio · (http://juicystudio.com/services/readability.php)
· Contrast Ratio Calculator from MSF&W · (http://www.msfw.com/accessibility/tools
· Colour Blindness Simulator from etre ltd. · (http://www.etre.com/tools/colourblindsimulator)
Assistive technologies used:
· JAWS 10 (BETA Demo) from Freedom Scientific · (http://www.freedomscientific.com/jaws-hq.asp)
· Fire Vox by Charles Chen · (http://firevox.clcworld.net)
· Screen magnification · In-built Mac OSX tool
· Trackball Mouse used by User Tester
As the website has a high amount of content, only the necessary webpages will be evaluated for accessibility. These pages represent the most popular activities that site visitors will use. They involve information retrieval, user registration, and the e-commerce aspect of purchasing event tickets and items from the shop.
The findings were organised into scope (how many webpages had accessibility issues) and the impact (Very High, High, Medium, Low) that these problems would have on a disabled user browsing the site. Each finding is also matched to the appropriate WCAG 2.0 Guideline so it can be cross-referenced using the chart in Section 7.2. WCAG 2.0. Guidelines.
Positive Findings:
Website is operable with CSS disabled
Displays correctly in major web browsers and across Windows, Mac and Linux operating systems
A descriptive TITLE element is used effectively for each individual webpage
Every webpage contains a DOCTYPE declaration to facilitate validation
Over 90% of webpages set the default language using the lang attribute on the html element
Over 95% of webpages specify the character encoding with a html/head/meta element using the content attribute
Negative Findings:
3.1.1. Fails HTML and CSS validation
Scope: Entire Website · Impact: High · WCAG 2.0 Guideline(s): 4.1.1 (A)
- Tested using the W3C Validator, FAE, and WAVE 4.0, the website’s coding fails to conform to the correct validation standards, with numerous errors found. See Appendix – Figure 7.1.1.
3.1.2. Key site features unusable when JavaScript is disabled
Scope: Register/Login Pages · Impact: Very High/High · WCAG 2.0 Guideline(s): 2.4.5 (AA)
- Users cannot login to their account unless they have JavaScript enabled. This is a serious accessibility issue as it restricts users from accessing content.
- The calendar on the site, a key feature for users to search and browse when performances are on is inoperable without JavaScript. The image map on the Floor Plans page also requires JavaScript to open an external window.
Scope: Some Pages · Impact: Low · WCAG 2.0 Guideline(s): 2.4.5 (AA)
- The sub-menu navigation on some pages contains a ‘Back’ link that also requires JavaScript. Not being able to use this feature is unbeneficial for the navigational flow of the website.
3.1.3. Important webpages missing
Scope: Entire Website · Impact: Medium · WCAG 2.0 Guideline(s): 3.3.2 (A)
- There is no accessibility or sitemap page on the website.
3.1.4. Depreciated coding
Scope: Entire Website · Impact: High · WCAG 2.0 Guideline(s): 4.1.2 (A)
- Tables have been used to create the website’s layout. CSS should be used instead as the use of tables should be restricted to organising data in rows and columns.
- Numerous depreciated tags were found throughout the website. These include align attributes, and < center > elements.
- Some < p > and < div > elements were found to not be correctly nested and closed on some pages.
3.1.5. Unnecessary use of animation
Scope: Homepage and Entire Website · Impact: Medium · WCAG 2.0 Guideline(s): 2.4.6 (AA) | 2.4.5 (AA)
- Banner and other headers embedded in Flash provide no considerable benefit to the user.
- There is no alternative provided for those browsing without a Flash Player plug-in. See Appendix – Figure 7.1.2.
3.1.6. Site navigation and comprehension
Scope: Some Pages · Impact: Very High/Medium · WCAG 2.0 Guideline(s): 3.2.3 (AA)
- When browsing the site in Mozilla Firefox with images disabled, the button image links to important pages such as booking tickets are not displayed. This is critical as it may decrease the amount of users who are likely to click through and buy tickets. See Appendix – Figure 7.1.3.
- Inconsistent e-commerce strategy may confuse some users. Tickets are being sold via an external website (Quay Tickets) that are available to be purchased directly on The Lowry’s own website.
- Website homepage is too long, and content should be minimised. See Appendix – Figure 7.1.4.
Positive Findings:
Consistent visual presence kept throughout the website using CSS
All text on the website can be re-sized by a web browser or user software
Does not present information using colour alone
Fluid three-column layout conforms to user’s screen resolution
Site images remain comprehensible when tested under protanopia, dueteranopia and tritanopia colour blindness conditions
Text contrasts well against background colours throughout
Majority of hyperlinks have a context description
Size of form input boxes is adequate
Site works well with magnification assistive tool
Negative Findings:
3.2.1. Navigation, layout and screen reader issues
Scope: Entire Website · Impact: High · WCAG 2.0 Guideline(s): 1.3.1 (A) | 2.4.1 (A) | 2.4.4 (A) | 3.2.3 (AA)
- < ol > or < ul > tags are not used for the navigational links which may confuse screen readers.
- There is no hidden ‘skip to content’ link, which means a screen reader has to read out the navigation links for each webpage. This could easily alienate and frustrate users browsing the site.
- Some hyperlinks do not contain a description, e.g. click ‘here’ is used on the Quay Tickets page .
- Different layout used for shopping basket section of the website breaks visual consistency and may confuse some users. See Appendix – Figure 7.1.5.
3.2.2. Document linearisation issues
Scope: Some Pages · Impact: High · WCAG 2.0 Guideline(s): 1.3.2. (A) | 1.3.1. (A)
- Some features like the calendar do not display well when linearised. See Appendix - Figure 7.1.6.
- Deeply nested tables are used throughout the site. This can cause problems when the pages are rendered in a linear mode (e.g. by a screen reader).
3.2.3. Forms
Scope: Some Pages · Impact: High · WCAG 2.0 Guideline(s): 1.1.1 (A)
- 21 of the 25 pages that use forms do not have a < label > element either through encapsulation or id reference. Evidence of this inconsistent markup can be seen in the ddlMonthSelector form which doesn’t contain a < label >.
- A dropdown menu < option > must be selected by default.
3.2.4. Images and scripting
Scope: Entire Website · Impact: Medium · WCAG 2.0 Guideline(s): 1.1.1 (A)
- Over one third of all pages contain images that do not have an alt attribute.
- The descriptions on some pages are repetitive and are not wholly representative of the image – therefore frustrating those reliant on a screen reader. See Appendix – Figure 7.1.7.
- The arrows next to each navigation link contain < img > elements used for stylistic purposes. CSS techniques should be used instead so the image doesn’t have to be rendered multiple times.
- The font used for image buttons and the header does not have legible kerning, and also appears pixelated and compressed. This is an accessibility issue as the text cannot be resized and could be illegible to some users. See Appendix – Figure 7.1.8.
- The element for the image map on the Floor Plans page does not contain an alt attribute.
- Pages that contain the < applet > and < embed> elements have no alt text.
3.2.5. CSS issues
Scope: Entire Website · Impact: High · WCAG 2.0 Guideline(s): 1.3.1 (A) | 4.1.2 (A)
- No webpages contain a < h1 > tag, and over 95% of pages do not contain any header elements. These are useful to have so that screen readers and other devices can clearly see the content structure of the website. They are also beneficial to site architecture and search engine optimisation.
- The depreciated color attribute is used throughout the site to specify the colour of HTML elements. < font > and < b > elements were also found. These inline style elements should be declared via CSS so a consistent visual appearance can be kept throughout the site.
3.2.6. Multimedia content
Scope: Entire Website · Impact: Medium · WCAG 2.0 Guideline(s): 2.4.5 (AA)
- The animated banner prevents a user from clicking the logo back to the homepage until the animation transition has finished. This could frustrate users who wish to follow the orthodox method of clicking the logo to return to the homepage.
Positive Findings:
Verification is used on the login page to indicate a user they have left a field blank or their details are incorrect
Text readability is generally good with a 6.25 average Fog Index score
Identification elements such as buttons remain constant throughout
Text is legible throughout site
No distracting audio or video content
Animated content (banner) transitions are not rapid enough to inflict a seizure
White text on blue background is used for some site headers and for hovered hyperlinks – this improves readability and focus for dyslexic users
Clear print and plain English guidelines are followed consistently
Negative Findings:
3.3.1. Verification missing
Scope:: Some Pages · Impact:: Medium · WCAG 2.0 Guideline(s): 3.3.1 (A) | 3.3.3 (AA)
- The user is not presented with information such as ‘no results found’ when searching content. If there is no data to show, the page is left blank. If a user does not fill in the search field, they are not made aware of their error – instead a small asterix appears next to the input box. This is not an effective method as it is unhelpful to users with language perception difficulties.
3.3.2. Difficult language and perception issues
Scope:: Some Pages · Impact:: Medium · WCAG 2.0 Guideline(s): 3.1.5 (AAA) | 1.3.2 (A)
- Some complex language is used on pages such as the history of LS Lowry webpage – as evidenced by the page having a 9.36 Fog Index score (10 is the equivalent of TIME Magazine). Complicated language may cause problems for users who have literacy difficulties.
- The < u > element is used for non-hyperlink text. This will be confusing to users who rely on standardised web design features and may mistake the text for a link.
3.3.3. Page contrast issues
Scope:: Entire Website · Impact:: Medium · WCAG 2.0 Guideline(s): -
- Black text on a white background is used throughout site. Although this contrast is beneficial for a large majority of users, those suffering from Scotopic Sensitivity Syndrome will have trouble focusing and prefer to have a darker coloured background (preferably blue).
Positive Findings:
Pages offer sub-menu links effectively by utilising a secondary navigation panel
Tabbing works logically for keyboard users
The onclick attribute is not used on elements that cannot accept keyboard focus
Negative Findings:
3.4.1. Navigation and orientation
Scope: Entire Website · Impact: High · WCAG 2.0 Guideline(s): 2.4.3 (A) | 2.1.1 (A) | 2.4.1 (A)
- There are too many main navigation links which could be overwhelming to a user. They are also misaligned when viewed in Internet Explorer Version 5 or below. See Appendix – Figure 7.1.9.
- The trackball user testing reported that the navigation links were presented too close together. This is awkward for mouse input users with dexterity difficulties, as they will have trouble clicking the necessary link.
- There are no hidden navigation links and the user has no ability to bypass blocks of content.
Positive findings:
The majority of the site contains clear and simple language
No distracting or non-content related visual stimulus
No video or audio content was found on the website. However if these features were to be implemented in the future, then see the advice and recommendations given in Sections 5.2. Resources to Enhance Accessibility and 7.2. WCAG 2.0. Guidelines.
These recommendations are categorised under the impact they were awarded in Section 3. Website Design Accessibility Issues. It would be beneficial for the site if all recommendations were responded to, however the Very High and High Priority issues should be taken into more serious consideration. This is because currently The Lowry website is severely out-dated and lacking standardised accessibility practices. The absence of these features is preventing disabled users, and those reliant on assistive technologies to browse the website in an efficient, enjoyable and productive manner.
4.1.1. Validate website HTML and CSS
Remove all depreciated coding tags so that the website validates to W3C standards. This will also bring the benefit of increased browser interoperability and webpage load performance.
4.1.2. Use CSS instead of tables
The site layout should immediately be re-designed using CSS to control the presentation of the website. With the exception of displaying tabular data, using tables to present content is an obsolete technique.
4.1.3. Offer JavaScript alternatives
It is critical that the user registration and login forms are re-designed (using a server-side script) as well as other features of the site, such as the calendar where operability is reliant on JavaScript.
4.1.4. Re-design navigation
The site would benefit from narrowing down the amount of navigation options presented to the user. One way to achieve this would be re-coding the navigation bar to create a drop-down navigation. < ol > or < ul > element tags should also be implemented so the navigation structure becomes clearer.
4.1.5. Make the website screen reader friendly
A hidden ‘skip to content’ facility should be implemented into the site. This allows users with a screen reader to move to the content of a page, without the device having to read main or sub-menu navigation links for each individual page.
>4.1.6. Implement ALT tags
Text descriptions must be present for every image on the website, as well as other < area >, < applet > and < embed > elements. Null alt tags can be used for stylistic or decorative images, and the longdesc attribute must be applied to more complex images.
4.1.7. Format forms correctly
Make sure all forms have an id reference and a < label > element.
4.1.8. Replace image buttons with text
Remove all image buttons, and replace them with a CSS-styled background and standard text. This means that a user can easily re-size the text to their needs, and important links are not missed by users browsing with no image support.
4.1.9. Clear information for link destinations
Ensure every hyperlink has a relevant description, so a screen reader can process the information effectively. Link text should not be vague, and language that contains spatial or visual reference should be avoided. Also make use of the title attribute when creating hyperlinks. All body text should also be styled so it is easily differentiated from hyperlinks.
4.2.1. Implement alternative high-contrast stylesheet
Offer an alternative stylesheet (via a CSS style switcher) for users who suffer from vision impairment.
4.2.2. Create access keys
Create access key shortcuts for the navigation to allow a user to browse the site more efficiently using a keyboard.
4.2.3. Allow the bypassing of content blocks
Offering internal link anchors allows users to skip straight to content or to navigate to the top of the page.
4.2.4. Increased verification for search queries
Incorporate more advanced verification for search fields that provide a text description. If possible this should be via a server-side technique, and must contain clear comprehensible language and instructions.
4.2.5. Format tables correctly
Each data table must incorporate < th > elements for the first cells of all columns or rows. Each td element in a complex data table must also have a header attribute that references the id attributes.
4.2.6. Reduce language complexity
Make sure text content throughout the site is readable for a high majority of literacy levels, and scores no higher than 8 on the Fog Index scale.
4.2.7. Adjust animated content
Produce a homepage link alternative for those who do not have the Flash plug-in. Also re-design the text transitions to be slower – remember that dyspraxic users read text 25% slower on a computer.
4.2.8. Inbuilt text-resizer
Create an embedded text-resizer. This is a useful accessibility tool for users who are unaware or unable to re-size text via a web browser.
4.2.9. External links
Spawning secondary windows is not supported in some user agents and can cause spatial disorientation for blind users using a screen reader. It is best to avoid opening a new window but where this is not possible, warn the user that the content (or an externally linked website) will open in a separate window.
4.3.1. Progression from HTML 4.01
The DOCTYPE of the webpages should be changed from HTML 4.01 to XHTML Transitional 1.0. This is a more recent version that means the website will continue to be rendered by future browsers in the correct fashion whilst sustaining a higher level of accessibility.
4.3.2. Create sitemap webpage
The creation of a sitemap will allow users to be able to view the navigation sequentially and also aids quick information retrieval.
4.3.3. Create accessibility webpage
An accessibility page would be beneficial to users wanting to discover the accessibility features and strategies that The Lowry have implemented into the website. It also allows for feedback from disabled users on their experiences with the site. From this, a database of accessibility testers can be created to help report or give advice on future website developments.
4.3.4. In house style guide
The creation of an in house style guide will ensure that accessibility standards are introduced across the whole website. It is also beneficial for branding the website visually and keeping site aesthetic consistent throughout.
4.3.5. Promote accessibility
Accessibility features should be made apparent to users visiting the website. If a user can see that the site is accessible to all, The Lowry will continue to be seen as an ethical organisation that cares for its visitors.
4.3.6. Re-develop strategy and policy
Raise awareness of accessibility issues relating to the website and provide formal training for staff that are connected to the management, maintenance and contact sectors of the website.
4.3.7. Web Development and user testing
Hire external web developers or train the current web development team on the importance of having a valid and accessible website. The software used to create the webpages should conform to Authoring Tool Accessibility Guidelines. When the site has incorporated accessibility features – host focus groups where disabled users can test the website, allowing developers to see issues that directly affect human judgement.
4.3.8. Gain accreditation
It would be beneficial to gain verification from disability organisations and charities, such as the Royal National Institute of the Blind’s See It Right campaign .
4.3.9. Follow W3C WCAG updates and PAS78
It is important that the developers of the website keep abreast of WAI guidelines, as WCAG are continually being updated . Before it disbanded, the Disability Rights Commission (DRC) commissioned the production of a Publicly Available Specification (PAS). This document outlines good practice in the creation of websites that are both accessible and usable by disabled people, (Box: 2006)
The PAS78 document is also useful to web commissioners, as it reinforces the business case of accessibility, and introduces accessibility into the early stages of the development cycle. It also stresses the importance of user testing and the maintenance and evaluation of accessibility solutions.
This section contains examples of corrected markup that can be implemented into The Lowry website to improve accessibility. It also contains useful accessibility literature and resources that will be beneficial for future accessibility developments and maintenance on the site.
5.1.1. Hyperlinks
Current Incorrect Markup:
Revised Correct Markup:
Giving a description of the link destination helps users who are using a screen reader, as they are informed exactly where next they can browse to.
5.1.2. Text Equivalent for images
Current Incorrect Markup:
Revised Correct Markup:
Providing an alt description for images also benefits screen readers and those viewing the site on a browser with no image support or with images disabled. Adding the dimension of images will help the browser to render the image faster. The border tag has also been removed as it should be styled via CSS using a class.
5.1.3. Forms
Current Incorrect Markup:
Revised Correct Markup:
The tables have been removed, as well as the depreciated align and border attributes. The Password field has been given a label tag to help describe it. < fieldset > has been used to group the form fields together. This is beneficial to screen readers as the fields are grouped logically. Studies have shown placing text to the left of input fields imposes a cognitive workload on users. Therefore, placing labels above input fields is preferable and therefore the code has been altered to conform to this (Penzo: 2006).
5.1.4. Opening New Windows
Although ideally it should be avoided, if a new window does need to be opened then there is an alternative method which is operable for users without JavaScript.
Revised Correct Markup:
5.1.5. Colour Contrast
Colours should be declared in the stylesheet in pairs to ensure that a foreground colour has an accompanying background colour.
5.1.6. Navigation and Access Keys
Current Incorrect Markup: