A Comparative Investigation of the Accessibility Levels of Irish Websites

The 159 websites assessed by the WARP accessibility project (McMullin, 2002) were used as a basis for this study. The aim of the study was to compare the sites’ 2002 and 2005 WCAG 1.0 compliance levels, to ascertain whether there has been any improvement in compliance levels over the intervening three year period.

The 159 site URLs were retrieved from Appendix H of the WARP study. These URLs were used to retrieve websites for analysis. Three websites had placeholder pages (Appendix 1). Four sites were not available as the URL had not been renewed (Appendix 2). These seven sites were not usable in the current study as they were not operating as websites at the time of the analysis. Therefore the total number of websites analysed in the current study was 152.

Of these 152, 101 sites had the original URL used in the 2002 study (Appendix 3), a total of 40 had an automatic redirect to an updated URL (Appendix 4) and one other site had non-automatic, linked redirect (Appendix 5). A further 10 had URLs which were replaced by manual searches in Google, WHOIS and the Enterprise Ireland website (Appendix 6).

Of the 152 sites used in the study, several sites used framesets and iframes as part of their design. As the automatic validator only analyses the URL submitted and not the embedded frame pages, these must be analysed separately. Therefore a page using frames is deemed to have an accessibility rating equal to that of the frameset plus that of each of the pages viewed in the frameset on page load. Pages using iframes also had the accessibility results of the iframe page added to the original page.

The WebXact validator available at http://webxact.watchfire.com/ was chosen for the purposes of this study. The original WARP study used Bobby however Bobby on-line was replaced by WebXact in May, 2005, just prior to this study and the Bobby URL http://bobby.watchfire.com/ redirects to WebXact.

Some sites had text-only versions, and although text-only versions of sites were used by the original study for analysis, they are only suitable for blind individuals using screen readers. Other visually impaired individuals requiring simple magnification of the text can be quite easily catered for by simple changes to the main site. Indeed a so-called accessible text-only version may actually be less accessible for cognitively disabled people as there are no supporting images (Mencap, n.d., p.2; Poulson & Nicolle, 2004, p.5). A page full of text can appear very daunting to those whose reading levels are poor. This can also affect deaf individuals who have a lower reading level than the average person due to their lack of fluency with the language (Gallaudet Research Institute, 2003). Therefore, where text-only versions of the sites were available this was counted as a pass for checkpoint 11.4 which allows that if a page could not be made accessible a link to an alternative accessible page would suffice. However, for the purposes of the study, and the remaining checkpoints, the main site was analysed.

As WebXact is used for this study, it’s assumptions shall be taken to be accurate in all cases, however where the researcher disagrees with WebXact’s interpretation this will be noted in the results.

Initial analysis will concentrate on the automatically verifiable checkpoints. This will allow a direct comparison between the 2002 and the 2005 results. Checkpoints which do not fail the automatic check will be assumed to be exempt and recorded as an exempt in the analysis stage and a pass in the evaluation stage.

Subsequently, the method of carrying out the manual checks will be researched and written up. This should facilitate consistency across pages, will allow other researchers to identify how decisions were made and will facilitate repeatability of the study.

Manual checks will then be undertaken on all pages and an additional analysis carried out. In the cases where checkpoints are both manually and automatically validated, the checkpoint will be considered passed where the automatic checks indicate that the site is exempt and the manual check indicate that the site has passed. Where there is a fail in either the manual or the automatic check, the page will be deemed to have failed the checkpoint.

Copies of WebXact’s results, language tests, flicker check test, linearized page check, and html and css validation checks will be kept to facilitate analysis and repeatability. In addition, a log will be compiled for each site indicating details of the manual checks. This will aid further analysis as a breakdown of some of the checkpoints will be thereby facilitated.

All page unless otherwise specified are checked using Macromedia Dreamweaver MX, using the Edit > Find and Replace > Search for Source Code option. To ascertain which of the Checkpoints needed to be manually checked, all the index pages of the 152 sites were parsed by WebXact. The results of this were input into an excel spreadsheet. Where even one site required a manual check, the method of performing the check was researched and written up. These methods were applied equally to each site.

10.1.1 Checkpoint 1.1 - Provide a text equivalent for every non-text element

