Anyway it was nice to see that the indent button no longer uses the BLOCKQUOTE tag to achieve the desired styling, and that the alignment buttons have dispensed with the ‘align’ attribute.

It’s been a bugbear of mine that whilst the developers and designers of a site might be required (& also have a passionate desire) to work to standards, the content providers are being offered tools that makes all that effort redundant. In the case of these particular buttons they would have stopped a page from conforming with the Double-A WCAG 1.0 accessibility requirements and produced invalid XHTML 1.0 Strict code.

So well done moxiecode! Hopefully the other editors have already followed suit, or well do shortly.

As I’ve been testing it out I have been struck by the similarities with the screen magnifier demonstration that I posted about before. There have been discussions in the past about the link between improving your search engine ranking and meeting accessibility requirements through the same techiniques (for example this article on A List Apart). We may find that the (possible) rise of the mobile web continues this trend. For example I’ve noticed that with the iPod I’ve wanted:

• layout and navigation conventions maintained – as with the screen magnifier you need to know where you are on a page and how to get to the content that interests you when you’ve zoomed in to see some detail
• space around links – ironically it’s harder to use some web sites that have been designed for standard handheld devices as you don’t have the same degree of accuracy if you’re pointing at a link with your finger rather than a stylus, this is similar to the experience desktop users will have with poor hand-eye co-ordination
• alternatives to scripting – the iPod Touch doesn’t support Flash at the moment so I’ve come to a shuddering halt with some sites that rely on this technology, so I could find something to see at the Watershed but not St George’s and couldn’t go into sysadmin mode with Google Analytics when I wanted to check up on clients’ websites

I liked the fact that it hasn’t been through their marketing department – the user demonstrating the magnifier obviously has Google as her default home page.

That’s no change since 1999! At that stage we were just discovering the joys of Internet Explorer 5.0 and the Netscape browser was stuck on version 4 (as the Mozilla project that produced Firefox got under way). The first graphical browser had only came out in 1993. So we’re talking about the early days of web design and development when the accessibility working group would have been drafting the recommendation.

In practice this has meant that the guidelines are now addressing problems that are no longer applicable (who after all still uses ASCII art?); new technologies aren’t addressed; old techniques are retained even though better options are now available; and badly drawn-up checkpoints remain on the tick lists for compliance. So it is possible to create an accessible website that doesn’t comply with the WCAG 1.0, and a website that conforms that isn’t as accessible as it could be.

The W3C have been working on a revised standard (since 2002), but there was a furore last year when they made the proposed standard available for ‘final’ comments – for example Joe Clarke’s article To Hell with WCAG 2. Out of that an independent group known as the WCAG Samurai decided to work on providing a set of errata for the current WCAG 1.0 standard – removing parts that didn’t work and bringing it in line with 2007. Their draft version was made public last week, with a final version promised by the end of the month.

After being the butt of numerous April Fools’ announcements, a revised WCAG2 working draft was released last month, with at least another version promised before moving into the final stages of the recommendation process. No deadline has been set. In fact the W3C site states WAI anticipates WCAG 2.0 may be completed in 2007 [my emphasis]. This time round though the draft has been met with more appreciative comments.

I suspect that the WCAG Samurai work might not become a widely used benchmark in its own right. Standards have come from the grassroots in the past, but I would think that there would need to be more of a groundswell of support and lobbying to have say the UK government adopt the WCAG Samurai Errata as their next standard (and from there be taken up by the rest of the public sector).

Instead its legacy might be that it will serve as a source of best practice techniques to be implemented by those of us concerned about accessibility; that it was part of the barrage of criticism that has led to the improved WCAG 2.0 draft and hopefully that it will also serve as a reminder when the W3C starts on the next cycle of amendments.

In the meantime it’s worth starting to look at the WCAG 2.0 drafts – particularly the Quick Reference and  Comparison with WCAG 1.0 documents.

