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.

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)

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 editor – and many gremlins lie down that path.

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 at the top attached to the <html> tag or it could be something like <meta content=”xx-XX” http-equiv=”content-language” />. This shouldn’t be confused with Dublin Core metadata – if you’ve got something with “DC.language” then that’s what you’re looking at. If you can’t see a language definition page then check with your techies & get them to add it if it’s missing.

If you view the source code for this page then you’ll see that I’ve marked it up as “en-GB” right at the top. That’s the sort of thing you’re looking for.

Marking up changes

Unfortunately the standard settings for most rich text editors won’t be of much help in identifying language, to do this you will need to get into the HTML source for the content or convince your developers to add an option into the menu for you.

If you’re dealing with a few words within a sentence then you need to add a new tag around the appropriate text. So change your editor so that you’re looking at the HTML source. Track down the content that you need to mark as a different language and put in front of it <span lang=”xx”> and then after it </span> (the xx needs to be replaced with the appropriate language code that you can find about next). These tags should be placed immediately in front and after the text – there’s a thing in HTML about not having tags overlapping, so if you do this you don’t need to know anything more about it.

Remember that the guideline mentions “text equivalents” so if you’ve added an alt attribute for an image in another language then you need to put a <span> around the <img> tag.

If there’s a bigger chunk of text, such as a paragraph, then you can add the attribute ‘lang=”xx”‘ to the existing tag (again the xx needs to be replaced with the appropriate language code that you can find about next). So typically you might see the <p> tag and you’ll need to make it <p lang=”fr”> for a paragraph of French. If there’s more than one paragraph then you do this on each <p> tag.