WebXact can check automatically for the presence of ‘alt’ text when it is required. However, where an image contains important information, such as a chart, table or diagram, it should have an extended description so that blind individuals can access this content (W3C, 1999a). The extended description is referenced using the ‘longdesc’ attribute of the <img> tag which links to the URI of the extended description (W3C, 2000a).

To ascertain compliance with this checkpoint, the pages will be checked manually for charts, diagrams and table images and images with extended text, by viewing the page’s images in Window’s Explorer in thumbnail format. If images like this are found, the page will be checked for a ‘longdesc’ attribute. Those with no extended description, will be deemed to have failed the check, otherwise the page will be deemed passed.

10.1.2 Checkpoint 1.4 - For any time-based multimedia presentation synchronize equivalent alternatives with the presentation

This guideline refers to making available text versions of the audio content in a multimedia element so that deaf individuals can access it. It also refers to a text description of the multimedia itself so that blind people know what the multimedia’s content and purpose is. This can be achieved either by having captions embedded into a QuickTime movie, by using the SMIL specification (WebXact, 2003a) or by enabling accessibility options within the multimedia source code (Celic & Arch, 2003, para.27).

To check whether accessible text versions or alternative text descriptions have been applied, the JAWS 6.20 screen reader will be used on every page which contains multimedia. If equivalent alternatives are available when a page containing multimedia is scanned with JAWS 6.2 the page will be deemed to have passed the check. Where equivalent alternatives cannot be discerned, the page will be deemed to have failed the check.

10.1.3 Checkpoint 2.1 - Ensure that all information conveyed with colour is also available without colour

Information which is conveyed using colour should also be conveyed using mark-up or context (W3C, 1999b). This guideline is primarily concerned with text and links being available and clear to those who are colour blind or using a non-standard monitor.

Therefore, compliance with this checkpoint will involve links being either different from normal text in a non-colour specific way such as being underlined, italicised, bold, in buttons or in obvious navigation bars. An obvious navigation bar will have either: a separate vertical or horizontal grouping of more than two links; a background colour effect; a border; or a graphic which implies a navigation bar. Links which are not in an obvious navigation bar and which do not have a font effect applied will render the page as having failed the check. For example, where in-text links are found, they must have a font effect applied. Font effects applied to links should not be used for non-linked text. Other colour specific content, where not marked up, will also cause the page to fail.

10.1.4 Checkpoint 4.1 - Clearly identify changes in the natural language of a document's text and any text equivalents

Changes in the language of the document should be denoted with the ‘lang’ attribute (normally found in a <span> tag) so that screen readers are able to pronounce the text correctly and Braille displays generate the correct characters (W3C, 1999d).

In order to check the pages, they shall be opened in Dreamweaver MX and the spell checker used (Text > Check Spelling). Where non-English words are present, the source of the original html document shall be checked for the ‘lang’ attribute. Pages which have non-English words which are not marked with the ‘lang’ attribute in the original page will be deemed to have failed the check. These include non-English names and place names which are pronounced differently in their native language to the way they would be pronounced in English (W3C, 2000c). For example, the Irish girls name Caoimhe is pronounced Qwee-Va in Irish.

10.1.5 Checkpoint 5.1 - For data tables, identify row and column headers

Data tables need to be correctly marked up with headers so that individuals using screen readers or Braille displays can conceptualise the structure of the table (W3C, 1999e). The page will be checked visually for data tables. Data tables are defined as those tables where there is a relationship between the cell content and its positioning within the table.

Where no data tables exist, the page will be deemed to have passed. Where there are data tables, the source code will be inspected for use of the following tags: <th> for header information and <td> for table data (W3C, 2000b). Where these tags are present and used correctly the page will be deemed to have passed the check. Where the tags are not present or used incorrectly, the page will be deemed to have failed the check.

10.1.6 Checkpoint 5.2 - For data tables that have two or more logical levels of row or column headers, use mark-up to associate data cells and header cells

This guideline only applies to data tables. Where a page has been identified as having no data tables (see Checkpoint 5.1), this check shall be deemed passed. Where a page has a data table with multiple headers correctly marked up with <thead>, <tfoot>, <tbody>, <colgroup> and <col> tags, or axis, scope and header attributes the page shall be deemed to have passed (W3C, 2000b). If a data table with multiple headers does not have the correct mark-up, it shall be deemed to have failed.

10.1.7 Checkpoint 6.1 - Organize documents so they may be read without style sheets.

