Website Accessibility Auditing Eoin Campbell, Technical Director, XML Workshop Ltd.

Website Accessibility Auditing

Eoin Campbell, Technical Director, XML Workshop Ltd.

29 July 2004 © 2004 XML Workshop Ltd. 2

What We Do

• Design, develop and maintain websites

– Eg. Teagasc, Dept. of Enterprise, Trade and Employment

• Develop software and services to maintain accessible websites

– YAWC – Yet Another Word Converter

• Offer electronic publishing consultancy for print and online publications

– E.g. NALA, Davy Stockbrokers, NDA


Why Audit Website Accessibility?

• To establish a base status: assess whether website is accessible, and identify any areas of non-compliance

• As an acceptance test: to assure quality of delivery from a 3rd-party developer

• As a benchmark: to compare current website status against previous or future audits, and measure changes over time


Aspects of Accessibility

• Subjective, site-specific, 'soft' issues

– Graphic design

– Information architecture and navigation

– Quality of language and writing

• Objective, site-independent, 'hard' issues

– Use of HTML markup


What to Audit?

• Audit both subjective and objective issues in an initial assessment of a website

• Audit objective issues for a final acceptance test or benchmark

• Audit subjective issues before accepting a design prototype


Internal or External Auditors?

• Internal auditors

– Lack objectivity (and maybe) credibility

– Few staff have required range of skills, especially for subjective issues

• External auditors

– Dedicated staff, more experience, deeper expertise

– Credible, objective, efficient


Specialist Accessibility Service Companies

• XML Workshop Ltd. (www.xmlw.ie)

• NCBI-CFIT (www.ncbi.ie)

• Frontend (www.frontend.com)

• Ennis Information Age Services (www.eias.ie)

• Open Interface (www.openinterface.ie)


Auditing Stages

• RFT, scope definition, cost quotation, choose vendor, etc.

• Define tests and select primary target pages

• Audit website and compile draft report

• Issue draft for review and feedback

• Revise and present final report

• Identify issues and decide on further actions


Definition of Tests

• Web Content Accessibility Guidelines (WCAG), version 1.0, 1998

– World-Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)

– De facto world standard, accepted by most governments

• Referred to by Irish Government Web Publishing Guidelines, and NDA IT Accessibility Guidelines

• Each guideline is categorised by priority


WCAG Guideline Statistics

• Total of 65 checkpoints

• 3 priority levels

– 16 Level/Priority 1 (A) - Essential

– 30 Level/Priority 2 (AA) - Recommended

– 19 Level/Priority 3 (AAA) - Desirable


Types of Checkpoints

• Some checkpoints can only be assessed subjectively

– E.g. 14.1 "Use the clearest and simplest language appropriate for a site's content"

• HTML markup checkpoints are objective

– E.g. 1.1 "Provide a text equivalent for every non-text element"


Types of Accessibility Audit

• Objective audit of HTML markup checkpoints only

– Clearcut results, no subject-specific knowledge required

– Cheap: takes 1-8 hours to audit

• Subjective audit of graphic and information design, language, etc.

– Difficult, requires subject-specific knowledge

– Expensive: may take up to 5 days to audit


80/20 Rule of Accessibility Audits

• 1-day audit against a subset of the WAI WCAG Guidelines covers 80% of the relevant checkpoints

• A more comprehensive 5-day audit covers remaining 20%

– For small organisations, extra expense may not be justified


HTML Markup-specific Audit

• Provides a reasonable indicator of overall accessibility

• Compliance doesn't necessarily mean site is usable

• Audit results are non-controversial, as website is either compliant or non-compliant with each checkpoint

– Very useful for formal acceptance testing


Graphic and Information Design, Content Audit

• Provides a better indicator of overall usability

• However, compliance still doesn't necessarily mean website is usable by its intended audience

• Results are somewhat subjective

• Most useful as part of a formal re-development process


HTML Markup Checkpoints

• 19 text checkpoints

– 4 Level/Priority 1 (A)

– 12 Level/Priority 2 (AA)

– 3 Level/Priority 3 (AAA)

• 3 form checkpoints

– 2 Level/Priority 2 (AA)

– 1 Level/Priority 3 (AAA)

• Much more manageable than 65!


Level 1 Text Markup Checkpoints

• Priority 1 ('A'): 4 Checkpoints

– 1.1 Provide a text equivalent for every non-text element

– 4.1 Clearly identify changes in the natural language

– 6.1 Organize documents so they may be read without style sheets

– 5.1 For data tables, identify row and column headers



• Priority 2 ('AA'): 12 Checkpoints

– 3.4 Use relative rather than absolute units in markup language attribute values

– 3.5 Use header elements to convey document structure

– 3.6 Mark up lists and list items properly

– 3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation.

– Etc.



• Priority 3 ('AAA'): 3 Checkpoints

– 4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs.

– 4.3 Identify the primary natural language of a document

– 5.5 Provide summaries for tables