It’s probably aimed more for web developers who need to think about how the overall page is structured, but provides an insight into how someone who can’t see that page finds the content they’re looking for. As you’ll find the text in page titles and links, and the proper use of headings and lists are crucial.

There’s also a link through to a presentation on the history of screen readers which is also worth considering. As with web browsers we can’t assume that our audience has access to the latest, shiniest versions – especially when it comes to assistive technologies such as screen readers since they can also be an expensive investment.

The relevant WCAG 1 checkpoint is:

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

It’s a Priority 2 requirement, so is necessary for Double-A compliance.

Don’t indent with <blockquote>

So the first thing is probably to put some test content into your WYSIWYG editor and try the Indent button. Then look at the HTML code produced to see if it uses <blockquote>. If that is that case then you should only use that button for indenting lists.

The best alternative is to have an indent style added to your stylesheets and for that to be available as an option in your editor. Then you just have to highlight the text and select the style.

The next stop down is to have the style in your stylesheet but you have to go into the HTML code to say where you want to use it. Finally you can use the style attribute to put the formatting in directly.

In both cases you need to find the tag that surrounds the block of text that you want to indent. This is usually going to be a paragraph so you’re looking for <p>. If you’re armed with a class name from your stylesheet, say ‘indented’, then you want to change it to <p class=”indented”>, otherwise you’ll use something like <p style=”margin-left: 20px;”>.

Do mark up quotations

There are two relevant HTML tags – <blockquote> for blocks of text and <q> when it’s part of a block of text (i.e. a phrase within a sentence, etc.). You don’t need to go overboard though and mark up absolutely every piece of speech in your content.

If your normal browser is Internet Explorer and you’ve been using <q> in your content then you might be surprised by additional speech marks appearing in other browsers. Don’t worry that’s just the default behaviour. Internet Explorer (including IE7) doesn’t understand the tag so there’s no styling applied, some other browsers do and wrap the text up in speech marks. The best solution if you see this is to get your web team to remove this behaviour in the stylesheet so that it looks the same for everyone.

Don’t worry about &quot;

In your journeys through HTML you might have come across this strange notation, which looks like it’s something to do with quotes. It isn’t, so you can ignore it (or remain in your current blissful state).

It’s just used in the HTML code if you need a speech mark within, for example, alt text. The same character is used to enclose the alt text, so this is the route out of the potential confusion of speech marks inside speech marks. Your WYSIWYG editor should take care of these details for you though – you will still enter the ‘”‘ character in the dialog box.

Summary

• avoid using the Indent button if your editor converts it into the <blockquote> tag
• alternatively add a class (if it has been defined in your stylesheet) to the paragraph tag, or the style attribute (e.g. <p style=”margin-left: 20px”> …</p>)
• <blockquote> is for marking up blocks of text
• <q> is if you have a quote within a block of text
• some browsers wrap text marked with <q> in speech marks, Internet Explorer doesn’t – have them removed in your stylesheet for consistency
• don’t worry about &quot;

The reality is that there are times when you can’t avoid it – have deadlines to meet and you know that the stylesheet won’t be amended in time. So these are the WCAG 1 checkpoints that you need to be aware of.

Colour

A Priority 1 requirement is:

2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup.

You’ll have come across the application of this checkpoint when you’re filling in forms. There was a time when you would have had a phrase like ‘Required fields are marked in red’. That’s not particularly helpful for a screen reader that doesn’t report on colours to the user, so now the convention is to use a ‘*’ either as a replacement or in addition. So if you are using colour to highlight say the main contacts in a list then you will need to follow a similar convention.

Font sizes

A Priority 2 requirement (i.e. for Double-A compliance) is:

3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values.

You’ll come across this mainly when changing the size of text. The first thing to check is that you do want to use this option & that you shouldn’t be using a heading style instead. If that’s not the case then you need to avoid using points (pt) or pixels (px) as the measurement unit and instead use ems (em), percentages (%) or the relative sizes (xx-small, x-small, small, medium, large, x-large, xx-large).