Pages which are organised using style sheets for layout should also retain the same information if the style sheets are not supported (W3C, 1999f). To test this, the style sheets for each document shall be temporarily renamed (for external style sheets) or commented out (in-page header styles) so that they are not available to the document. In-line styles will not be commented out as this would be laborious in the extreme. If the page is then still readable and understandable, the page will be deemed to have passed. If the page is not readable or understandable in full without style sheets, the page will be deemed to have failed.

10.1.8 Checkpoint 6.3 - Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.

If this is not possible, provide equivalent information on an alternative accessible page If scripts are disabled the page should function equally well (W3C, 1999f). To test this, the Internet Explorer ‘Tools > Internet Options > Security > Custom Level > Scripting Options’ shall be set to ‘disable’. If the page retains all its functionality the page will be deemed to have passed. If there are changes to the page which result in the page being less usable, such as navigation not being accessible, the page will be deemed to have failed.

10.1.9 Checkpoint 7.1 - Until user agents allow users to control flickering, avoid causing the screen to flicker

Individuals suffering from epilepsy may suffer an attack if the screen flickers or mimics strobe light effects where the flicker rate is between 4 and 59 flashes per second. The peak rate occurs at 20 flashes per second (W3C, 1999g).

Pages will be checked for flickering animated gifs using a flickering check tool available at http://www.webaccessibile.org/test/check.aspx. Those pages which have no flickering elements will be deemed to have passed. Flickering elements which are not in the critical range for WCAG 1.0 will be deemed to have passed. Flickering elements in the critical range or close to peak sensitivity will be deemed to have failed.

10.1.10 Checkpoint 8.1 - Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies if functionality is important and not presented elsewhere

Scripts, applets and objects may not run on all systems, so a text alternative should be provided explaining the function of the script. Where a <script> tag is found on a page, a <noscript> tag should also follow (WebXact, 2003b).

Pages will be scanned for the search string ‘<script’ (without a closing > as many script tags have attributes which occur before the >). Where scripts are found, the page will be again scanned for ‘<noscript’. If there are scripts on the page and no <noscript>s can be found, the page will be deemed to have failed. Where a <noscript> is found, the page will be deemed passed.

Pages will be also scanned for ‘applet’. Where an applet is found it should have an ‘alt’ attribute, otherwise the page shall be deemed to have failed. Pages will also be checked for ‘object’. Objects should have alternative content between the <object> and </object> tags (WebXact, 2003b), otherwise the page will be deemed to have failed.

10.1.11 Checkpoint 11.4 - If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.

Creating an alternative version of the page is possible only if it is not possible to make the current page accessible (such as those pages which use applets etc) (WebXact, 2003c). Pages for which this guideline is highlighted by WebXact will be checked for links to an accessible version. Pages which do not have an accessible version will fail the check.

10.1.12 Checkpoint 14.1 - Use the clearest and simplest language appropriate for a site's content

The purpose of this guideline is to prompt the web author to create text which is readable by everyone (W3C, 1999n). The average reading level of the general population is around the 8th grade (NCDDR, 2003, p.4). Text which is accessible to individuals with cognitive disabilities should be around the 4th-5th grade level (NCDDR, 2003, p.4).

Pages will be assessed using the Readability test tool from Juicy Studio http://juicystudio.com/services/readability.php. Pages which have a Flesch-Kincaid Grade Level of 5th Grade (5.x) or lower shall be deemed to have passed. Pages with a Flesch-Kincaid Grade Level equal to or higher than 6th grade will be deemed to have failed. Where the index page does not have adequate representative text for this check, another page will be chosen.

10.2.1 Checkpoint 2.2 - Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits or when viewed on a black and white screen.

The purpose of this check is to ensure that partially sighted or colour blind individuals are able to read the text on the background colour of the page (W3C, 1999b). An accessibility tool called aDesigner (Takagi et al, 2004) will be used to check colour contrast. aDesigner has 4 settings for low vision for which it can make a comparison regarding foreground and background colour combinations, including the three types of colour blindness, and crystalline lens transparency, or yellowing of the eye, associated with aging.

The default settings in aDesigner will be used independently. These are crystalline lens transparency of 40 (years of age) and each of the three colour blindness. aDesigner awards a maximum of 3 stars for each test. Pages will be deemed to have passed where they are awarded 3 stars on each of the 4 tests.

