This section ensures that a UK government website is developed to serve the largest possible audience using the broadest range of systems (hardware and software platforms) and that the needs of users with disabilities are considered.
We cannot count on our users having standard technology, therefore, to ensure access to our information on the web the onus is on our web managers to deliver the message in a way that allows everyone to benefit.
It is very important that your organisation’s website is not only user-centered and usable at the outset but maintains that level of accessibility and usability throughout its existence.
Use each checklist to ensure that your web pages comply with these guidelines.
2.4.1 Checklist and summary: Core guidance
A myth surrounding website development is that building accessible and inclusive pages is expensive, they have to be dull and boring, and they have to be written for the lowest common denominator - this is not the case! It is also not the case that users must view a web page the way the designer intended. With the range of browsers, screen sizes, colour depths and other user preferences it is often not possible to have a web page look the same to all users.
What is important is that users should be able to view a web page the way they wish to view it with the equipment that they have available and avoid those negative experiences that result in losing repeat visits.
Integrating accessibility into your web development process efficiently creates websites that work effectively for more people in more situations - and that means more users. The challenge to your web developers has to be in creating web pages that are both visually appealing and fully accessible to a wide range of users.
We are moving into a world in which managing different versions of your content will become the norm. You will provide different content for different media such as mobile devices. You are likely to design and write content in order to communicate with different audiences as well. The advent of broadband access will mean that more multimedia content will also be appropriate.
Equally, to make a website inclusive, there needs to be alternatives to support people and systems with differing abilities. This is not just an issue for the disabled. Some corporate systems are protected by firewalls that strip out active content. Accessibility is also an issue when communicating with a business audience.
The sighted web user gets a good sense of the content and scope of a web document at a glance. The layout and navigation should enable users to quickly find a specific part of the document.
When using screen readers and screen magnifiers only a small part of the screen can be presented at one time. So website users who are dependent upon this technology may have three immediate difficulties:
For example, screen readers only communicate what the browser or operating system renders. This information is revealed by listening to a synthesised voice or Braille display that presents only text and which ‘speaks’ one piece of information at a time in a serial fashion.
Moving from accessibility to usability. Accessibility means that a broad range of software and audiences can actually receive your content. It is now mandatory that government websites comply with the minimum level of the World Wide Web Consortiums Web Accessibility Initiative.
However, compliance with WAI recommendations alone does not necessarily mean that a website will meet the needs of different users. This is the difference between accessibility and usability. With careful consideration the site can be written and designed so that it works well when browsed through screen readers or screen magnifiers. For example:
Text only versions. Ideally a website should be both accessible and useable. Some websites rely on a non-graphic, text-only version to make their sites accessible. But a text-only version may not be useable if, for example, it contains too many links or is confusing when presented through assistive technology. It is essential to ensure that content is complete and up-to-date.
Rather than invest in a text-only version that is not useable, it may be better to clarify the navigation and text to improve usability as well. We would prefer you made the graphic version of your website more usable, taking steps such as reducing numbers of links and clearly describing options and navigation.
Where you are using multimedia or plug-ins, such as Macromedia’s Flash, we would prefer that the user accesses (as the default) a usable website with an option to choose to use a multimedia alternative rather than being delivered the multimedia version as the default with an option to choose the alternative.
2.4.2 Audiences with special needs
There are many people who find it difficult to interact with computer technologies. One of the ways in which government websites differ from commercial sites is the requirement that the needs of these audiences are part of our website strategies.
22.214.171.124 Key audiences to remember
The inexperienced or technophobic
Electronic devices such as video recorders and microwave ovens cause confusion for some people. Others have little experience of computers. For both audiences, the inherent complexities of a home computer can make retrieving information from the web very difficult.
The socially excluded
A proportion of the public do not have the means to purchase a home computer. Their job may not bring them into contact with IT and a digital TV may be out of the question. A PC with limited capabilities in the local library may be the only resource available to this sector of the population.
Advancing years can bring one or a combination of the disabilities listed in section 126.96.36.199 to a user.
Many people in the UK do not use English as their first language. Extra care should be taken to ensure that the English used on a web page is clear and simple to understand.
188.8.131.52 Physical impairments
Recent disability figures for the UK suggest that there are:
It is worthwhile remembering that impairments take a variety of forms and can exist together in combination.
Specific considerations for the common disabilities are as follows;
The web is superficially seen as a visual medium, but as the majority of information in a website is in text format there are many ways in which this data can be manipulated. Screen reader software reads a web page one line at a time, horizontally across the screen. The text is spoken using a speech synthesiser or alternatively sent to a retractable Braille display or to a fixed single line display. Screen magnification software is used to magnify portions of a screen using a zoom feature. Many people who have visual impairment still have a degree of usable vision. Simply using clear fonts and distinguishable colours may be all that is needed.
Many people with auditory disabilities have little difficulty in using websites unless streaming audio and video files are used. This can be overcome simply with the use of text captioning. This also assists those non-native speakers who may find written language easier than spoken.
Many diseases and physical conditions can cause a person to have a loss or limitation of function in muscle control or movement, which can mean difficulty in using a conventional keyboard or a mouse. Software such as, Sticky Keys can make difficult keystrokes more accessible and WAI offers the ability to assign hotkeys to navigation elements. The use of speech recognition systems allows the user to speak commands to their computer. Other alternative input devices include pointer devices and eye scanning systems controlled by mouth or head movements.
Reading difficulties such as dyslexia and limited mental agility can all limit the understanding of information. Users may have problems with memory recall or text recognition; they may also have problems entering information correctly, such as querying a search facility.
Flickering and flashing text or images can trigger epileptic seizures in some individuals and do not encourage usability among the visually impaired.
Important: A very simple if not comprehensive way of seeing your existing website in a different light is to turn off the graphics capabilities of your web browser. This will give an indication of your site’s usefulness without graphics.
2.4.3 Compliance with W3C WAI recommendations
184.108.40.206 W3C Web Accessibility Initiative (WAI)
Many people that use the web have disabilities of one form or another, which could be sensory or motor disabilities. It is very important to ensure that any web page produced by public sector bodies is as available to these users as to any other. Government websites are now expected to comply with the W3C WAI recommendations.
The W3C states that there are basically ten quick tips that should be used to produce web pages that can be seen as truly accessible. They are listed as:
220.127.116.11 The 14 guidelines of the Web Content Accessibility Guidelines 1.0
To ensure that your organisation’s website is universally accessible, the following WCAG 1.0 Guidelines should be considered and implemented:
18.104.22.168 Implementation of the W3C WAI ‘A’ rating
A website can be rated at one of three Web Content Accessibility Guidelines conformance levels - A (Priority 1 items), AA (Priority 1 and 2 items) and AAA (Priority 1, 2 and 3 items).
All UK government websites are expected to achieve, as a minimum, and adhere to the single ‘A’ (Priority 1 items) level. When this has been completed the W3C WAI logo can be displayed on the website home page, if required.
If this mark is not achieved, one or more groups will find it difficult to access information on your site. Satisfying this checkpoint is a basic requirement for some groups of the user population to be able to use web documents. The following checklist must be completed before a webpage can be considered to have attained this mark.
In general the para references below are to WCAG 1.0 Priority 1 checkpoints:
1.1 Provide a text equivalent for every non-text element (eg via ‘alt’, "longdesc"’ or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (eg animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks and video.
2.1 Ensure that all information conveyed with colour is also available without colour, for example from context or mark up.
4.1 Clearly identify changes in the natural language of a document's text and any text equivalents, eg captions.
6.1 Organise documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.
6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes.
7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.
14.1 Use the clearest and simplest language appropriate for a site's content.
…and if you use images and imagemaps
1.2 Provide redundant text links for each active region of a server-side image map.
9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
…and if you use tables
5.1 For data tables, identify row and column headers.
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.
…and if you use frames
12.1 Title each frame to facilitate frame identification and navigation.
…and if you use scripts and applets
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.
…and if you use multimedia
1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation.
1.4 For any time-based multimedia presentation (eg a movie or animation), synchronise equivalent alternatives, (eg captions or auditory descriptions of the visual track) with the presentation.
…and if all else fails
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.
2.4.4 UK Government accesskeys standard
The accesskey attribute, introduced in HTML4.0, is intended to provide keyboard shortcuts in that they provide an alternative form of navigation.
This attribute should be added to the hypertext link element within an HTML page as follows.
<a href=http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/”whatsnew.htm” accesskey=”2”> What’s New </a>
This addition allows users with limited physical capabilities to navigate the organisation’s website more easily. There are some drawbacks, for example:
In the example above, the organisation’s What’s New page has a ‘2’ value given which should be used consistently throughout the Website.
When a user visits your department’s website for the first time they bring their collective experience gained from all other sites. It is, therefore, important that UK Government Websites adopt a constant accesskeys standard. Variations from this will make it more difficult for users as they have to learn new navigational skills each time.
Listed below is the recommended UK Government accesskeys standard:
S - Skip navigation
1 - Home page
2 - What's new
3 - Site map
4 - Search
5 - Frequently Asked Questions (FAQ)
6 - Help
7 - Complaints procedure
8 - Terms and conditions
9 - Feedback form
0 - Access key details
When this navigational system is made available, it is important to inform your website users, as soon as they enter. Otherwise, users who are least able to do so will be faced with a mouse-dependent navigational system that could have been bypassed. Each page could display a message, e.g. ‘UK government accesskeys system’
Web managers can extend this system by attributing any one of the other 25 alphabetic characters to pages within their website but should ensure that the core elements listed above are used. It is important to ensure that the additional keys selected do not compromise shortcut keys used by various browsers, e.g., Microsoft Internet Explorer ‘alt h’ drops down the help menu.
2.4.5 Other accessibility considerations
22.214.171.124 Download speeds and accessibility
Bandwidth or the capacity to send and receive data is an important consideration when designing an electronic document for distribution over the Internet. It is important that the link to the Internet (from the computer serving the pages to customers) has sufficient capacity to be able to handle the expected load. Otherwise, the response to users will be unsatisfactorily slow.
Most people today connect to the Internet over a phone line, typically using a modem with a speed of 28.8 to 56 kilobits per second (kbit/s). This ‘narrowband’ communication requires user to wait while a dial-up connection is made before they can access the Internet, and means that Internet use when connected is slow.
Broadband services offer significantly faster data rates, enabling the delivery of services, such as high speed Internet access. These may also be ‘always on’ connections to the Internet.
However, what looks great and downloads quickly within the confines of the Web manager’s high-speed network connection does not necessarily work as well for the average user of the Internet. It is probably best to presume that your user is connected through a 28.8 kbit/s modem. Documents published on the web need to be kept small, be linked efficiently and contain only the data and graphics that they require.
126.96.36.199 Colour blindness and clarity
Usability for people with visual disabilities difficulties must always be a primary consideration.
When designing a website be aware that complicated background patterns can make it difficult for viewers with low vision and difficulties, such as dyslexia, to interpret foreground information, such as text and hyperlinks.
188.8.131.52 Splash screens and accessibility
Some websites use splash screens to introduce the contents of the entire site or a particular section. Such pages, usually containing an image and a brief line of text, are displayed on screen for a set period of time before automatically redirecting the browser to another more descriptive page.
Although this technique can be appealing it has limited use and can seriously hinder the accessibility of a website. Some browsers are not capable of following this sort of automatic redirection.
It is strongly advised that Web managers do not employ this feature. A W3C recommendation is not to use client-side redirects.
184.108.40.206 Styling pages for accessibility
Important: See how your site looks on a browser that cannot use Cascading Style Sheets by disabling the link to the CSS in the HTML file. Now when it is viewed in the browser you will see the data without the styling.
220.127.116.11 Accessibility with drop down menus and pop-up windows
Drop down menus:
See section 18.104.22.168 Scripts and accessibility
22.214.171.124 Accessible images
126.96.36.199 Accessible multimedia
Multimedia content is becoming more common on websites, although the large file sizes and long download times can make this delivery method an unwelcome feature.
When you link to an audio or video file, indicate to the user its format (e.g., .wav, .au) and size. Do not assume that the user has the requisite media-player software so provide clear instructions on how to obtain this software. Beyond the technical difficulties of installing such software, some firewalls may not actually permit the passage of this material.
Auditory content, e.g. recorded voice or music, may be inaccessible to users who have a hearing impairment and will be inaccessible to those with computers with no audio capability or who do not have, or cannot use (because of a firewall), the plug-ins necessary to do the playback.
188.8.131.52 Accessible text
184.108.40.206 Accessible lists
220.127.116.11 Accessible tables
Avoid using tables to arrange text documents in columns.
Provide summary information for a table using the ‘summary’ attribute.
Table width should be set using the “%” value rather than a fixed pixel value. The table will then scale to the user’s displayable area and avoid left to right scrolling (see section 6.3).
Go to 6.3 HTML tables
18.104.22.168 Accessible links
22.214.171.124 Accessible frames
126.96.36.199 Scripts and accessibility
<a href=http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/”logo.htm” onclick=”window.open(‘logo.htm’, ‘popup’, ‘scrollbars, resizable, width=300, height=200’); return false”>
See section 4.6 Client-side scripting and programming.
188.8.131.52 Easy Access
The Easy Access channel applied on the Portal http://www.ukonline.gov.uk addresses accessibility issues. This channel is intended as an option for people who have difficulties using the more graphical channel - whether through lack of experience of using the Internet, or disabilities.
The channel offers enhanced legibility through high contrast, the use of only three colours and minimal use of graphics. The three colours chosen are visible to almost all people with colour blindness. Tab ordering and link indicators aid users of screen reading software. External links do not open a new browser window.
No content is reduced or re-written before it appears in the Easy Access channel - it is taken directly from one database so all content being viewed is the same for all users. Importantly, the channel is not just a text version of a graphical site.
The information displayed is rearranged into a vertical hierarchy. Sections contain enhanced spacing, increased clarity of headings and paragraphs and line separators between different content. Images appear where necessary - such as with the main news article, thus enhancing the experience for people who can see the screen.
This is a method of supporting a ‘WAI ‘A’ site (or an inaccessible website) with an enhanced accessibility channel.
2.4.6 Simple HTML attributes for accessibility
Each of the following examples is simple to implement and takes just a few minutes but can make all the difference to many visitors to your website.
A number of these additions are only available for use when the HTML 4.01 standard is used to construct the page. If HTML 4.01 is to be used, then the author of the document must use the correct DTD, quoted at the very beginning of the HTML file.
This attribute should be added to the hypertext link tag within an HTML page as follows.
<a href=http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/”whatsnew.htm” accesskey=”2”> What’s New </a>
This addition allows users with limited physical capabilities to navigate the organisation’s website more easily. Different browsers work in subtly different ways but most will work if the user holds down the ‘alt’ key and the accesskey value at the same time.
In the example above, the organisations What’s New page has a ‘2’ value given in accordance with the UK Government accesskeys standard. This should be used consistently throughout the website. See section 2.4.4.
184.108.40.206 Alt attribute for accessibility
This attribute should be added to the image tag within an HTML page as follows:
<img src=http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/”logo.gif” alt=”Our organisational logo”>
Keep this attribute short. If used correctly, it will ensure that a meaningful description will be displayed on the browser screen if the link image is unavailable or the browser cannot handle graphics.
Structuring the ‘alt’ attributes correctly allows differentiation between images within the site. The following ‘alt’ attributes could all be used to describe different possible purposes of an image of a magnifying glass:
Icon: magnifying glass - An icon graphic
Link: search - The same image that is a link to a search page
Photo: magnifying glass - A photographic image
<img border=”0” src=http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/”image/photo.gif” alt=”a yacht in harbour” - see long description “width “250” height=”300” longdesc=”aboutyacht.htm”> <:a href=http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/”aboutyacht.htm” [D]</a>
220.127.116.11 Title attribute for accessibility
This attribute can be added to the HTML href element within an HTML page as follows:
<a href=http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/”game.htm” title=”Rules of the game of football”>Football</a>
This word ‘Football’ may make sense to the user who can see the rest of the page but is not clear in itself. The title assists the user with a more descriptive message.
A screen reader will read out the text contained in this attribute, and there is no way of stopping it. An example of a bad implementation of this attribute would be:
<a href=http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/”whatsnew.htm” title=”This link goes to the What’s New section of our website, listing all items that have been added to the site in the past seven days">What’s New</a>
A visually impaired user would have to wait for the entire message in the title attribute to be read and would then have the text element of the page ‘What’s New’ read out as well. This is an example of a link that is self-explanatory and does not require the use of the title attribute.
It is extremely important to control the number of times the title attribute is used in a page. It is very useful if used correctly, but can be cumbersome and disruptive if overused and badly implemented.
The title attribute can also be used within the frame tags. A more detailed explanation of this usage is in section 6.4.
Go to 6.4 HTML frames
18.104.22.168 Summary attribute for accessibility
This attribute should be added to the table element within an HTML page as follows:/p>
<table border=”0” width=”100%” summary=”Cups of coffee sold”>
This attribute must be employed with the same level of control as the title attribute. Correctly used it is helpful and informative. When incorrectly used it will just get in the way.
Be careful to avoid replicating any data already supplied in the <caption> tag or in the table heading.
This attribute is discussed in more detail in section 22.214.171.124.
Go to section4.2 HTML pages
126.96.36.199 Acronym attribute for accessibility
This element can be used within an HTML page as follows:
<acronym=”World Wide Web Consortium”> W3C </acronym>
This element can be employed as many times as is necessary in a page. It can be very helpful to users who do not necessarily understand the shorthand language used within an organisation.
The use of this attribute is immediate when a user hovers their pointing device over a displayed acronym. A box will appear displaying the descriptive text of the acronym. This is important, when for example, a user is directed to the middle of an organisation’s website by a search facility or link from an external body. The organisation-specific acronyms may well all be new to the user and each will need to be explained.
When buying design services it is inadequate for the designer to simply present colour visuals or mock-ups of the look and feel. It is important these are also presented to you as HTML mark up. When you buy web design you are also buying the source coding that will render the visual onto computer screens and the standard of this is the backbone in achieving HTML validation and meeting the mandatory WAI requirements.
2.4.7 Validation and testing
Validation is important in ensuring platform independence, but alone is not sufficient. Developers should ensure that web pages are not dependent on a certain resolution, colour depth or font size. They should test and evaluate an early working version (a beta test) of a site with representative users. This is also known as prototyping.
Well-authored HTML is a highly structured and usable mark up language that is backward compatible ensuring that many web browsers can display information contained within a web page and equally providing accessibility at little or no cost. Although the web is often seen as a visual environment, accessible web pages should adjust and remain accessible in any browsing medium and adapt to allow audio and Braille presentations.
Once the page is completed it can be checked for conformity to a specific version of HTML by running it against the World Wide Web Consortium (W3C) automated validator. Cascading Style Sheets should be validated using the W3C automated validator. Tagged Adobe PDF files should be tested using a screen reader. This will demonstrate how your information will actually be presented to user and how the reading order and navigational links will work. Hyperlinks should be carefully checked.
These validators are available online from the following websites:
188.8.131.52 Bobby testing
It must always be remembered that the W3C WAI is not a standard but a set of guidelines. There is no automatic way in which an organisation can get its website validated against the guidelines.
A page can be compared against the guidelines to raise a Web manager’s awareness of certain issues. The leading tool is The Center for Applied Special Technology’s (CAST) Bobby software.
Individual pages can be run through the Bobby service by visiting the site and typing the page URL into a specific box. The service will scan the page and then return an automated report highlighting areas of concern and suggesting what could be done to rectify them. A downloadable version of Bobby is available for testing an entire site.
The reports can look extremely daunting at first because of their length and quantity of detail but it is a service worth persevering with. It must be noted that this application has a number of limitations:
Getting validation clearances, a successful BOBBY test, and a W3C WAI rating does not necessarily guarantee that your site is, eg, accessible via a screen reader.
Bobby analysing application [External link]
184.108.40.206 The WAVE accessibility test
The Wave accessibility checker, from Pennsylvania’s Initiative on Assistive Technology, is an online service that will check your pages and mark it visually with icons that help you understand how assistive technology will read or display the page. Other useful features are:
Wave accessibility checker [External link]
220.127.116.11 Page Valet
The Page Valet is an online validator with a range of accessibility testing features based on the W3C’s Web Content Accessibility Guidelines. Useful features are:
Page valet validator [External link]
18.104.22.168 A-Prompt Toolkit
The University of Toronto’s Adaptive Technology Resource Centre (ATRC) and the University of Wisconsin’s TRACE Centre have jointly developed the A-Prompt Toolkit. This offline Web accessibility verifier has been designed to check for the three WCAG conformance levels - A (Priority 1 items), AA (Priority 1 and 2 items) and AAA (Priority 1, 2 and 3 items). It also checks for compliance with Section 508 of the US Rehabilitation Act. When accessibility issues are detected the toolkit displays relevant dialog boxes and guides to enable the user to fix a range of problems. Some tasks are semi-automated, such as correcting:
The toolkit can be downloaded to a PC.
A-Prompt Toolkit [External link]
2.4.8 Portable Document Format (PDF) and accessibility
The Portable Document Format (PDF) is widely used in electronic publishing (see section 4.4). It is the universal file format that preserves the look and feel of a document, including the fonts, formatting, colours and graphics, regardless of the application and platform used to originate it. Information in PDF is generally considered inaccessible to web users whose disabilities make it difficult to interact with computer technologies.
Adobe PDFs have become the portable document format standard for government on the World Wide Web but PDF documents cannot be considered as accessible. However, Adobe have taken considerable steps to improve the accessibility of both their Acrobat software and the information contained in their PDF files. Their latest specification (PDF1.4) is incorporated in Acrobat 5.0 and features some of the following usability enhancements:
It is important to understand that your legacy PDF documents: those not originally created using the PDF 1.4 specification will remain inaccessible. To give them a level of accessible you have to either:
22.214.171.124 Make Accessible plug-in
The Acrobat 5.0 Make Accessible plug-in automatically analyses the logical structure of a document and creates a new version of that file that will read more logically with assistive technology. The plug-in allows the users of Acrobat 5.0 for Windows to convert untagged legacy PDF files into tagged Adobe PDF files. A tagged Adobe PDF file is designed to ensure:
126.96.36.199 Accessible checker
The Adobe Accessibility Checker is a tool intended to identify common accessibility problems in Adobe PDF documents. This tool will, eg, check a document for missing ALT information on images, and for unrecognisable character encoding. When found they are logged and reported so that you can choose to fix or ignore the identified problem.
Practical tip if your are a sighted web manager
To get a rough idea how some screen readers interpret information: Sit away from your computer and make sure you cannot see the screen Ask someone to take a rule and lay it horizontally on your computer screen; Ask them to read aloud, without pause, from left hand edge of your screen to the right hand edge; Ask them where there is an illustration to say the word ‘image’ and before any hyperlink say the words ‘link to’; Ask them to continue to continue to move the ruler down one line at a time and read without pause. Better yet, invest in a screenreader yourself - or get an auditor to tell you how useable your pages are on assistive technology.
Adobe online accessibility resource [External link]
2.4.9 W3C work in progress
The W3C’s Web Content Accessibility Guidelines Working Group (WCAG WG) has released a working draft of the Web Content Accessibility Guidelines 2.0. This shows how more generalised, less HTML-specific) WCAG checkpoint might read. These checkpoints explain how to make web content more accessibly to users with disabilities. Working drafts of W3C accessibility guidelines are available at:
2.4.10 Further reading and resources
Don’t forget that all this is just the beginning of the process of ensuring universal accessibility.
Always test your website with a diverse user group. Discussion with other Web managers will only make the task easier. Over time, experience may show that certain elements that were added with the best intentions do not work and they may make extracting data from a page more difficult rather than easier.
A number of manuals and guidelines published by W3C expand on the major themes outlined here. It is recommended that Web managers familiarise themselves with their content. A great deal can be achieved by reading through the W3C guidance on this topic.