Form Markup Checkpoints

• Priority 2 ('AA'): 2 Checkpoints

– 10.2 For all form controls with implicitly associated labels, ensure that the label is properly positioned

– 12.4 Associate labels explicitly with their controls

• Priority 3 ('AAA'): 1 Checkpoint

– Include default, place-holding characters in edit boxes and text areas

HTML Markup Example: Headings

• Checkpoint 3.5: Use header elements to convey document structure

• Compliant HTML markup

– <h1>Main heading</h1>

• Non-compliant HTML markup

– Main heading

– Main Heading

HTML Markup Example: Lists

• Checkpoint 3.6: Mark up lists and list items properly

• Compliant HTML markup

– <ul><li>Bullet list item</li>

• Non-compliant HTML markup

– Bullet list item


What to Audit?

• Only some pages on website need to be audited

– Most website pages conform to one of a small number of templates

• Typical pages to audit include:

– Home, About, News, Publications pages

– Search and Search results pages

– Contact or Feedback form

– Some text pages (e.g. Press Release)


How to Audit a Page

• Accessibility auditing uses mixture of tools and techniques

• Use visual inspection to identify absence or misuse of markup

– E.g. lack of heading elements or misuse of BLOCKQUOTE element for indentation

• Use online tools to identify markup errors

– Missing required attributes

– Invalid or non-standard HTML markup


Visual Inspection

• Open the HTML file in a plain text editor

– Check markup of common HTML markup for branding and navigation

– Check markup of headings, lists, etc. in body content

– Are tables used for layout?

– Check for occurences of FONT element

– Check a page containing a data table


Tools to Audit a Web Page

• Bobby accessibility checker

– http://bobby.watchfire.org

– Quickly catches some types of markup error

• HTML validation check

– http://validator.w3.org

• CSS markup validation

– http://jigsaw.w3.org/css-validator/


Automated Auditing

• In some cases, a comprehensive test of every page on a site is required

– To ensure compliance with a set standard of accessibility

– To measure progress towards a stated goal

– To benchmark performance against previous audits, or other sites

• Half-yearly or yearly audits are probably reasonable


Automated Auditing Tools

• Many tools now available for automated accessibility testing

– Bobby, AccVerify, Lift Online

• Can buy ongoing service, or buy tools and use them yourself

• Should include range of tests, not just accessibility

– Linkcheck, validation, metadata, connectivity


Other Useful Audits

• Accessibility of authoring tool or system

• Sitewide automated accessibility check

• Test for broken hyperlinks

• Use of metadata (Dublin Core/IPSMS)

• HTML validation

• Irish Government Web Publishing Guidelines


Authoring Tool Accessibility

• Does the website maintenance system (Web CMS or HTML editor) generate accessibie pages?

– If not, how can it be changed or improved?

• Is the maintenance system itself accessible?

– Can it be used by someone with a disability?

– Is it platform and browser independent (if a Web-based CMS)?

• See WAI Authoring Tool Accessibility Guidelines (ATAG)


Complete Accessibility Test

• What percentage of pages reach each WAI compliance level?

– E.g. A – 100%; AA – 82%; AAA – 74%

• Use as a benchmark to monitor improvement over time

• Automated monitoring services available

• Need to define required standard, and actions to reach it


Broken Hyperlink Check

• Broken links degrade accessibility!

• How many external and internal links are broken?

• How many pages contain broken links?

• What percentage of links are broken?

– Use as a benchmark to monitor improvement over time

• Automated monitoring services available


Metadata Assessment

• Good metadata improves accessibility

– Better search engine performance/results

– Better navibability and usability

• Metadata encompasses a number of different aspects

– Content of HEAD/TITLE element

– Dublin Core and other metadata fields• E.g. DC.Date.modified, DC.Subject, Description

– Visible text (e.g. last modified date, breadcrumb trail)


HTML Validation Check

• Valid pages improve browser, version and platform compatibility

• What percentage and how many pages are valid?

• What DTD is used?

– HTML 4.01 Strict for good accessibility and older browser compatibility

– XHTML 1.0 Strict for maximum accessibility and future-proofing


Irish Government Web Publishing Guidelines

• Good practice guidelines for websites

– Defined by Dept. of the Taoiseach in 1999

– Still a useful reference today

• Checklist of issues to be aware of

– E.g. Site map, contact information, last modified date

• Websites must be manually assessed

• 'Softer', subjective issues of website usability


Summary

• Use a website accessibility audit to gain the knowledge required to make decisions

• Choose the most appropriate type of audit for your situation

• Act immediately on the results of the audit!


Website Accessibility Auditing

• XML Workshop Ltd.

• Q&A

• http://www.xmlw.ie/

Website Accessibility Auditing Eoin Campbell, Technical Director, XML Workshop Ltd.

Documents

Transcript of Website Accessibility Auditing Eoin Campbell, Technical Director, XML Workshop Ltd.