10.2.2 Checkpoint 3.1 - When an appropriate mark-up language exists, use mark-up rather than images to convey information

This guideline’s purpose is to ensure that as much content as possible is provided without resorting to images (W3C, 1999c). This ensures that screen readers can parse the document to the greatest extent. Pages will be tested by opening the associated image file and viewing the images as thumbnails. Pages with images which contain elements which could be marked up with style sheets (such as those which simply contain text and a background colour) will be marked as failing the check as this is simple to achieve with style sheets. Pages with images which contain formula will also fail the check as this should be marked up using the MathML mark-up language (W3C, 2000d).

10.2.3 Checkpoint 3.2 - Create documents that validate to published formal grammars

Documents must comply with formal grammar specifications, otherwise some browsers, assistive technologies and legacy systems may be unable to render them correctly. To ascertain the validity of the page grammar, the page will be checked at http://validator.w3.org/ (for html and xhtml), http://jigsaw.w3.org/css-validator/validator-uri (for css and css2). Where xhtml files fail the check and the associated css files cannot be assessed, the css file will be tested separately at http://jigsaw.w3.org/css-validator/ using the ‘validate by file upload’ option. Pages which fail any applicable test will be deemed to have failed the check.

10.2.4 Checkpoint 3.3 - Use style sheets to control layout and presentation

Style sheets are promoted as they can be turned off by the user using the Internet Explorer > Tools > Internet Options > Accessibility options. This can be useful for some dyslexic individuals who find it easier to read using various colour schemes (James & Litterick, 2005, para.3), and for colour blind individuals who may find it difficult to see page elements using the given colours. This check is purely to ascertain whether style sheets were used, not whether they are grammatically correct. Sites using frames will have each framed page tested for style sheets. Pages which have neither a linked or embedded style sheet (as verified by testing in Checkpoint 3.2) will be deemed to have failed the check.

10.2.5 Checkpoint 3.5 - Use header elements to convey document structure and use them according to specification

Header elements should be marked up correctly to facilitate page scanning by screen reader users (WebXact, 2003d). The <h1> tag should be the first header on the page when the html code is viewed. Subsequent headers should follow a logical order (W3C, 2000e). Each header should be preceded by a header equal to or one level up from it, except when starting a new section. For example, <h1><h2><h3><h3><h2><h3> is ok, but <h1><h3><h2><h4> is not.

Pages where headers are used incorrectly will fail the check. Pages which have words or phrases marked up with header tags which clearly are not headers (not followed directly by a paragraph or another header) will be deemed to have failed the check.

10.2.6 Checkpoint 3.6 - Mark up lists and list items properly

List tags should not be used for formatting effects, as this can confuse screen reader users. The <li> tag should not be applied to non-list items such as a vertical or horizontal line used to visually space out a list. Nested lists should use styles to denote list hierarchy (W3C, 2000f). Items which appear visually to be listed, should use list mark-up (<li>, <ul> <ol>, <dl>, <dd>, <dt>). Pages which use list mark-up incorrectly or fail to use list mark-up when required will be deemed to have failed the check.

10.2.7 Checkpoint 3.7 - Mark up quotations. Do not use quotation mark-up for formatting effects such as indentation

The use of <q> and <blockquote> to mark-up quotations facilitates assistive technologies to render the page correctly (WebXact, 2003e). Where quotations are visible on the page, the code will be checked for both <q> and <blockquote>.

Short inline quotations using the <q> tag will be deemed to have passed. Long block level quotations using the <blockquote> tag will be deemed to have passed. Quotations not using either will be deemed to have failed. Quotations using the wrong tag for its position will be deemed to have failed. Pages using <blockquote> to indent text (W3C, 2000g) will fail.

Text enclosed with quotes which does not have a source referenced will not be deemed a quotation. It will be regarded as emphasis and will not be failed.

10.2.8 Checkpoint 5.3 - Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).