You can’t put a <span> around a <p> tag (so not <span lang=”fr”><p> … </p></span>, but only the HTML pedants would be upset if you did something like <p> <span lang=”fr”> … </span> </p>. That will be OK & would mean that you need only remember one solution.

Now you can see why I’d suggest that if you’re doing this often you should get something added to the toolbar to make it easy for you.

What language code should you be using?

The W3C have provided some advice for selecting a language code, which basically in this context boils down to:

• use the shortest language code that is appropriate (i.e. you don’t need to specify UK English unless there’s something that is specific to the region, just saying English will be fine)
• you can find the appropriate sections of code in the official language registry
• you’re most likely to either use the single language code (e.g. ‘es’ for Spanish, ‘fr’ for French) or the language code with region (e.g. ‘es-MX’ for Mexican Spanish, ‘es-ES’ for Spanish from Spain)

What should be marked up?

The answer to this sounds obvious – anything in a different language – but when it comes to the fine detail it can be a grey area. Should you mark up the names of people and places? I’d be intrigued to know what language code you’d use to get a screenreader to pronounce ‘Belvoir’ as ‘beaver’ (as in Belvoir Castle).

Bear in mind that it’s not an issue of pedantry (“Is ‘vice versa’ accepted as English or should it still be treated as Latin? Discuss.”) or cultural battles (although I could imagine the Academie Française insisting that Paris should not only be marked up as French, but French as spoken in France at that). The aim is to help screenreaders by giving them sufficient information to be able to pronounce the word correctly.

So try to be consistent if nothing else – make sure that other content providers for your site understand whatever rule that you come up with.

Summary

• Check that your page specifies the main language used in the content – this is different to specifying the language in Dublin Core metadata
• Mark up any changes in the language of your content
• Remember to think about the alt text for images as well
• The implementation of this guideline is pretty subjective – the main thing we’d recommend is being consistent & think what will be helpful for the user
• If you’re using other languages in the titles for your content then you should alert your developers – those pieces of text will be automatically dropped into menus or headings and they need to indicate the change of language
• Not an accessibility issue, but while we’re here – if you’re going to be using characters that aren’t in Western European languages then you probably also need to check with your developers as they might need to make some adjustments

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 to do this to get any level of accessibility compliance.

The considered view of the accessibility gurus on alt text is:

• it should convey the meaning of the image and be relevant to the content, so “Photo” isn’t going to be of help to anyone and neither is something like “Couple staring” when a stock photo is just being used to set the mood for the content (this is a real example and you couldn’t even see what the couple were staring at!), “Photo of the Houses of Parliament” would be OK
• if the image conveys no content then the alt text should be blank (i.e. when you view the source for the page, in the image tag you should see alt=”")
• if you’ve got an image and text all wrapped up as the same link then the alt text should be blank (otherwise the text is repeated and would sound odd)

Just about every rich text editor will allow you the opportunity to enter the alt text when you add an image to your content, although they might use varying descriptions as to what it is (with this blogging application it’s the ‘Image description’). Since it should be blank in certain cases then it’s not possible to make it required. You should check though what happens if that field is left empty – it should still produce an empty alt attribute (i.e. alt=”") rather than miss it out.

There’s also an extra part to the requirement that most people don’t realise – the longdesc – and that’s usually because the need for it is less common as it relates to complex content (e.g. a chart). So the idea is that you may have a graph – maybe the results of a survey that you undertook – and you need to explain to someone who can’t see it what information you’re trying to convey.

The longdesc attribute itself is a web address where you have (not surprisingly) the long description for the image – this can be on another page or a section of the current page. Not many text editors will have this option by default, so I’m afraid it’s back to editing the HTML source to add the attribute to the image.

Another requirement to consider with images is 2.2:

Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].

So as a priority 2 checkpoint it’s part of the Double-A compliance.

One quick way to check colour combinations is to convert the image into black and white (greyscale is probably the better term). That will give you a good idea as to whether the colour contrast is sufficient. For information about colour-blindness I’d suggest that you look at Vischeck.

Summary

• Always include an alt attribute for an image
• The alt text should convey the meaning of the image
• It is appropriate to leave the alt text empty (i.e. have alt=”") if the image has no real meaning
• For a complex image (such as a graph) you will also need to create a separate page (or section of a page) that explains the information in the image more fully
• Check the contrast and colour combinations of images – or if someone else is providing the images make sure that they are aware of the accessibility requirements

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 it’s a lot harder to work out where the headings and subheadings might be on a page. That can be important for someone using a screenreader where it will take much longer to take them through the content on a page – sighted readers can scan the screen to look for visual styles that imply something is a heading. (Although as well as helping with accessibility this can also be used by a search engine to work out what are the important bits of content on your page and help in its mysterious assessment of what results are most relevant.)

In the Web Content Accessibility Guidelines (WCAG) this is covered under checkpoint 3.5:

Use header elements to convey document structure and use them according to specification.

It’s a priority 2 checkpoint, so if you’re just having to conform to A rather than Double-A accessibility you don’t necessarily need to worry about it.

There are two main parts to satisfying the criteria.

The first part is to make sure that you mark-up headings properly (rather than styling them to look the same) and not to mark-up something as a heading that only requires that styling.

Quite often we’ve found when asking clients why they didn’t use the heading mark-up we’ve found that it’s because they don’t like the styling that it uses. If this is the situation that you find yourself in then the first thing to do is to decide what heading styles you require. You can then work through them with your web developers to see how they can be added to your site. There are a number of options open – the styling could be changed automatically for you depending on which section of the site the content will appear in or where on the page; the styling options might be added in a drop down menu in the editor; you might need to go into the HTML source for the content and make the change that way; or you can’t justify the cost/time involved so the styling is dropped.

The second part is that there are 6 levels of heading available on a web page (H1 – H6) and these should be used in the right way. The main heading for the page should use H1. Now there’s a whole debate about what is or isn’t a main heading, should headings in a sidebar be H2 or lower, etc. This won’t be an issue for you as someone else will have already made this decision and you just need to follow through accordingly.

The starting point is the heading level that has been designated for the title of your content – your web developers will be able to tell you what that is. Failing that you should look at the source code for a similar page in your web browser (usually by going to the View menu & selecting Source) and searching for the content title. The title might appear a number of times in the source so you’re looking for the one immediately above the content.

Once you have found out what level is being used for the title of your content you then know that any subheading below that that you create will be the next level down. So in this blog we’ve used H1 as the title for the content, so any subheading will be H2 (& a sub-subheading will be H3, etc.).

Intriguingly as I’m writing this in WordPress there’s no option to create headings from within the rich text editor toolbar by default. However I know that they’re using TinyMCE to provide this functionality and it’s available there, so unfortunately someone at WordPress has decided to take it out.

So what should you do if you find yourself in the same circumstance? Firstly you should make loud noises to your developers (hmm yes, it is on my list of things to do with this blog) as it’s highly likely that the option has been hidden. You and other content providers need to have the tools available to maintain the accessibility of your site. Secondly, in the interim period, I’m afraid you’ve got to get your hands dirty and change the underlying code yourself. It’s probably best to get your IT support to help you with that, as the exact sequence will vary from editor to editor. It’s not difficult though, it just takes you into areas that you probably don’t want to go regularly.

Summary

• Think about the structure of the content that you’re creating rather than the text style that you want to achieve
• Use the heading mark-up on heading text – don’t just make it bold and a bigger size
• Don’t use headings to implement a style for the sake of it – if it’s text that you want to emphasise then this is the time to hit the bold (& any other) button
• The heading levels should go in order, so the next level of headings after H2 should always be H3, etc.
• You may need to go to your web developers to make sure that you have the visual styles for headings
• If headings (or the right styles) aren’t available in your editor then you might need to get into the HTML source to mark them up appropriately – not a long term solution

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 computer code. That code not only dictates how the text might be displayed visually in your browser but also how it is assessed solely as structured content (e.g. a hierarchy of headings) and delivered to someone (or even to another system such as a search engine) in a different format.

For instance someone with a screenreader can ask that program to give them a list of all the links on a page, because they are not in a position to scan through the text looking for the styling that you’ve decided to use and reading text takes a longer time. However on many sites they might be hearing a whole list of links that say ‘read more’. But read more what? Which one is the link that’s of interest to them? For sighted people it’s quite easy because they can see that there is a list of news items, and for each one there is a title, summary and link that invites them to ‘read more’.

If you start looking around for resources on website accessibility then you’ll find yourself either at the abstract end of the spectrum (I’ve included the links to the WCAG below, but be warned) or deep in geek country. They’re not for the faint of heart. So we’re putting together a series of posts on this blog looking at what issues are relevant when you, as a content provider, are sitting in front of your rich text editor.

What are the issues?

A good place to start, to get an understanding of who we’re doing this for & what issues they face then I would recommend Dive Into Accessibility. The document is aimed at technical bloggers so you can stop reading after Day 5 when he starts to look at how to change the code produced by the blog. This will be the sort of thing that your developers should be concerned about on your website – that is unless you’re running your own blog, in which case you should read the rest of the document.

If you’re feeling brave then you might want to tackle the Web Content Accessibility Guidelines (WCAG). The standard that is in use currently is WCAG 1.0 and you can refer to the Checklist of Checkpoints to see what is required for double-A compliance, for which you’ll need to pass all Priority 1 & 2 checkpoints.

Don’t believe your eyes

One of the most common accessibility problems is caused by users selecting styling on the basis of how the content will appear on the page. The main bugbears seem to be headings and lists, but sometimes the rich text editors throw a spanner in the works with how they implement indented text.

So a short answer is that headings should be marked up as headings rather than making the text bold and the right size; similarly headings shouldn’t be used just to make text bold; lists of items should be marked up as lists even if they don’t have bullet points; and text that you want to emphasise with bullet points shouldn’t be marked up as lists.

Over the course of this series we’ll cover these issues in more depth, but at the moment it’s a question of shifting how you look at your content and how you use the formatting options available. In a number of cases we’ll be suggesting that you go back to your developers & designers and make requests for extra styling options. That will reduce the temptations to stray off the straight and narrow, as for instance you’ll have an option to indicate that a paragraph needs to be highlighted with a bullet point without using styling it as a list.

Beware the copy & paste

Currently the bane of my life.

A client has either received content by email or they’re taking an existing document in say Word and putting it onto the web. So they cut and paste the text, and unfortunately along with it comes a mass of formatting. And then we get the email or phone call asking why the text on a particular page is all different sizes or fonts, what’s happened to their wonderful look & feel that we unveiled for them recently.

Accessibility issues also come into the frame as well. If the content is coming from a format that is used for printing then issues about document structure will have gone by the board. For example it make absolutely no difference on paper if the word-processed document used heading styles or just had the text made bold, increased in size and maybe some extra spacing around it. It still looks the same in print – but it won’t be the same when it is added to a web page.

The easiest way to get yourself out of the mess created by copy and pasting from a program that understands formatting is to put it first into something that has no concept of text styling like Notepad. Copy the text from its source and paste it into Notepad, then copy it again from Notepad and paste it into your rich text editor. That will give you unformatted text that you can then style up.