I was playing around with the current development version of WordPress (2.5 will be released in March) & had a nice surprise when I tried out the WYSIWYG editor. It’s about a year ago that I was last taking a serious look at the code they produced in response to Peter Krantz’s round-up over at “Standards Schmandards”.

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 …

Jared Smith has raised a good point over at WebAIM in his recent post - JAWS license not developer friendly. Basically the licensing agreement for the trial version of the software (one of the most popular screen readers) specifically prohibits using it for testing purposes. I would have thought that the fewer barriers that web developers have in understanding assistive technologies the better. Ultimately it would be to the benefit of JAWS users, and that would also reduce support issues for Freedom Scientific.

With all the (technical) media interest in the iPhone I decided it was worth taking a look at the iPod Touch to test out its new web browsing features. Other handheld devices and mobile phones have gone down the route of reducing a web page to fit the restricted environment of the screen, as can be seen in the screenshots for Internet Explorer Mobile. However there seems to be a trend for this paradigm of using a normal page but zooming in & out and scrolling around with your fingers. For example the new mobile operating system that Google have developed (Android) has similar features, as can be seen in this demonstration.

As I’ve been testing it out I have been struck by the similarities with the screen magnifier demonstration that I posted about before. …

Continuing their series on accessibility technologies in action, Yahoo’s User Interface Blog has a video demonstrating ZoomText.  Most of the issues involve the visual aspects of a web page (as opposed to a screen reader where the code used to create the page is more important) - for instance consistency in layout (as the user might only see part of the page at a time, so needs to know which direction to scroll in).

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.

Our recommendation for clients is that they should aim for small incremental updates on their website, maybe every three months - it avoids creating major upheavals that have to work as soon as the changes are implemented. This strategy isn’t going to work when you are developing standards as there needs to be more stability for others to be able to apply them. The World Wide Web Constortium (W3C) appears to have gone to the other extreme though as it is now 8 years since the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) became a recommendation - sometimes you might see references to the WAI (Web Accessibility Initiative) or the accessibility levels specified (AA, Double-A, etc.).

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 …

Yahoo’s User Interface Blog has an excellent video showing their Program Manager for Accessibility using a screen reader.

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.

Unfortunately the underlying technology used in most WYSIWYG editors makes it very easy to fall foul of these accessibility rules. The problem is the Indent button. It works fine if you use it on a list - making the list item that you’ve highlighted move in a level - but if you apply it to a paragraph then it will mark it up as a quote. That’s because the normal styling applied to a quote by your browser is to indent the text.

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 …

The designers of your website would want you to avoid having to be involved with any of the issues here, since it will mean that you are breaking away from the options in the stylesheets. In general, the more you use mark up to reflect the meaning and structure of your content the better. That makes it easier to maintain over a long period of time, to provide a common user experience across the site and to adapt to changes in the overall look and feel.

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 …

There are two checkpoints in the Web Content Accessibility Guidelines 1 (WCAG 1) directly covering links:
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 …

This section isn’t going to set many normal pulses racing. Thankfully once you’re in the swing of things you’re only going to need to remember to validate your pages occasionally. You just need to be aware of the options in your editor that produce incorrect code and the perils of casually pasting in content from other programs.
The relevant main checkpoints from the Web Content Accessibility Guidelines (WCAG) are:
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 …