Although using tables for layout is not prohibited by WCAG, authors are generally advised to follow the concept of ‘separation of content from presentation’. In web terms, this is normally accomplished by laying out the text in a logical order, marking it up using <div> and <span> tags to identify discrete areas of content and then using CSS to style and position those pieces of content. Older methods of laying out html pages used the table, which was originally designed to be used for data presentation only. However, tables may be rendered incorrectly by some assistive devices, such that pieces of text from adjacent cells are merged together (W3C, 2000h). This is due to incorrect linearization of the table. To check whether a page’s tables linearize correctly they will be viewed using lynx, a text only viewer, available at http://lynx.isc.org/current/. An installer for lynx2.8.5 is available at http://csant.info/lynx.htm. Lynx treats the <tr> tag as a <br> tag, and the <tr> and <td> tags as spaces (Lynx, 2004), effectively linearising the table.

Where the text is readable, understandable, and available in full when viewed through lynx, the page will be deemed to have passed. Where the text is garbled or not displayed in any instances, the page will be deemed to have failed this check.

10.2.9 Checkpoint 5.4 - If a table is used for layout, do not use any structural mark-up for the purpose of visual formatting

Data tables assume a relationship between the contents of each cell and the header tag of its column. Tables used for layout should not use <th> tags like those used in data tables as this can confuse screen reader users who may expect to find a non-existent relationship (WebXact, 2003f).

Where a table which is clearly not a data table is using structural mark-up, such as the <th> tag, the page will be deemed to have failed the check. A data table is one where there is a relationship between the content of a cell and its position within the table.

10.2.10 Checkpoint 6.4 - For scripts and applets, ensure that event handlers are input device-independent

Some individuals are restricted in the input devices they can use. Some can use only the keyboard, others can use only the mouse. Others must use other devices such as head pointers and virtual keyboards. Scripts which use device dependant attributes such as onmousedown, onmouseup, onclick, ondblclick, onkeydown, onkeyup and onkeypress may not be accessible to some of these individuals. Device independent attributes such as onfocus, onblur and onselect should be used instead. It may also be possible to use both the mouse and keyboard handlers to achieve the same accessibility (W3C, 2000i).

Pages using scripts (as ascertained in Checkpoint 8.1) will be checked for device dependant attributes. Where device dependant attributes exist, that are not complemented in each instance by an alternative device script, the page will be deemed to have failed.

10.2.11 Checkpoint 7.2 - Until user agents allow users to control blinking, avoid causing content to blink

Blinking text can be distracting to individuals with attention deficits or cognitive disabilities (WebAim, 2004). Text should not be marked up to blink with the use of the <blink> or <marquee> tags (W3C, 2000j). Pages will be scanned for <blink> and <marquee>. Where these tags are found, the page will be deemed to have failed the check.

10.2.12 Checkpoint 9.2 - Ensure that any element that has its own interface can be operated in a device-independent manner

Where <object>s and <applet>s exist (as verified by Checkpoint 8.1) they should not use device dependant scripts and should be directly accessible (W3C, 2000k). On pages which trigger this check in WebXact, attempts will be made to use both mouse and keyboard to control the <object>s and <applet>s. If this is unsuccessful, the page will be deemed failed.

10.2.13 Checkpoint 10.1 - Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user

Opening new windows can cause problems for novice users and those using assistive devices (WebXact, 2003g). The user should always be aware that a new window will open on a particular event. The attribute ‘target’ or scripts such as JavaScript can be used to open new windows. In a frameset the use of ‘target’ is permitted once ‘_blank’ is not used (W3C, 2000l).

Where the target attribute is found, and the page is not a frameset and no text warning is given, the page will be deemed to have failed the check. If any other pop up windows appear as a result of loading or manipulating the page, the page will fail the check.

10.2.14 Checkpoint 10.2 - Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned

Labels for forms which are not correctly placed can be confusing for screen reader users, as they may not know which label is associated with which form element (WebXact, 2003h). Labels should appear on the same or preceding line of the element (W3C, 1999j). This check does not require that the label be explicitly associated with the form element (for example, using the ‘for’ attribute), or that every form element has a label.

Pages which have form elements will be checked manually for compliance. Where labels are not on the same or preceding line as their associated form element they will be deemed to have failed the check.

10.2.15 Checkpoint 11.1 - Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported

Web authors are urged to use the latest technology specification on the grounds that there is more support for assistive technologies. Unfortunately, the list of W3 technologies is enormous (W3C, 2005) and it will not be possible to exhaustively check each page against this.