There’s no real difference in the choice between ems and percentages as 1em equivalent to 100% (.5em is 50%, 1.5em is 150%, etc.).

This is mainly intended to help people who are using the text resizing option in Internet Explorer which ignores any absolute units. Other browsers (and now IE7) have a zoom option that will enlarge/reduce all the text on the page no matter what units have been used.

Blinking

7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off).

This might have been more of a concern when the guidelines were originally framed (1999) than it is today – the <blink> tag. So if you haven’t come across any other reason to avoid it like the plague then here’s one. It’s required for Priority 2 compliance.

Summary

• It’s better to have the stylesheets changed overall than to format directly in the content
• Don’t use colour alone to provide meaning
• Use ems, percentages or the relative units (i.e. small, medium, etc.) to change the size of text rather than pixels or points
• Don’t use the blink tag (restrain yourself, it’s horrible)

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.

13.1 Clearly identify the target of each link.

Both of them are Priority 2, so you need to abide by them to meet Double-A compliance.

Making the links clear

Sighted users are able to scan through content and pick up the links by visual clues without having to wait for the content to be read out to them. The idea behind the second checkpoint is to help some screen readers that try to achieve the same result by extracting a list of all the links on a page. However since they are no longer in their original context then it is possible that they might not make sense.

There are two ways of solving this issue. The first way is to select the most appropriate text for the link – e.g. in the first sentence of this post I could have selected ‘checkpoints’ rather than ‘Web Content Accessibility Guidelines’, the latter works better out of context.

However this might not always be appropriate, as you don’t want to clutter your text with full titles (e.g. ‘in a previous article’ rather than the title of the article) or you might want more than one link for an item (e.g. a report might have two links, one to a Word file and the other to a PDF). So in this case you would use the second solution which is to use the ‘title’ attribute that’s found in the dialog box when inserting a link using your WYSIWYG editor.

This additional content is available to the screen reader in its list, and normally will pop up on the screen for other users when they move their mouse over the link. For example on the home page of this blog each post is linked to with the text ‘full article’ but if you put your mouse over the link then the article title is shown as well.

You’re definitely going to need the ‘title’ attribute if your writing/linking style is to pick out phrases in sentences and tease your readers.

Opening new windows

There’s a usability argument against creating new windows when clicking on a link that makes for a confusing user experience. The ‘power users’ take it all in their stride but for many others they might not notice that anything has changed until they come to use the back button or close the window. In accessibility terms the situation is worse. If someone can’t see the screen then it can be even more disorientating if they haven’t had any warning.

That’s the rationale behind checkpoint 10.1 – providing information for the user in advance of clicking the link. Following on from the discussion above then we need to make sure that this is included when the link is taken out of context by a screen reader. So you could use the link text itself, an icon in the link (obviously with appropriate alt text) or kept away from the screen design using the title attribute.

Gotcha

There’s a few small things to look out for with links:

• if you are opening new windows and your site should be producing XHTML, then I’ve noticed that some text editors include a ‘target’ option in their dialog box for adding a link which then produces the equivalent attribute in the A tag. Unfortunately that’s not allowed in XHTML, and your page must validate to meet Double-A compliance (checkpoint 3.2)
• the method for opening a new window if you’re using XHTML is to use JavaScript, and that means that you have to make sure the link still works for people who aren’t using it (or have it switched off), so something like: <a target=”_blank” href=”http://news.bbc.co.uk” > becomes < a href=”http://news.bbc.co.uk” onclick=”window.open(‘http://news.bbc.co.uk’); return false;”>
• if the web address you’re putting into a link has an ‘&’ character in it then you should make sure that in the HTML for the page it’s shown as ‘&’, it’ll go back to ‘&’ when you click on the link or check it in the status bar of your browser – you don’t need to do this every time, just make sure that the system you’re using is dealing with this situation properly once

Summary

