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 …

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 …

Peter Krantz over at “Standards Schmandards” has given a range of WYSIWYG editors an annual work-out and posted his results.

It’s nice to see that a couple of the WYSIWYG developer teams (for TinyMCE and WYMeditor) have responded in the comments, and are taking the issues on board. Hopefully pressure can continue to be applied so that in future we don’t have to battle with the rich text editors to produce accessible content.

Note that he’s not testing it against the Web Content Accessibility Guidelines 1 (WCAG 1), nor looking at whether the editor itself is accessible. Essentially he’s trying the sort of content that we (as web developers) would would want our clients entering into their assorted content systems. So anything that relates to look and feel (colours, text alignment, etc.) would all be provided by the stylesheets rather than the WYSIWYG …

Language has a nasty habit of tripping people up when it comes to accessibility. It’s not something that happens that frequently on most sites, but it’s priority level 1 in the World Wide Web Consortium (W3C) guidelines. So if something slips through the net then you won’t even make A compliance let alone Double-A.

The relevant checkpoint in the Web Content Accessibility Guidelines (WCAG) is 4.1:
Clearly identify changes in the natural language of a document’s text and any text equivalents (e.g., captions).
The language for the page
So the first thing you might want to make sure is that a language has been specified for the page before thinking about your own content. After all there’s no real point in highlighting the exceptions if you haven’t said what is the rule.

When you view the HTML source for one of your content pages you search for ‘lang=’ - you could find this …

This is probably the one area that most people involved in websites know about. You have to have an alt tag on an image (actually if you’re in point-scoring mode then it’s an alt attribute in an image tag).

In the Web Content Accessibility Guidelines (WCAG) this is covered under checkpoint 1.1:
Provide a text equivalent for every non-text element (e.g., via “alt”, “longdesc”, or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., 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 of video, and video.
As you can see this is not just about images but other multimedia content that you might include on the website. It’s a priority level 1 requirement, so you need …

Let’s start with a spot the difference competition. Here are two web pages - version 1 and version 2 - that display the same content with the same look & feel. There isn’t an awful lot on the page to go wrong, but one would fail the Double-A accessbility criteria.

It’s that easy to create content that would fail the accessibility requirements!

What’s the problem? Well, even though the pages look the same the heading at the top is marked up in the underlying code in different ways. In the first (correct) version there is a heading level 1 tag (with an h1 tag) whilst in the second (incorrect) version the same text is just marked up as a paragraph (with a p tag).

They might look the same in your browser but if you were presented only with the HTML code then …

Database-driven websites are commonplace for many organisations. Content management systems (CMS), blogging tools, etc. are no longer the preserve of large enterprises, and with them the days of requiring a web expert or design agency to put up the latest press release have gone. The balance of control has shifted and now it is the people who create the content in the first place who are able to write their own text.

However with that power comes responsibilities and one of those is to ensure that the website is accessible. For most public sector organisations in the UK this means that they must comply with the double-A (or AA) guidelines of the Web Content Accessibility Guide (WCAG) from the Worldwide Web Consortium (W3C).

Most content providers are focussed on the text that they are creating and how it is to be styled. However at the same time they are involved in generating …