Cabinet Office
The testing of websites has identified clear examples of good practice, describing the approach that others should emulate if the accessibility of online public services across EU member states is to improve. It has also uncovered the common reasons why many websites are falling short of the required standards at Level A and Level Double-A. From this information a list of priorities has been developed that will achieve the greatest impact for disabled users with the most efficient use of resources.
Web managers, developers and policy-makers, can learn from the good practice shown by some of the sites that have performed well during our testing. A further step in the process of assessment was used to select good practice sites from those that achieved Limited Pass Level A (Appendix 2 details this final step of evaluation). From this analysis, three European websites have been highlighted demonstrating overall good practice.
All three of these sites demonstrate at least ten out of the 12 features of evidence of good practice listed opposite. For example, they each have very clearly laid-out pages detailing site-specific accessibility features that are directly linked from the home page. These pages not only give helpful information about accessibility, but in so doing present a positive policy to accessible web services.
Social Security Administration website: www.seg-social.es (as at October 2005) [External website].
Accessibility section: http://www.seg-social.es/inicio/?MIval=cw_usr_view_Folder&LANG=1&ID=40247 [External website]
The following features of good practice in accessible web design are a more concrete illustration of a number of the WCAG 1.0 checkpoints. However, they are not a substitute for the full set of WCAG 1.0 checkpoints, nor are they intended to suggest any alternative prioritisation. Rather, they are just a noteworthy selection of the good practice accessibility features in operation during the current study.
This provides information about the accessibility of the website and is also an opportunity to state known accessibility barriers. By demonstrating awareness of accessibility issues, it makes a positive statement about commitment at both the policy as well as the implementation level.
Whilst sighted users can see physical images on the web page, users who are vision impaired rely on the alternative text being read by a screen reader for the image so that they may understand what the image is. The use of alternative text (also known as ‘alt text’ or ‘alt tags’) for all types of image, such as pictures, text as graphics, decorative graphics, spacer ‘gifs’, form buttons and graphical links, is fundamental to accessibility. It is responsible for around 30 to 40 percent of all problems affecting a range of disabled people accessing the web.
For a number of reasons all graphics on a page need to be labelled. Blind users accessing the website via a screen reader will have only the information in the ‘alt text’ to gauge the importance of a particular image. In addition, missing ‘alt text’ on graphical links and form buttons will impede the usability of the website for users using voice recognition software. The usability of the website will also be significantly reduced for users with cognitive impairments or dyslexia, as software packages that they use to assist them will ‘speak’ the content of the page, including pictures and graphical links. In short, if no meaningful alternative text is provided, this reduces greatly the readability and the visitor’s understanding of the site content.
Providing consistent navigation is important for all users enabling them to orientate themselves within the website and reduce the possibilities for becoming confused or lost. In addition to consistent navigation, it is often helpful to provide a ‘breadcrumb’ navigation list. This is a design feature created to help users understand where they are in relation to the previous page, as well as the site as a whole. It is particularly helpful for users with cognitive disabilities.
Cascading style sheets (CSS) are used to define the presentational aspects of a web page, such as its use of background colour, text colour and the position where objects are placed on a page, whilst the content is defined in the web page code itself. Separating content from presentation by using CSS results in the website engaging a consistent design that improves its accessibility. It facilitates easy navigation for a user as the means of navigation is likely to be in the same place on each page. By introducing CSS instead of ‘hard coding’ presentation information into the content, users have the facility to override style sheets with their own customised style sheet if they require specific colour combinations, very large fonts or a different layout, for example.
It is important that users are able to increase font sizes in their browser. This is specifically helpful for low-vision users, where increasing the font from the default size enables them to read the information on the web page more clearly. This option is facilitated when websites do not attempt to specify ‘absolute’ font sizes.
Users of screen readers, magnifiers, or Braille displays cannot easily scan the overall organisation of a web page. This will slow down their use of the web significantly However, if they extract an outline of the page, based on properly structured headings and subheadings, this facility will provide such users with a quick way to skim the content rather than plough through the whole web page. The user can scan the headings and select any of interest to go to the specific area on the page. Such a page outline can also facilitate in-page orientation and navigation for users with some cognitive disabilities.
Users with a wide variety of disabilities may be unable to operate a mouse or other pointer-type input device. This may arise owing to physical difficulty in operating a mouse, or a visual or cognitive impairment which means the user cannot effectively track an on-screen mouse pointer. In all such cases, it is essential that any user interactions required on a website can be completed using a keyboard interface – whether a conventional computer keyboard, or one specially adapted to the specific needs of the user.
This is a useful tool for people who want to orientate themselves after becoming lost in the website, particularly for a range of disabled people such as blind web users and people with cognitive impairments such as memory disorders.
The site map allows users to gain an overall ‘feel’ for the layout of the site, while also allowing direct access to any page on the site. If it provides access to only a selection of pages, it becomes of limited use as an information location tool. If pages appear as one very long list, the usability of the feature as a navigational aid is severely compromised.
Providing a unique page title is important because it aids users of non-graphic browsers, particularly visually impaired/blind users in identifying quickly which page they have arrived at. Unique page titles will also allow pages of the site to be indexed more accurately by non-human devices such as search engine robots.
Department of Health website www.dh.gov.uk (as at October 2005) [External website].
http://www.dh.gov.uk/Help/HelpTechnical/fs/en?CONTENT_ID=4088697&chk=ZWm8nd [External website].
European Central Bank www.ecb.int (as at October 2005) [External website].
Non-graphical browsers, including text-to-speech-based browsers, provide web page information in a linear form. This means that users cannot scan pages to find the start of the important page content. By providing a means to skip to important page content, navigation is speeded up for non-graphical browser users, particularly blind and vision-impaired users.
Pages that validate, i.e. those that have been coded using standards defined by formal grammars, are likely to be supported by more browsers and assistive technologies, thereby resulting in the page being accessible by a greater number of users. Many features of assistive technologies and web browsers rely on published formal grammars. Moreover, pages that fail validation are likely to create barriers for users accessing the web via assistive technologies such as a screen reader.
Opening a link in a new window without letting the user know is an issue because it can often confuse a screen reader user and people with cognitive impairments such as memory deficit disorder, e.g. they might not know why the browser back button no longer works.
In addition to our three examples of overall good practice, the study has identified many sites that have demonstrated individual areas of good practice, although not excelling in every way.
| Member State | Title of website | URL |
|---|---|---|
| Austria | Austrian national portal | http://help.gv.at [External website] |
| Estonia | Estonian Institute | http://www.eesti.ee [External website] |
| France | Minister of the Interior | http://www.interieur.gouv.fr [External website] |
| Hungary | Prime Minister's Office Information Technology Government Commissioner | http://www.meh.hu [External website] |
| Italy | Verso L'Universita | http://universo.miur.it [External website] |
| Luxembourg | Police Grande Ducale | http://www.police.public.lu [External website] |
| Lithuania | State Social Insurance Fund Board under the Ministry of Social Security and Labour | http://www.sodra.lt [External website] |
| Malta | Portal to Malta Government Services | http://www.gov.mt [External website] |
| Member State | Title of website | URL |
|---|---|---|
| Austria | Austrian national portal | http://www.help-business.gv.at [External website] |
| France | Directorate General of Customs | http://www.douane.gouv.fr [External website] |
| Greece | Citizen Service Centres Project – Ministry of Interior and General Secretary of Public Admin and e-Government | http://www.kep.gov.gr [External website] |
| Ireland | Online Access to Services Information and Support (OASIS) | http://www.oasis.gov.ie [External website] |
| Lithuania | State Social Insurance Fund Board under the Ministry of Social Security and Labour | http://www.sodra.lt [External website] |
| Portugal | Portuguese Directorate – General for Traffic | http://www.dgv.pt [External website] |
| Member State | Title of website | URL |
|---|---|---|
| Austria | Federal Ministry for land and forestry, environment and water management | www.lebensministerium.at [External website] |
| Austria | Convention on the International Trade in Endangered Species of Wild Fauna and Flora | www.artenschutz.at [External website] |
| Germany | The Deutschland Portal | www.deutschland.de [External website] |
| Italy | Comune di Sala Consilina | www.comune.sala-consilina.salerno.it [External website] |
| Spain | Spanish Social Security | www.seg-social.es [External website] |
| Sweden | Swedish Agency for Economic and Regional Growth | www.nutek.se [External website] |
| Member State | Title of website | URL |
|---|---|---|
| Austria | Convention on the International Trade in Endangered Species of Wild Fauna and Flora | www.artenschutz.at [External website] |
| Malta | Malta Police Force – Online Reporting System | www.pulizija.gov.mt [External website] |
| Spain | Federation of Spanish Municipalities and Provinces | www.femp.es [External website] |
| Sweden | Swedish Companies Registration Office | www.bolagsverket.se [External website] |
| Sweden | Swedish Agency for Economic and Regional Growth | www.nutek.se [External website] |
Ensure effective liaison with all EU-wide organisations (e.g. EIAO, EDeAN, Support-EAM, eAccessibility Expert Group) to encourage the sharing of best practice and a harmonised approach across the EU so that eAccessibility becomes part of the mainstream for online services, e.g. the link between accessibility and usability.
See Section 5.2 for full list of recommendations
It is vital to understand where the reasons for failure lie in order to propose actions for improvement. We start with the most common reasons for failure at Level A, summarised in Chart 9, identified by automated evaluation. This shows a high incidence of failure across the full sample of sites for five of the fully automated checks.
(Note: These include all sites classified as Marginal Fail Level A as well as those that have been assessed as Fail Level A.)
Chart 9 Reasons for non-conformance (Level A)
In order to help organisations achieve Level A conformance, we have provided a further series of charts, analysing in turn each of the five reasons in Chart 9.
Of the sites that were found to fail these specific checks, just over 20% were considered to have failed marginally, the failures being limited in variety and/or scope across the site. These sites were classified as Marginal Fail A. If these sites were able to have this core set of accessibility defects corrected, then they would be converted into the Limited Pass A category; and, as a result, 30% of sites would achieve this level. This would be a significant short-term step in improving WCAG 1.0 conformance, for potentially little effort
We finish with the most common reasons for failure at Level A identified by manual evaluation. Of the 57 sites which successfully passed all the fully automated checks at Level A, a sample of16 were subjected to further detailed manual evaluation. At this stage, four of these sites where found to have substantially achieved Level A conformance; the remaining 12 sites (75% of those subject to this manual evaluation) still failed at least one check. There was no single dominant reason for this. Most sites failed on multiple checks, and there was substantial diversity in which particular manual checks were failed. However, five kinds of problem accounted for almost all of these failures. If these could be corrected, virtually all the sites considered here could have achieved the full Level A Pass classification.
‘Provide a text equivalent for every non-text element’ (WCAG 1.0 Checkpoint 1.1 – Priority 1)
Chart 9a Image ‘alt text’ (Level A)
Almost two-thirds of sites have widespread instances of this problem. Omission of this alternative text represents a substantial potential barrier for significant numbers of people with disabilities, particularly those affected by a variety of vision impairments. This manifests itself in two distinct ways:
Formulation of appropriate alternative texts for images does require training for website designers and authors; but it is not a complex skill. In the great majority of cases, composing suitable alternative texts requires only a nominal amount of additional effort. There may be a difficulty if an authoring tool or content management system does not facilitate the process of adding alternative texts; but in such cases it would be appropriate for organisations to source more appropriate tools, ideally conforming with the W3C WAI Authoring Tool Accessibility Guidelines (ATAG).
Deployment of appropriate alternative texts for images can bring additional benefits. For example, images cannot, in general, be automatically indexed for search purposes; but the corresponding text alternatives can. Where images carry significant information or are functionally important, this will improve access to a site for all users.
To summarise, it is clear that this defect is correctable, usually with minimal investment, and with significant and immediate benefits for users with a variety of disabilities. Given the continuing high incidence of this defect, there is a strong case for targeted intervention to address this single issue.
Ensure that all images are supported with effective alternative text, appropriate to the situation at all times (including explicitly null alternative text, where applicable).
See Section 5.2 for full list of recommendations
‘Title each frame to facilitate frame identification and navigation’ (WCAG 1.0 Checkpoint 12.1 – Priority 1)
Chart 9b FRAME titles (Level A)
The second most pervasive of the defects assessed was missing ‘title’ attributes on ‘frame’ elements. This occurs in sites that use the HTML ‘frameset’ mechanism for combining a number of distinct resources, or pages, into a single unit for visual display to the user. A typical application is to maintain a common navigation panel for a site in a separate pane of the browser window from the substantive site content. The frameset mechanism was originally conceived and designed specifically with visual users in mind, and, therefore, presents additional difficulties for users who cannot directly perceive a multi-frame visual layout. Frameset sites can still be made accessible to such users, but this depends critically on providing additional, non-visual ‘hints’ or ‘cues’ about the functions of the different visual frames. This is technically done via the ‘title’ attributes on the ‘frame’ elements. In the absence of such attributes, these sites will be difficult, if not impossible, to navigate for many users with a wide variety of visual disabilities.
Frameset is, at this stage, an obsolete technology. This is evident from the fact that, in this study, only about 22% of sites use it. We recommend that, where a website with frameset is undergoing a major redesign, the opportunity should be taken to discontinue its use.
However, in the interim, of those sites using frameset, almost all (91%) currently omit titles from frames. Accordingly, where frameset does continue to be used, we strongly recommend the basic step of providing appropriate frame titles as a matter of urgency. In general this requires a very modest effort, and has a significant positive impact on accessibility to such sites for a variety of users with disabilities.
Discontinue the use of obsolete frameset technology. If not immediately possible, make sure that the settings related to its use are fully accessible
See Section 5.2 for full list of recommendations
‘Provide a text equivalent for every non-text element’ (WCAG 1.0 Checkpoint 1.1 – Priority 1)
Chart 9c Image map area ‘alt text’ (Level A)
Image maps are used to provide complex ‘clickable’ images, where clicking in different parts of the image follows a different hyperlink. They are commonly used to implement graphical navigation bars. In this study, their use was quite extensive, with over 33% of sites having at least one example.
As with simple images, the image map technique presents potential access barriers, particularly for users with vision impairment. Similarly, the solution is to associate appropriate alternative texts with each image map area, and thus with each distinct hyperlink. The user's assistive technology can then render the navigational possibilities in a tailored, accessible, form.
Image maps differ somewhat from generic images in their impact on accessibility. Firstly, as they are often used to implement critical site navigation features, they can have a fundamental and pervasive impact on overall site accessibility if they are inaccessible. Secondly, when used in this way, typically they arise in the form of one or more site-wide templates, and so repair (adding appropriate text alternatives) can often be a very simple and quick process, even on otherwise very large or complex sites.
As a result, and particularly given the relatively small intervention that is often required, we strongly recommend that web developers should repair these defects.
‘Provide a text equivalent for every non-text element’ (WCAG 1.0 Checkpoint 1.1 – Priority 1)
Chart 9d NOFRAMEs ‘alt text’ (Level A)
This defect again relates to the use of frameset technology. The ‘noframes’ element is intended to provide an alternative access mechanism in cases where a user's browser does not support frameset at all. If a site must use frameset, it should code frame titles correctly and also provide an appropriate and functional ‘noframes’ element.
Only 10% of sites overall omit the ‘noframes’ element. However, this constitutes over 30% of sites that do use frameset. Moreover, manual inspection of a sample of these sites shows that, even where a ‘noframes’ element is identified, the content is often found to be an ineffective alternative, i.e. a statement that the site requires a browser which supports frameset. Therefore, it is likely that the incidence of satisfactory frames alternatives is lower than the raw data suggests.
Nevertheless, there is ongoing debate within the web accessibility community about the practical impact of the ‘noframes’ mechanism. All current browsers with substantial practical deployment, including text-only browsers such as Lynx, now support frameset directly. A requirement for ‘noframes’ is separately and explicitly mentioned in WCAG 1.0 checkpoint 6.5, but that is at Priority 2
Furthermore, in contrast to the provision of frame titles, designing and deploying truly equivalent ‘noframes’ content requires a larger development investment.
In these circumstances, we do not regard provision of ‘noframes’ content as a high priority for remedy. It would be better to address the requirement for frame titles and, ideally, to move away from the use of frameset technology entirely.
Provide a text equivalent for every non-text element’ (WCAG 1.0 Checkpoint 1.1 – Priority 1)
Chart 9e Applet ‘alt text’ (Level A)
Applets are small applications or programs embedded within web pages. They can pose particular barriers for assistive technologies. Therefore, the W3C WAI guidelines recommend that all applets should include a text alternative. This should, as far as possible, provide equivalent functionality for any user who cannot access the applet.
Only 1.4% of sites were identified as failing this check. However, this does represent 40% of all sites that used applets. In addition, where applets are used, they may provide crucial components of site functionality. Therefore the absence of a text equivalent may represent a very serious accessibility barrier.
Manual investigation of a sample of the applets identified showed that most of them were used to implement scrolling ‘ticker-tape’ displays of news items. This is a somewhat dubious technique on general usability grounds. If it must be used, then it is important to ensure that the information (and linkage, if applicable) presented is also made available by other means, whether via the ‘alt’ attribute of the applet element or otherwise.
We identified one complex transactional site that relied critically on Java applets for its functionality. Although some of the applets had text alternatives, these served only to advise that the service was unusable without Java applet support. There was no statement or advice regarding access issues for users with disabilities, and there was no indication that accessibility was considered in the design process. In this type of case, where an important e-government service is being provided through this mechanism, it should be a high priority to implement a comprehensive accessibility review. This review should consider carefully both the provision of alternatives to the particular applet and also the accessibility issues for users with disability who have Java support. The latter is addressed in WCAG 1.0 Checkpoint 8.1 (‘Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies’), and would be classified as Priority 1 in this case.
‘Provide a text equivalent for every non-text element’ (WCAG 1.0 Checkpoint 1.1 – Priority 1)
As already discussed, text alternatives should be provided for all images, to facilitate users who cannot perceive the image. The automated evaluations picked out sites where text alternatives are simply missing; however, in the case that alternatives are present, manual evaluation is required to assess whether they are actually appropriate. There was a practical difficulty here about the methodology, because the evaluators were not fluent in all the different languages of the 25 Member States, and so could assess the suitability of text alternatives in only a minority of cases. Nonetheless, a number of images were found to have ineffective text alternatives; given the limitations in the evaluation, it is likely that this problem is, in fact, even more extensive. The images with ineffective text alternatives include:
'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.' (WCAG 1.0 Checkpoint 6.3 – Priority 1)
'Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.' (WCAG 1.0 Checkpoint 8.1 – Priority 1/2)
Javascript is software code embedded within a web page, usually in order to add extra user functionality or interaction. Typically, in the sites encountered it was used for adding more dynamic ‘drop-down’ functionality to menus. The use of Javascript potentially poses additional barriers to users with a variety of disabilities because it may not interoperate properly with their assistive technologies. (It should also be noted that, for security reasons, Javascript may be disabled for many users.) This can be a very serious barrier if it prevents access to critical navigation functions of a site. For example, a significant number of sites were identified where important Javascript functionality was not usable through keyboard interaction. This directly excludes users with a variety of disabilities who cannot use a mouse or other pointer-type input device. It should be emphasised that Javascript is potentially a very useful technology, and designers should not be discouraged from applying it, where appropriate. Indeed, in certain cases, Javascript can enhance functionality for a variety of users, sometimes particularly including those with certain disabilities. For example, one site in this study used Javascript to make it easier for users to adjust the styling of the site presentation to suit their needs (colours, text size, etc.) which clearly facilitates accessibility in certain circumstances. Nevertheless, where Javascript is used, designers should take care to ensure both that it is coded with accessibility in mind, and also that any important functionality is still available even if Javascript is disabled.
'Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).' (WCAG 1.0 Checkpoint 4.1 – Priority 1)
Certain assistive technologies (in particular, speech synthesisers and Braille displays) need to know the natural language of a text in order to render the information intelligibly for a user. This is most critical where a single page includes text in more than one language. It is then essential that each change in the natural language be explicitly marked so that the assistive technology can adapt as necessary. It should be noted that the provision of multi-lingual websites is very helpful to a wide variety of users, including those with various disabilities, and is strongly to be encouraged. However, where this is being done, the minor additional effort to ensure that natural language use is made technically explicit should be incorporated in the authoring process. Indeed, authoring tools may be able to actively assist authors in marking changes in natural language use, provided that authors are trained effectively in their use.
'For data tables, identify row and column headers.' (WCAG 1.0 Checkpoint 5.1 – Priority 1)
'For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.' (WCAG 1.0 Checkpoint 5.2 – Priority 1)
Tables are used in web pages in two quite different ways:
Perception of tables presents particular problems for users with visual disabilities, who cannot scan the two-dimensional structure of the table visually.
Layout tables are, generally, now discouraged, as the same effects can be achieved more flexibly and adaptably using style sheets instead (CSS). However, if tables are still used for layout, then they should specifically not use ‘mark-up’ that is intended only for data tables, such as identifying certain cells as row or column headers. Otherwise, such tables may wrongly trigger special features of assistive technologies that are intended only for dealing with data tables. At the very least this can be very frustrating for such users.
Data tables can and should be used where data has a genuine tabular structure. In this case, however, it is essential to make the structure as explicit as possible to facilitate the navigation of the table by users who cannot directly perceive this structure visually. In particular, column and/or row headers must be marked as such. If a table is complex with multiple levels of structure, then additional mark-up may be needed to more precisely indicate the mutual relationships between different items of information. Again, achieving this relies critically on training of relevant content authors in how to implement good table design using their given authoring tools.
'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.' (WCAG 1.0 Checkpoint 6.3 Priority 1)
‘Provide a text equivalent for every non-text element’ (WCAG 1.0 Checkpoint 1.1 Priority 1)
By ‘rich media’, we mean audio and video resources, animations, and so on. In general, this study found relatively few examples, but the number can be expected to increase in the future, particularly as broadband allows more practical access to such resources. Rich media can bring particular benefits to users with a variety of disabilities. Users can have increased options to select combinations of media that suit better their particular needs and skills. For example, a speech recording on the web may be directly accessible to a person with a vision impairment, but totally inaccessible to a person who is deaf. But if that audio file is accompanied with a full text transcript, then each user can choose the form best suited to that person.
However, this presupposes that multi-media complement each other rather than act as mutually exclusive alternatives. In fact, some examples were encountered in the present study where particular resources were made available exclusively in one (audio-visual) media type. While this clearly facilitates some users, it is also relatively inflexible in adapting to many people with other needs and preferences, particularly those who cannot see, or hear, or interact graphically etc.
So, the use of multi-media is to be specifically encouraged on general accessibility grounds, but it should incorporate applicable accessibility features (e.g. synchronisation of media alternatives, audio description, etc.) and also be complemented with generic functional equivalents (typically text-based) that can be adapted to the widest variety of potential users.
This section reviews the results from a number of tests relating to WCAG 1.0 Priority 2 checkpoints. These are important in order to meet the policy objective of Level Double-A conformance. However, the Priority 1 checks already discussed are the most immediately pressing areas identified for intervention. Most of the checks reviewed here relate to issues where results depend critically on improvements in content management systems or authoring tools. These issues are of long-term importance to improving web accessibility. Web developers still have a key role to play, particularly through the incorporation of these requirements into procurement policies.
Chart 10 Reasons for non-conformance (Level Double A)
‘All web-based resources should validate to published formal grammars.’ (WCAG 1.0 Checkpoint 3.2 – Priority 2)
The force of this checkpoint is that the resources should be structured or formatted in accordance with a clear and public technical specification. The rationale is that such technical validation against known, public, formats is the best way of ensuring consistent and reliable interoperability between the hugely diverse, and constantly evolving, systems that constitute the web.
The early, explosive days of the web saw a phase when technical standards evolved very rapidly and technically skilled content developers were scarce. In that situation it became common for websites to be ‘hand-crafted’, to work well only with certain popular browsers, in typical configurations (screen or window size etc.), rather than for generic compatibility with any standards-based browsing platform or device. Each time a new user technology was deployed (even just a significantly new version of a browser), it was necessary to re-test and reconfigure the design to suit the new situation, without ‘breaking’ backwards compatibility with the previous systems. In addition, browser developers created several proprietary extensions to standard HTML that would only work with their own browsers in order to get competitive advantages over their rivals. However, it is now clear that this is not a sustainable long-term strategy. Recent years have seen a consistent trend towards ‘standards-based’ web design, illustrated, for example, by the Web Standards Project (WaSP) (see http://www.webstandards.org) [External site].
These developments affect all web users, but they have a particular impact on users with disabilities. Many of these users are heavily reliant on special-purpose assistive technologies. By their nature, these technologies are devised for relatively specialised and small user groups. So, whereas users of dominant or mainstream technologies can generally assume that websites and services will be explicitly tested and guaranteed to work with those technologies, users of specialist or minority systems must rely much more heavily on sites being generically interoperable – through conformance with open technical standards.
However, despite recent progress towards ‘standards-based’ web design, the vast majority of web-based resources continue to demonstrate very poor conformance with technical standards. Hence, the finding in the current study, that 99% of the sites evaluated still have significant problems in this area, is completely consistent with findings from other similar studies.
As noted, there is a particular role here for procurement policy. It is likely that an explicit requirement to adhere to standards on any web content development or authoring systems, built into procurement documents, and suitably verified, would have a significant impact in driving the improvement of conformance with formal standards in these technologies. In the shorter term, useful progress may be made by deploying server-side systems dynamically to coerce HTML to conform with standards as it is being served (see, for example, the mod_tidy module for the Apache web server at http://mod-tidy.sourceforge.net/) [External website]. In addition, automated tools are available to test the validity of (X)HTML CSS and other formats used.
It should be acknowledged that improving standards conformance does not generally have the same immediate and tangible effect on accessibility, as, say, providing text alternatives for images, ensuring keyboard accessibility of user interactions, or offering full text transcripts of audio material.
‘Avoid deprecated features of W3C technologies.’ (WCAG1.0 Checkpoint 11.2 – Priority 2)
For the most part, this check is concerned with HTML features that originally appeared in early versions of HTML but have since been superseded by alternative mechanisms, most prominently the use of style sheets, such as Cascading Style Sheets (CSS). Style sheets support the effective separation of web page content and presentation, which, in turn, facilitates the flexible adjustment of presentation to best suit the particular needs of any individual user. In the current study, it was found that over 97% of sites did make some use of CSS; however, an almost identical proportion also still make significant use of a variety of deprecated HTML features that would be better implemented via style sheets.
In order to realise the potential benefits of CSS for personalised presentation, it is important that it be embraced fully for all aspects of presentation, and that use of the deprecated, HTML-based presentational mechanisms be discontinued. As with HTML validity, this is largely an issue for web content development and authoring tools, and again, intervention through public procurement policies will have a significant impact in improving this situation. Similar to the requirement for well-formed (X)HTML, detection of deprecated features is something that can be verified easily and unambiguously through the use of validators or schemas.
‘Use relative rather than absolute units in mark-up language attribute values and style sheet property values
(WCAG 1.0 Checkpoint 3.4 – Priority 2)
These two issues relate to facilitating flexible visual presentation of web pages. The layout and overall visual formatting can either be ‘rigid’, where elements of the page are directed to appear in absolute sizes and positions on a screen, or ‘fluid’, where elements of the page have hints about relative sizes and positioning, but can be flexibly scaled or rearranged to suit the particular display available. Fluid layout and formatting allows text size, in particular, to be easily scaled up and down, and the entire page layout to adjust dynamically, flowing into the available width and avoiding horizontal scrolling if possible.
This particularly facilitates people with intermediate levels of vision impairment – a very large, and growing, user group, but it also delivers benefits to many mainstream users. For example, it facilitates browsing on hand-held devices such as PDAs and mobile phones, and scaling up pages for effective display on projection systems.
With failure rates of 89% and 74% for the two items reported here, it is clear that such fluid coding of web pages is still not widely deployed. Again, content development and authoring tools play a large role in this, and intervention via procurement policy is particularly important in bringing about improvements.
‘Use header elements to convey document structure and use them according to specification’.(WCAG 1.0 Checkpoint 3.5 – Priority 2)
These two checks both relate to the appropriate use of HTML ‘header elements’ to implement hierarchical structure in a web page. This is particularly useful to non-visual users, or visual users with high magnification, where it is very difficult to scan within a page. It also helps users with a variety of cognitive disabilities who benefit from additional navigational supports. Suitably configured browsers can use the header information to present all these users with additional, hierarchical, in-page navigation.
With failure rates of 39% and 28% for the two items reported here, this is a significant issue. Improvement depends partly on support in authoring/content development tools; however, most tools currently deployed do actually permit proper use of headers, although they may not prevent improper use. Accordingly, a significant improvement here probably requires active intervention in training for content developers and authors.
‘Provide metadata to add semantic information to pages and sites.’ (WCAG 1.0 Checkpoint 13.2 – Priority 2)
The ‘title’ element in a web page is a form of metadata. In this particular case, it is intended to provide a brief, informative title for the particular page. It is typically used by browsers to label the window or tab in which the page is displayed; and is normally used as the default label for the page in bookmarks or shortcuts. Search engines will also typically use this as a brief label for a page when including it in a listing of search results. Clearly then, appropriate title elements are valuable for a variety of purposes and improve site usability for all users, but they are especially helpful to users who have difficulty with fast scanning, memory or navigation between browser windows or tabs, i.e. users affected by a variety of visual and/or cognitive disabilities.
This was a pervasive problem on 12% of sites, and affected at least some pages on an additional 20% of sites. Further, this particular automated check only tested whether a title element was present, but it did not assess whether a given title element was meaningful or appropriate. Accordingly, the actual failure rate is probably somewhat higher again. As with appropriate use of headers, improvement in this does need some support in content authoring and development tools, but is primarily an issue for adequate training of content developers and authors.
Make sure that all content commissioners and authors are fully trained in the importance of accessible content, and in the means that are made available to them to achieve this.
See Section 5.2 for full list of recommendations
The analysis of non-conformance with Level A and Level Double-A can be brought together to form an action plan for improving eAccessibility. The priorities set out below take account of two important criteria – the ease of execution and the impact for disabled users.
The automated tests confirm that:
The manual tests confirm that:
The automated tests confirm that:
The automated tests confirm that:
The manual tests confirm that
The manual tests confirm that:
The automated tests confirm that:
The manual tests confirm that:
Looking beyond these priorities, we can see that today’s problems should not be perpetuated by continuing with current procurement and training practices. Action should be taken by policy-makers and practitioners to ensure that new procurements have in-built accessibility requirements and that all those involved in web development and support are trained to keep websites accessible.
Plan now to get existing sites up to at least Level A in the short term (by the end of 2006) and to achieve Level Double-A in the mid-term (by end of 2008), prioritising carefully work applied to individual sites in order to enable the quickest resolution of the most common problems that will achieve the biggest impact.
Make sure that all content commissioners and authors are fully trained in the importance of accessible content, and in the means that are made available for them to achieve this.
Build applicable W3C WAI guideline requirements into all public procurements of new website designs, major upgrades, and into all outsourced content production (such as reports, publications etc)
See Section 5.2 for full list of recommendations
Produce software tools that conform with Authoring Tool Accessibility Guidelines (ATAG1.0) to at least Level Double-A, and/or with the User Agent Accessibility Guidelines (UAAG 1.0) as applicable, (including open source software).
Build the W3C WAI guidelines into industry codes of practice.
Train all web designers in both the requirement for, and the techniques to achieve, fully accessible websites.
Develop a competence framework for web designers that includes web accessibility and use it for personal development schemes and recruitment campaigns.
See Section 5.2 for full list of recommendations
Produce by 2006 a short-term public plan that enables a clear measurable improvement for all websites delivering public services.
Ensure that government policy now builds applicable W3C WAI guideline requirements into all public procurements of new website designs, major upgrades, and all outsourced content production (such as reports, publications etc). In the case of software procurement, such requirements should apply equally regardless of the licensing model (open- or closed-source).
See Section 5.2 for full list of recommendations
Ensure that EU public procurement government policy now builds applicable W3C WAI guideline requirements into all procurements of new website designs, major upgrades, and all outsourced content production (such as reports, publications etc).
Carry out a feasibility study in 2006 into the development of an appropriate qualification in accessible websites for developers, managers and content providers (perhaps aligned with the European Computer Driving Licence).
See Section 5.2 for full list of recommendations