• Make sure that the text associate with the link is clear when taken in isolation, e.g. don’t just use ‘Read more’, either put more information in the text of the link or in the title attribute
• Let users know if clicking the link will open up in a new window – you could use an icon (with appropriate alt text), include it in the text of the link or put it in the title attribute (so that it’s not part of the screen design)
• If you’re opening new windows then check that your text editor is using the appropriate code for your site – if you’re using XHTML then it can’t use ‘target=…’ in the link but needs to use JavaScript instead, and the link also needs to work without JavaScript as well
• The first time that you use a web address with a ‘&’ you should check that the HTML for the resulting page converts it into a ‘&’

3.2 Create documents that validate to published formal grammars.

11.2 Avoid deprecated features of W3C technologies.

Both of them are Priority 2, so are required to meet the Double-A standard.

You’ll probably get to hear much more about web standards over the course of your Internet life. The purpose here is to make use of one of the basic tenets of the standards evangelists – more people can see and use more websites if we all use common points of reference. The second checkpoint is making sure that you keep up to date – usually before an HTML/XHTML element or attribute is removed from the standard it is marked as being deprecated so that everyone has time to make adjustments if they are using it.

How to validate

You can check whether your page using the HTML validator provided by the World Wide Web Consortium (W3C). If its content that is publicly available then you can enter the web address, otherwise view the HTML code for your complete page and paste that into the ‘Direct Input’ box. You will need to take the latter option if a user has to be logged in before seeing the content – otherwise the validator will only see the login form and check that.

You will get one of three results – yes, tentative yes and no. The ‘tentative yes’ will only appear if there is some information missing in the template for your page, as the validator needs to have the type of HTML/XHTML specified and also the character set. So if you see that then it’s an issue for your web team.

Resolving the problems

A ‘no’ from the validator means that there is something wrong with your page – that might be the content you’ve created or the template that its using. The best way to check this is to try to validate a page with as minimal content on it as you can muster. If you still have an invalid page then you will need to get your web team to look at the template. For the interim they might also be able to cook up a very simple web form that can generate a page using the code from the WYSIWYG editor and a minimal template that does validate. At least that will enable you to check if your part of the page has problems or not.

Making sense of the error messages isn’t easy unless you understand HTML – and sometimes they take some fathoming out even if you do. There are three possible circumstances that could be causing your problem:

• you’re entering the text into the editor and styling it using the options available – in that case you (or your web team) need to work out which piece of functionality is creating the invalid code, and then avoid using it (or have the web team remove it)
• you’re typing in HTML code in the editor – this requires some training/support and then you do need to be precise, HTML is a computer language and they can be very unforgiving if you don’t pay attention to the detail; or you get your web team to extend the functionality of your editor so that you don’t have to think about these things (after all that’s why it’s there in the first place)
• you’re pasting content from other applications such as Word or an email – what’s happening here is that the editor is trying to retain the styling and not creating the proper HTML; the ways around this are either to find if your editor has a ‘Paste from Word’ or ‘Clean Word’ option and use that, or paste the text into a basic editing program which has no styling options (like Notepad) and then copy & paste from there

Specialist markup

You’re highly unlikely to need to do anything about the final checkpoint here:

3.1 When an appropriate markup language exists, use markup rather than images to convey information.

Basically there are some alternative technologies for handling the specialist layout needs of complex scientific and mathematical formulae. If you’re working within that sector then you must use them rather than resort to using images. Otherwise you can ignore this one.

Summary

• Make sure that your pages validate
• Avoid/remove options in the editor that create invalid code
• Look for training/support if you are having to enter HTML code yourself, and pay attention to the detail when you are typing it in
• Be careful when pasting content from other programs, if there isn’t an option to paste/clean content from Word in your editor then use a simple text program (like Notepad) as a staging point to remove any text formatting
• If you’re working with complex scientific or mathematical formulae then there are specialist technologies you should use to include them in your web page (e.g. MathML)