Accessibilty for content providers - links
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 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 ‘&’