However, on the Techniques For Accessibility Evaluation And Repair Tools page of the w3c website (http://www.w3.org/TR/AERT#use-w3c), a list of non-W3C technologies is given which have w3c equivalents. These are PDF, Flash, GIF images, JPG images & proprietary HTML elements.

Pages which use the JPG file format shall not fail the check as on the Core Techniques for Web Content Accessibility Guidelines 1.0 page it states ‘some are best expressed in JPG, a non-w3c spec’. However, all the other technologies on the list, when present will result in a fail unless an accessible equivalent is also available. PDFs (.pdf) should be replaced with text only, Flash (.swf) should be replaced with HTML and PNG, and GIF (.gif) should be replaced with PNG or JPG.

10.2.16 Checkpoint 11.2 - Avoid deprecated features of W3C technologies The following tags have been removed from HTML 4.0 and therefore should not be used: <applet>, <basefont>, <center>, <dir>, <font>, <isindex>, <menu>, <s>, <strike> & <u> (W3C, 1999o). Several attributes have also been deprecated including: align (deprecated if used in <caption>, <iframe>, <img>, <input>, <object>, <legend>, <table>, <hr>, <div>, <h1..6>, <p>), alink (deprecated if used in <body>), background (deprecated if used in <body>), bgcolor (deprecated if used in <table>, <tr>, <td>, <th>,<body>,) border (deprecated if used in <img>, <object>), clear (deprecated if used in <br>), compact (deprecated if used in <dl>, <ol>, <ul>), height (deprecated if used in <td>, <th>), hspace (deprecated if used in <img>,<object>), language (deprecated if used in <script>), link (deprecated if used in <body>), noshade (deprecated if used in <hr>), nowrap (deprecated if used in <td>, <th>), size (deprecated if used in <hr>), start (deprecated if used in <ol>), text (deprecated if used in <body>), type (deprecated if used in <li>, <ol>, <ul>), value (deprecated if used in <li>), version (deprecated if used in <html>), vlink (deprecated if used in <body>), vspace (deprecated if used in <img>,<object>), width (deprecated if used in <hr>, <td>, <th>, <pre>) (W3C, 1999p).

Each page for which this check is triggered by WebXact will be initially tested for the presence of <font> and <center> tags as these are the most common. If a page does not have either of these tags the other tags and attributes will be checked. The presence of any deprecated language features will result in the page failing the check.

10.2.17 Checkpoint 12.2 - Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone

Individuals using screen readers may not know which frame to choose to view if the title details are minimal or unclear (WebXact, 2003h). If the ‘title’ attribute does not provide clear unambiguous information relating to the content and purpose of the frame, a long description is required. Where frame titles are not clear, pages without an associated ‘longdesc’ attribute will be deemed to have failed the check.

10.2.18 Checkpoint 12.3 - Divide large blocks of information into more manageable groups where natural and appropriate

This checkpoint refers to the correct use of layout tags and their use in grouping related elements. Form controls can be grouped using the <fieldset> and <legend> tags. The <optgroup> tag can also be used to group choices. Tables and associated tags such as <caption>, <thead>, <tbody>, <tfoot> and <colgroup> should be used to group tabular data. List items should use <ul>, <ol> & <dl>. Header elements <h1> … <h6> should be used correctly to break up long stretches of text and add structure. The <p> tag should be used to break text into paragraphs (W3C, 2000m).

Pages will be scanned for the tags listed above. Where pages have failed to use any of the tags listed, they will fail the check. Note that <div> and <span> tags are not included in this list, as they were not on the w3c website.

10.2.19 Checkpoint 13.1 - Clearly identify the target of each link

Screen reader users often jump from link to link when scanning a page. If the links are not self-explanatory there will be confusion for the user. In particular the use of ‘click here’ and ‘more’ is discouraged. Web authors are also encouraged to add link text, via a ‘title’ attribute where necessary for clarity. Furthermore, duplicate link phrases can cause problems due to ambiguity (W3C, 2000n).

Pages will be visually checked for the use of ‘click here’ and ‘more’ and other ambiguous wording in links with a visual check of the page. Pages which have identical link phrases which link to different pages will be deemed to have failed the check. Pages which use ambiguous wording without additional title text will also be deemed to have failed the check.

10.2.20 Checkpoint 13.2 - Provide metadata to add semantic information to pages and sites

Metadata is used to provide additional data about the page. Mandatory metadata include the <title> tag (W3C, 2000o) and the <doctype> statement (required for validation). Other optional metadata include Meta, Address, and Link tags. As the only mandatory elements are the <title> tag and <doctype> statements, these will be checked. Pages which do not have a <title> tag and <doctype> statement will fail the check.

Where <meta> tags are used, the attribute ‘http-equiv="refresh"’ is forbidden. Where this is found the page will also fail the check.

10.2.21 Checkpoint 13.3 - Provide information about the general layout of a site (e.g., a site map or table of contents)

Site maps are important to give users a sense of the extent, complexity and content available on the site. Nested lists are recommended (WebXact, 2003j). Each site will be checked for a sitemap link. If no sitemap exists the site will be deemed to have failed the check.

10.2.22 Checkpoint 13.4 - Use navigation mechanisms in a consistent manner

Novice users as well as cognitively disabled and blind individuals find a site much easier to navigate if navigational elements are consistently found in the same place (W3C, 2000p). Five pages from each site including the home page will be checked to verify consistency.

Where the main navigational elements (left, right, top and bottom navs, next, back and home links) do not change position the site will be deemed to have passed. If any of the main navigational elements have changed, the site will be deemed to have failed the check.

10.3.1 Checkpoint 4.2 - Specify the expansion of each abbreviation or acronym in a document where it first occurs

The <abbr> (abbreviation) and <acronym> tags should be used with title attributes to provide clarification of the meaning of the abbreviation or acronym text in the document. This both aids understanding by novice users and facilitates reading by screen readers which can read out the title text. The mark-up is only expected at the first instance of an abbreviation or acronym on the page (W3C, 1999d).

To test this checkpoint, each page shall be scanned visually for abbreviations or acronyms. Where they are found, the first instance of each will be checked for correct mark-up. If the correct mark-up is found, the page will be deemed to have passed. If any instances of incorrect mark-up, or no mark-up, are found on the first instance of an abbreviation or acronym the page will be deemed to have failed the check even if the surrounding text contains the expanded text.

10.3.2 Checkpoint 5.5 - Provide summaries for tables

The <caption> tag is used to explain the purpose and content of a table. They are useful for those using screen readers, as the caption can provide enough information to allow them to choose whether the table is of interest to them or not. Summary attributes can also be used within the <table> tag to provide layout information of how the table is structured (W3C, 2000q).

Where data tables exist in the page, as verified in Checkpoint 5.1, the page will be searched for the <caption> tag and the summary attribute. Where no <caption> tag or summary attribute exist for each data table, or where the explanation provided is insufficient, the page will be deemed to have failed.

10.3.3 Checkpoint 5.6 - Provide abbreviations for header labels

Long labels when being read out continuously by screen readers can take a lot of time (W3C, 2000q). Labels more than two words long cause WebXact to trigger this check. These should have a one or two word abbreviation, which the screen reader can substitute in its place.

Pages will be scanned for <th> tags and those with labels which have three or more words, and which do not have an associated abbreviation attribute will be deemed to have failed the check.

10.3.4 Checkpoint 9.4 - Create a logical tab order through links, form controls, and objects

Tabbing to get around the page is used by screen reader users and keyboard-only users. The tabindex attribute can be used to specify the most logical order in which page elements should be visited (WebXact, 2003k).

Where the tabindex attribute is used the page will be deemed to have passed. Where the tabindex attribute is not used, the page will be deemed to have failed the check.

10.3.5 Checkpoint 9.5 - Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls

It is also possible to implement accesskeys which are keyboard shortcuts to important links. This means that a minimal amount of tabbing is required to scan the page, thereby speeding up the process (W3C, 2000r). Most sites which put accesskeys in place have a list of those used in the site on the accessibility statement page.

Where at least one instance of the accesskey attribute is used the page will be deemed to have passed. Where the accesskey attribute is not used the page will be deemed to have failed the check.

10.3.6 Checkpoint 10.3 - Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns

Tables which format text in columns can cause problems for some screen readers which read out text from adjacent columns as if they were joined, resulting in a garbled output. Layout tables are checked for linearization in Checkpoint 5.3, however tables should also have a linear version in the event that some devices cannot handle the linearization process (W3C, 2000h).

All pages for which this checkpoint is highlighted, which have tables with no alternative linear version available, will fail this check.

10.3.7 Checkpoint 11.3 - Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)

