Accessibility is based upon a ratio off 60% Priority 1(A) and 40% Priority 2 (AA). This reflects the importance of Priority 1 over Priority 2.

The Web Accessibility Center at Ohio State University holds regular workshops on how to meet various standards and accessibility guidelines, their online archive displays some of their work.

eAccessibility Country Information

eAccessibility Country Information is data gathered by the eInclusion@EU project and National Correspondents attached to the project. The contry information investigates the situation on various eAccessibility related issues for each country.

Articles

Commission calls for coordinated action to make information and communication technologies more accessible for citizens

Coordinated action by EU Member States is needed to make information and communication technologies (ICTs) more accessible to all, and particularly to people with disabilities and some older persons, said the European Commission today. In a Communication on “Electronic Accessibility” (eAccessibility), adopted today, the Commission calls upon Member States to do more to promote EU e-Accessibility initiatives in a concerted approach and to encourage uptake by industry. Progress will be reviewed two years from now, when additional measures may be proposed, including new legislation if necessary.

Commission takes low profile on e-accessibility

The Commission has opted for a careful approach to integrating senior citizens and people with disabilities into the information society, favouring standardisation over regulation.

Tables are intended to display tabular data, their use to control layout should be discouraged but not ruled out. Instead the use of additional mark-up can ensure a page remains accessible to all.

Guideline 5 of WCAG 1.0 covers several recommendations under the banner "Create tables that transform gracefully":

• For data tables, identify row and column headers

  The TH tag should be used to clearly define and separate the header cells of a table.

• For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells

  Complex tables may require a hierarchy of headers, for example to separate rows into groups by location. The W3C describe several examples of how to achieve logical headings

• Do not use tables for layout unless the table makes sense when linearized

  In order for a screen reader of another accessibility tool to interpret a page the content is simplified, linearisation is the process of turning such a page into one long document. Tables add extra work to this process, inadvertently a screen reader may separate two page elements which should be together. This can be difficult for a developer to imagine and test.

  Sitemorse recommends the command line browser Lynx, for this and many other tests, to experience a site in it's most basic manner. Additionally Firefox users with the Web Developer Extension have the option under Miscellaneous to "Linearize Page" and witness the result

• If a table is used for layout, do not use any structural markup for the purpose of visual formatting

  The tags mentioned earlier for tabular data must not be misused. The TH tag must always refer to a column heading never just the first cell of a table, or to make the contents central and bold. CSS can achieve the same result and not interfere with accessibility aids.

• Provide summaries for tables

  Summary text can be read by screen readers as a general descriptor of the tables purpose or a synopsis of the data content.

  <table summary="This table charts the number cities in the UK and their respective populations">

  Additionally tabular data tables should contain a caption providing a more concise description of the tables purpose and whether the visitor need view the table.

  <table summary="This table charts the number cities in the UK and their respective populations"> <caption>Population by City</caption>

• Provide abbreviations for header labels

  A visitor using a screen reader may tire of the full column name, if appropriate provide a shorter alternative

  <th abbr="Population">Population, rounded to nearest thousand</th>

Sitemorse will report a 'wcag10/linktarget' diagnostic when the same link text is used for different target URLs. An important aspect of link text is its uniqueness. Typically a web page may link to several resources, either directing the user to different parts of the same page, or to different pages altogether.

Each link to a different target must have a unique description text, allowing users to quickly, and unambiguously, locate content on a page.

Take, for instance, a page which links to company reports:

<p>Company ABC <a href="reportABC.html">report</a></p> <p>Company XYZ <a href="reportXYZ.html">report</a></p>

The link text in both cases is simply "report", the description is not unique.

To resolve this alter the link text to ensure uniqueness:

<p><a href="reportABC.html">Company ABC report</a></p> <p><a href="reportXYZ.html">Company XYZ report</a></p>

Alternatively Sitemorse also takes into account the 'title' attribute. Thus the following example is also permitted:

<p>Company ABC <a href="reportABC.html" title="Company ABC">report</a></p> <p>Company XYZ <a href="reportXYZ.html" title="Company XYZ">report</a></p>

In this example the first solution is certainly desirable.

Further information:

HTML 4.01 Specification - Chapter 12 Links

The option to include a set of tools to adjust the screen font sizes is not a requirement of the Web Content Accessibility Guidelines.

As ever, the basic principle is that all the content should be accessible to people who need to vary the font size. Therefore there are a couple of points to note:

• as usual, all non-textual content must have textual equivalents (e.g. "alt" attributes for images),
• stylesheets should specify font sizes in relative units (e.g. "120%" or "1.2em" rather than "14pt" or "20px"),
• the site layout should be tested with varying font sizes (using the 'font size' control in the browser) in order to ensure that the layout still works with non-default font sizes.

There is no need to add a separate control to vary the font size on the web site. Users' browsers already have this control built-in to their web browser, which, if the rules above are followed, will work perfectly well with no assistance required from the web site itself.

Some people like to add such a feature regardless, perhaps as a "visible demonstration" of commitment to accessibility. break any rules.

All images must supply a text equivalent. The term "text equivalent" can be "nothing" - the simplest example being "spacer gifs" which are completely blank and therefore clearly provide no additional content.

Purely decorative images, such as work colleagues standing outside your business, serve as a visual break, dividing content and enhancing readability. An imaginative alternative text could be supplied, such as "image of employees posing dramatically against a blue sky" - but that's a description of the image rather than an alternative text, and it would not help someone who couldn't see the image to understand the page or use the site.