This guideline advocates allowing the user to retrieve information in another format, for example, different languages (W3C, 2000s), voice emphasis using style sheets (W3C, 2000t) using rel="alternate” attribute, device specific style sheets (W3C, 2000u) using @media.

Pages will be checked for the use of the @media, media= and rel=alternate elements and other user-preference features such as text only, adjustable text size, printable versions. Any pages which facilitate either alternative languages or alternative styling through the page interface will be deemed to have passed. Pages will be deemed to have failed this check where no evidence of customisation is available.

10.3.8 Checkpoint 13.5 - Provide navigation bars to highlight and give access to the navigation mechanism

Navigation bars are ‘compact, consistent, well-grouped, and comprehensible’ (webXact, 2003l) sets of links found on every page which helps users to orient themselves within the site. A navigation bar is normally found on the left, right or top of a page with supplementary links to the bottom.

Pages which show a clear navigation bar (set of more than 2 aligned links) will be deemed to have passed the check. Pages will fail where there is no visible navigation bar.

10.3.9 Checkpoint 13.6 - Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group

A method of bypassing grouped links should be provided so that those using screen readers do not have to laboriously wade through each link. Skiplinks are created by linking to anchor <a> tags throughout the page or by specifying a tabindex of 1 (W3C, 2000v).

Pages with navigation bars will be checked for the presence of a skiplink or tabindex attribute. Pages which have neither a skiplink nor tabindex attribute will fail the check.

10.3.10 Checkpoint 13.7 - If search functions are provided, enable different types of searches for different skill levels and preferences

Some individuals may not be able to use a search box effectively due to spelling or other cognitive difficulties. Different type of searches such as advanced searches, drop-down menus or a series of logically organised links should be provided to facilitate these individuals (WebXact, 2003m).

Where search boxes are available, pages will also be checked for the existence of another type of search or logically organised browse facility. A test query will be entered into the search function, to see if the user is offered a search refinement. Sites which have no alternative search or browse method will be deemed to have failed the check.

10.3.11 Checkpoint 13.8 - Place distinguishing information at the beginning of headings, paragraphs, lists, etc.

This guideline refers to the ‘inverted pyramid’ style of writing commonly used in journalism to provide the most relevant information to the top of a section followed by background information towards the end. This style facilitates people using screen readers who can read the header information or the first few lines and skip the paragraph if it is not relevant (WebXact, 2003n). It also facilitates cognitively impaired individuals who may find it difficult to read a large piece of text (Brown & Lawton, 2001, p.19).

Each paragraph will be checked to verify if the first sentence summarises or give a succinct introduction to the paragraph which follows. Where this is the case in all sections, the page will be deemed to have passed. Where the index page has little text based information, the ‘about us’ or similar page will be checked instead.

10.3.12 Checkpoint 13.9 - Provide information about document collections (i.e., documents comprising multiple pages.)

<link> tags are used to provide support information for the document, for example to show which URL is previous or next in a series of related links (W3C, 2000w). Unfortunately, it is generally not possible to ascertain whether a document belongs to a collection, unless you are an author of the collection. However where the author has supplied next and back links it will be assumed that the pages are presented in a sequence and therefore part of a collection.

Pages which have either a next or a back link will be checked for <link> tags providing support information. Pages which subsequently do not have appropriate <link> information will be deemed to have failed the check.

10.3.13 Checkpoint 14.2 - Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page

Some information is conveyed more easily with the use of graphs, arrows and other graphics. This is particularly important for cognitively disabled individuals who may find the text version incomprehensible (WebXact, 2003o).

Pages will be manually checked for text which would be better explained or supplemented with images.Pages which do have text which can be supplemented or replaced with graphics will be deemed to have failed the check. Particular targets include phrases such as ‘go up one level’ or ‘next’ where the meaning can be conveyed more effectively with the use of an up or right facing arrow.

10.3.14 Checkpoint 14.3 - Create a style of presentation that is consistent across pages

A consistent method of presentation of content, navigational elements (such as navigation bars and search boxes) and style (such as colours and fonts) can help to orient both novice users and those with learning and reading difficulties. The use of linked style sheets facilitates consistency, whereas embedded or inline styles are less likely to remain consistent after updates (W3C, 2000x).

As with Checkpoint 13.4, 5 pages will be checked from each site to ensure consistency in presentation. Where any of these pages are distinctly different from the others the site will be deemed to have failed the check.

previous - next