Design & UX
By Gian Wild

Making Accessible Links: 15 Golden Rules For Developers

By Gian Wild
Marginalia: adding comments to the text

Photo: Penn Provenance Project. Before the link, marginalia was one of
the ways publishers could provide extra context
to body text.

Links are the soul of the web — they are what makes it special.

From ancient times printed texts have relied on far clunkier devices — things like footnotes, appendices and marginalia — to add related content and extra context to the body text.

But, if the web has had one great trick, it is its ability to stitch together disparate content in a non-linear, but still meaningful way.

That is why there is a huge onus on us — the humble web developer — to make sure all those links work for users of all abilities!

This is, unfortunately, a little more complicated than just avoiding the use of phrases like “click here”.

Let’s look at what it takes.


So, what makes good link text?

While the current W3C’s Web Content Accessibility Guidelines – WCAG2 – emphasise providing overall context for a link, little emphasis is placed on making the text of a link itself understandable to users with disabilities.

I believe this is the wrong approach.

Screen reading applications offer only limited ways to interpret a page. One common method is to generate a list of links (without context) to determine the content of the page. Screen reader users also often scan a page by simply tabbing from link to link (without reading the text in-between).

When confronted with a bunch of “Click here to download the annual report” and “More on boating”, such techniques are useless.

Link text also becomes a serious issue once you start talking about mobile and tablet sites.

Two of the most well-known sets of mobile accessibility guidelines — the W3C Mobile Best Practices and the BBC’s Mobile Accessibility Guidelines — suggest clearly identifying and describing the target of the link.

In my work auditing web sites, I identify all the “click here” links and flag them as accessibility failures. Sure, “click here” links can be activated by the keyboard, but it implies that you need a mouse to activate the link.

And that’s a failing.

Sure, it’s a little more difficult to argue that “here” and “more” links are inaccessible strictly under WCAG2. I still flag them as errors, but it’s almost impossible to find a success criterion that they fail.

So, here is my 15 point checklist to keep in mind when linking text on the web.

Rule 1 : Don’t use the word “link” in your links

This is an easy one.

Screen readers tell the user when they encounter a link, so you don’t need to use the words “link” or “links to” or “goes to” in your link text.

Rule 2: Don’t capitalize links

Telephones, Baggage department and Security in capital letters in red neon signs.

Photo credit: ~dgies

There are two problems with capitalized text in links.

Firstly, some screen readers read capitalized text letter-by-letter. And this occasionally even occurs when the HTML is in sentence-case and the CSS forces the capitalization.

The second problem is that capital letters are harder to read (for everyone, but especially people with reading disabilities).

Capitalized text has no difference in shape: all the words are just one big rectangle. Sentence capitals have differentiated shapes based on the letters used.

See the following as an example:


Capitalized text is difficult to read. It’s all one big rectangle.

The general rule when it comes to reading is: if it’s more difficult to the general public then it will be almost impossible for a person with a cognitive disability to read.

And who wants to shout at their audience?

Rule 3: Avoid ASCII characters

Smiley face smarties

Photo credit: jessicahtam

Under Success Criterion 1.1.1: Non-text content is the requirement to provide text alternatives for ASCII characters.

The specific requirement is H86: Providing text alternatives for ASCII art, emoticons, and leetspeak, which means you need to provide text alternatives for things like smiley faces.

They recommend using the TITLE attribute; even though it’s not well supported, or the ABBR or ACRONYM elements.

However if you absolutely must use emoticons, then at least mark them up with some ARIA:

<span class="sr-only">Smiley face</span>
<span aria-hidden="true">:-)</span>

However I’ve always believed this technique should go one step further, and include most punctuation as well.

Let’s look at em-dashes as an example.

The following link text may be clear to visual users, but it’s a different story for screen reader users:

16 – 17 years, 17 – 21 years

Some screen readers will read the above link as “link one six one seven years end link“.

It is much clearer to replace the em-dash with the word “to”. In that case, screen readers will read it as “link sixteen to seventeen years end link”.

Much clearer, right?

Rule 4: Avoid using URLs as link text

When we see “”, we see the words ‘london’, ‘toy’ and ‘library’, but a screen reader is going to read the URL letter-by-letter. “Double-U, Double-U, Double-U, Dot, El-Oh-En-Dee..

As you can imagine, this becomes unintelligible after the first 4-5 letters.

So, always use meaningful text as links, such as “London Toy Library”. If you really need to provide the URL in text — for example if you expect people to print out the content — then append the URL to the link text in the print style sheet with something like:

@media print{
   a:after{content:" (" attr(href) ") ";font-size:0.8em;font-weight:normal;}

Rule 5: Keep link text concise

It’s a really good idea to restrict the length of your link text to a maximum of 100 characters.

Screen readers have a huge array of functions that allow users to skip to the next word, next sentence, next paragraph or next heading, but they have to read the entirety of a link.

So, you can imagine that if you have turned an entire paragraph into a single link (which we’re seeing more of with the advent of block-level links in HTML5), the entire link is read out by the screen reader.

You can imagine how annoying this could become.

Rule 6: Restrict the number of text links on a page

This is important because users see links as a form of navigation: they know they are not on the right page so they are looking for links that will take them to where they want to go.

If there are a lot of links on a page, it makes it that much harder to navigate a site.

And of course, screen reader users can pull out all the links in a page, so if there are hundreds of links then reading through them all is a nightmare.

Ok, so how many links are too many? That’s the ‘How long is a piece of string’ question, and depends on the type of site that you have.

Just bear in mind the users that are navigating from link to link when you’re constructing your pages.

What about areas where additional link text or contextual information is essential?

There are three key areas where additional link text or contextual information is a must:

  • linking to downloads
  • links opening in a new window
  • pagination / alphabetized links.

We’ll cover them separately.

Rule 7: Don’t link directly to downloads

In the usability testing I’ve witnessed, one thing is universal: people hate downloads.

It is even more annoying when they open a download without expecting it.

But what is a mere annoyance for general users becomes a very serious problem for people with disabilities. It is essential you properly indicate when a link activates a download – and make sure this information is in the link text.

If you use a ‘PDF’ or ‘Word’ icon instead of the text, always make sure they have useful ALT attributes!

One thing I have seen recently, is the automatic addition of a download icon via CSS. Remember that this is essentially invisible to screen readers — they don’t read CSS images — so never embed critical information in CSS.

I’ve always recommended that you add some more detail than just the type of download, for example the size of the download too.

So, that’s all fine if you have one document. But what if you have a whole bunch?

WCAG2 now allows something like the following (with “Disability Services Annual Report” coded as a heading):

Disability Services Annual Report
2013 PDF, 2013 Word
2012 PDF, 2012 Word
2011 PDF, 2011 Word

Or even something like this (where the first column and first row are coded table headers using <th>):

Title PDF Word
2013 Disability Services Annual Report PDF download Microsoft Word Download
2012 Disability Services Annual Report PDF download Microsoft Word Download
2011 Disability Services Annual Report PDF download Microsoft Word Download

Or even a combination of the two (headings and table headers):

Disability Services Annual Report

Title PDF Word
2013 PDF download Microsoft Word Download
2012 PDF download Microsoft Word Download
2011 PDF download Microsoft Word Download

Much cleaner, more semantic, AND more accessible, I think.

Rule 8: Always alert the user when opening new windows

It is important to warn people with disabilities that a new window has been opened — especially people with cognitive disabilities who may not notice.

The best way to indicate that a link opens in a new window is to add text to the link, such as “(opens in new window)”.

However, you can also add an icon with an appropriate ALT attribute, but you must explain what the icon means somewhere on the page, like FRIENDS Life does (although note their accessibility information is woefully out-of-date):

Page opens in new window icon with associated text that explains the icon.

If you absolutely must use a character to indicate a link, I’ve started using Font Awesome’sExternal link” icon for opening in new windows.

The HTML is:

<a href="" target="_blank">Google 
 <span class="sr-only">Opens in new window</span>
 <i aria-hidden="true" class="fa fa-edit fa-external-link"></i>

And the CSS is:

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  border: 0;

It renders like this :

Google as text link with an external link icon

Always include the icon after the link text. Otherwise screen reader users who pull out the links of each page, will get a whole list starting with “opens in new window” instead of meaningful link text.

Rule 9: Be aware of pagination and alphabetized links

For a visual user, a list of numbered links at the bottom of the search results means “move to the next page”, but in my user testing, I find over and over again that people with disabilities do not know what these links mean.

To make these links accessible, just add some contextual information before the list of links, such as “Go to search page: 1 2 .. etc”.

If it’s an alphabetized list of links, then a heading explaining the links is best, such as:

Author’s surnames starting with:
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

User agents and assistive technologies now are adept at rendering adjacent links, so there’s no need to put vertical bars, like in the example above, between links any more.

It is still important that there is space between adjacent links.

Android devices zoom in on an area when the user touch encompasses more than one link, but Apple and Windows devices do not.

I recommend using the CSS border property around links to make them look more like buttons. This makes the entire space within the border clickable, and can be achieved by simply adding:

border: 1px solid black;

I also see color being used in pagination or alphabetized links to indicate the current link, such as:

Numbers 1, 2, 4 and 5 in blue text and the number 3 in black text.

This violates Success Criterion 1.4.1 Use of Color:Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element“.

The best thing to do is make the current page number plain text and the other numbers links.

And make sure those links are underlined! This way the links are visually distinct (without relying solely on color) and programmatically distinct as well.

The other problem with pagination and alphabetized links is that they generally present a very small target area for the user to select.

This is no problem for keyboard users, however people using other input devices, such as a mouse, joystick or touch screen can find one letter links very difficult to properly select.

It’s a good idea to make single character links a larger text size than the surrounding content.

It’s also wise to use plenty of CSS padding around the link to increase the clickable area, such as:

padding-left: 1em;
padding-right: 1em;

So if you put these techniques together you get:

span.pag a {
  padding: 1em;
  border: 1px solid black;
  margin: 0.5em;
  background: #ffffc3;
  color: black;
span.current-page {
  padding: 1em;
  border: 1px solid black;
  margin: 0.5em;
  background: black;
  color: white;

And the HTML for the actual paginated links is:

<span class="pag">
 <a href="">1</a>
 <a href="">2</a>
 <a href="">3</a>
 <span class="current-page">4</span>
 <a href="">5</a>
 <a href="">6</a>

And you end up with paginated links that look like (for a working example see The Accessible Wizard of Oz):

Numbers 1, 2, 3, 5 and 6 underlined in yellow boxes and number 4 is white text on a black box

Of course, feel free to fancy it up a bit with rounded corners and some color!

Rule 10: Be mindful when using anchor links

Pencil drawings of various marine anchors.

Photo: El Bibliomata

It’s important to be very careful using anchor links.

With really long pages, I’ve seen many users scan the page and then select anchor links, assuming it will take them to a different page. Often they don’t realize they are just moving up and down the page they have already scanned.

Remember: if something is an issue for the general user — and we know this is — it will be a serious problem for a person with a disability.

Screen readers do usually identify whether a link is an anchor by adding the phrase “in- page link”, so they at least have some feedback when activating an anchor link. But visually-challenged users, people who use magnifiers and people with cognitive disabilities may not realize they are activating an anchor link at all.

I recommend using a standard preceding phrase to indicate anchor links such as “In this page:”, “Jump down to:” or “This page contains the following content:”.

Rule 11: The case for underlining links

People expect links to be underlined.

When they see underlined text they expect it to be a link (which is why you should never underline text in the online world unless you are representing a link).

WCAG2 does recommend that you underline your inline text links, but also allows developers to meet the accessibility criterion if they use a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them.

This requires that your text links contrast sufficiently with surrounding text (the W3C has a list of link colors that contrast appropriately with black text and a white background) and there is an additional visual cue when the link receives mouse or keyboard focus.

This visual cue can be an underline (go on, make those links underlined!), bold, italic or increase in font size or it can be the addition of a glyph or image. It can be implemented through CSS as this only needs to be a visual indicator.

But remember to add a:focus to a:hover!

Rule 12: Design with keyboard-only users in mind

The extra information conveyed in the TITLE attribute of a link HREF, (see H33: Supplementing link text with the title attribute, is not available to keyboard users.

In addition, this tooltip cannot be resized to suit the user, failing Level AA Success Criterion 1.4.4: Resize text. Neither can the colors of the text or background color be changed.

Another serious keyboard issue can be a lack of a keyboard focus indicator, which can often make a site almost impossible to use by keyboard users.

The only way for a keyboard user to know which link, navigation item or field has focus is if that item has a keyboard focus indicator. As you can see from the next screenshot, the item with the keyboard focus is a different color to the surrounding content and outlined with a dotted border.

About link is black and the Services link, which has keyboard focus, is orange with a dotted outline

Indicating keyboard focus.

I always recommend that if content changes on mouse hover, the same should occur on keyboard focus. In almost all cases you need to add “a:focus” wherever you have “a:hover” to achieve this.

Scripted links

Using scripting events, via JavaScript, to emulate links is also banned under the WCAG2.

All links should be created using A HREF or AREA. The use of ONCLICK on random elements, such as SPAN, IMG and DIV is not permitted.

Negative TABINDEX values

Negative TABINDEX values, introduced with HTML5, very clearly violate Success Criterion 2.1.1: Keyboard: All functionality of the content is operable through a keyboard interface.

Rule 12: Be mindful when using images as links

There are special requirements for images that are links. The ALT attribute acts as the link text. As mentioned earlier, you don’t need to add the word “link”, and you also don’t need to add the word “graphic” or “image”, as screen readers identify images to their users as well.

You do need to be careful when creating ALT attributes for image links, because the ALT attribute has two requirements: it must describe the image and it must tell the user what activating the link will do.

For an image button then an ALT attribute like “Search”, “Find” or “Submit” is great, but avoid using the word “Go” as I’ve found users don’t understand that terminology (“Go where?” they ask).

If you do have a linked image next to a text link that goes to the same page, then in most cases that image needs an empty ALT attribute.

This is a requirement under Technique H2: Combining adjacent image and text links for the same resource.

It is also a requirement that one link should encompass the link text and the image. Happily, this can be done now as HTML5 allows A as a block-level element.

There is one exception to this rule, and that is when the image conveys additional important information not provided in the text link.

Here’s what NOT to do with linked images

Image of The Sopranos next to a link and text about the Top TV Series of the Past 20 years

The code for this image/link combination is so woeful, I just had to include it here:

<div class="list-preview-item-wide">
<a onclick="(new Image()).src='/rg/list-user-wide/list-image/images/b.gif?link=%2Flist%2Fgm7xsjP4vD8%2F';" href="/list/gm7xsjP4vD8/"><img alt="image of title" title="image of title" src=",0,86,86_.jpg" class="loadlate" width="86" height="86"/>
<noscript><img height="86" 
 alt="image of title" title="image of title"
 src=",0,86,86_.jpg" class="" /></noscript>
 <div class="list_name"><b><a onclick="(new Image()).src='/rg/list-user-wide/list-title/images/b.gif?link=%2Flist%2Fgm7xsjP4vD8%2F';" href="/list/gm7xsjP4vD8/">Top TV Series of the Past 20 Years</a></b></div>

This code contains a great swath of meaningless inline JavaScript that could easily be replaced with HTML. It also has a mind-bogglingly useless ALT attribute that reads “image of title”.

Just to be sure, they added “image of title” to the TITLE attribute too!

In the previous screenshot, the image and the link text “Top TV series of the Past 20 years” go to the same place, so they should all be one link.

However the image of the Sopranos TV series tells us some important information: that the Sopranos is in the top 20. Therefore the image needs to have an ALT attribute like “The Sopranos”.

The correct code would be (and I just had to get rid of that JavaScript too):

<a href="/list/gm7xsjP4vD8/">
<span class="list-preview-item-wide">
<img alt="The Sopranos" src=",0,86,86_.jpg" class="loadlate" width="86" height="86"/>
<span class="list_name"><b>Top TV Series of the Past 20 Years</b></span></a>

Rule 13: Eliminate broken or empty links

Most people use a tool to find the broken links on their site, so I don’t often come across those.

But in almost every site that I test, I find empty links like this:

<a href='someplace.html'></a>
Empty yellow suitcase on a blue background.

Photo: roeyahram

I can only guess that they are inserted by some Content Management Systems glitch.

Whatever the origin, they are inaccessible and annoying to screen reader users.

All they’ll hear is “link end link” and find themselves wondering if they are missing something — or perhaps they’ll assume the link is an image with an empty ALT attribute.

Either way, very irritating.

Rule 14: Make your links consistent

Consistency is your friend. It lets your users orient themselves quickly.

Everything on your site should be consistent: your headings, field labels, buttons etc. You links are no exception to this rule.

This is especially important if you have decided, despite my urging, not to underline your links.

Your users will browse your site and determine how you display your inline link text – so make sure it is consistent! You must never use one color to indicate links on one page and then another color on another page.

Rule 15: Test your color contrast

You need to ensure that the color of your link text contrasts sufficiently with the background color. This is required whether your links are underlined or not.

If you change the color of the link on mouse and keyboard focus, you need to make sure that new color also meets color contrast requirements.

There are a number of online tools that make testing contrast both painless and scientific.

These include:

You made it!

As you now know if you got this far, there are a range of (usually) simple ways you can make your site easier to access for people with disabilities.

There are also even more ways to make the experience a nightmare.

Choose wisely.

I think that should cover things off — but if you’re looking for even more detail:

1) I have an even more detailed discussion on accessible links on my own blog.

2) Also try these Accessibility fact sheets:

  • KevTheDev

    #12: A div inside an anchor will not validate. It should be a span. A block element should not be used within an inline element. Other than that, great list!

    • Alex Walker

      Thanks Kev. Makes sense. I’ll check with Gian and likely update that.

      Yes, it’s a long article, (I edited it) but there’s a lot of good stuff in there.

      • Mate is correct re HTML5.

        • It is not, that if something is valid by rules, that it makes sense… look at any governments and country laws. They’re not always right either, are they? Just saying :)

          • The point is that this wasn’t a good “rule” to begin with. The HTML5 specs have corrected that, as John Faulds points out above.

    • Block level links are fine in HTML5:

      The a element may be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g. buttons or other links).


    • Mate Brkić

      you are not right, in HTML5 it’s perfectly valid to do that ;)

      • Alex Walker

        I guess it’s worth changing the DIV to a SPAN in the example, so the doctype choice becomes irrelevant.

  • Great piece of info.

  • This would have worked better as three articles with five rules each. What’s here is pretty good, but Rule 15 (for example) is really thin. There’s a lot more to color contrast than that, particularly when you think about how people with different kinds of disability are affected. I know you know that, Gian, so I assume this has been edited for space. Hence – a series would have been better.

    • Alex Walker

      Ricky, I hear what you’re saying, but I’m not a huge fan of series for list/rules type article like this.

      But point taken.

    • …and Rule 12 is repeated twice

  • Jacek Smolak

    Great article, as always.
    I would also like to add a tool to check contrast ratio by Lea Verou.

  • Jingqi Xie

    A bit long to read, but really a great article.

  • Great article, accessibility is super important for the future of the web!

    It’s worth noting that the acronym tag no longer exists in HTML5, abbr is now used for both acronyms and abbreviations.

    • Jingqi Xie

      For the compatibility with old versions of Internet Explorer.

  • Kalpesh Singh

    An Interesting read.

    Rule 2 is amazing. It is really hard to read capitalize sentence or words.

  • cyberlooks

    Making websites accessible is absolutely important and this article is great. But only for developers and NOT for clients who have NO HTML knowledge and NO experience.

    When I sit with my client in frotn of the laptop and explain them how to create a text, insert fotos, links etc., I tell them to add an alt-text and a title etc.

    And even that is too much sometines and people are stressed.

    Accessibility is a deveopers thing and I can optimize a theme/template can take care that things are prepared, but after that, my clients are “alone” and have to do it themselves.

    My clients are mostly business people and have more to do than learning WAI and HTML and I know that they have forgotten it in less than a week.

    I read the part of pagination, capitalized links and direct downloads.

    If i follow all the rules, developing the site will take way more time and cost a small fortune.

    I think it is also up to the developers of the software to take care that the software is more inteliligent (it costs also a fortune, right).

    More and more people, who are no developers will be the ones who delivr content in the internet and this apporach for accessibility is not working.


    Rob van Linda

  • Alex Walker

    You made some great points, Rob.

    One thing you might keep in mind: When explaining the idea of ALT tags to clients, make sure they understand that the world’s most prominent blind user is Google and it’s bots.

    That takes ALT tags out of the ‘be nice’ basket, and places it in the SEO and business goals basket.

    This is a legitimate way for your clients to make their pages more data-rich, more attractive to search engines and better for everyone.

    Win/win ?

    • cyberlooks

      Hello Alex,

      thanks for the reply

      The ALT is not the real problem and, yes, I tell them that Google is a blind user :)

      But when I tell them about a inside a link, they would propably start crying. And when I tell them to add a class to that span, thexy would propably go mad.

      Business people who take a website with a content management system work with an editor which takes “all” the work from them. People are used to Word/Pages/Open Office and adding a span would mean that they had to switch the editor off and do some hand-coding.

      That sounds for them like something Scully and Moulder did in “Te X-Files” :)

      People are often very, yes!, frightened when they start working with Joomla, WordPress, GetSimple or whatever sytsem. It is quite strange, but for many people the internet is still mystic and coding is magic.

      I have a great example.

      My current client is a very intelligent lady, She studied law and manages huges projects as a professional fund-raiser. So she’s a person who is used to challenges and solving problems.

      I always do loads of work to make working with a system as simple as possible. For “dummies” so to say (not meant literally of course!).

      I create classes in the css file to make inserting images in texts more comfortable and easy. An “img_right” and the same for left. When adding these classes to an image, it will have a width in percentage (for RWD) margins and floating.

      I teach my clients at least eight hours twice about how to create content, adding menu-items etc. I also wrote a handbook which explains all the steps very easily and each step is completed with a screenshot with borders around the buttons/parts and whatever is important in that particular step.

      This week my client started “playing around” and creating her first articles and she called me in the middle of the night because she was totally lost.

      These situations come in my mind when I read articles like yours.

      Your article is great and I myself follow these rules, But most people, who own a website, wont be ab le to fulfil these deamnds of accessibility.

      Therefor it is the task of the producers of screen readers to be more flexible. Maybe it should also be a task of the ladies and gentlemen who create the rules for WAI to keep in mind that websites are not owned by professional web developers anymore but that the majority of the webmasters are lay people.

      Writing this, I am thinking about people who get themselves an account at and start blogging. They have absolutely no clue that there is soemthing like accessibility :)

      So imho it should be a goal for the WCAG WG (Web Content Accessibility Guidelines Working Group) to make things more easy. In that case it would be possible for “normal” human beings to make their website accessible for all their visitors.

      So that was a long litany and I hope that it wasn’t tooo boring :)

      Regards from Berlin,


      • Dan Smith

        Hi Rob,

        I personally think that this is something that can be solved with better technology.

        Everyone should care about accessibility – it cannot just be the developer, as an established living site is mostly content and can easily become inaccessible through bad content entry – despite the valiant efforts of the web developer who built the templates.

        The weak point is the WYSIWYG (What You See Is What You Get) content editor plugin. This the point where the client’s content makes its way into the site. These plugins need to support the client through the steps required to create accessible content.

        The client or developer should not need to switch to ‘source code’ view to plumb in accessible markup, it should be available in the WYSIWYG, perhaps via some sort of ‘prompt’ system – eg: “you’ve entered a link but the text is not descriptive enough, here are some tips: x, y, z”.

        This also means that the client or developer does not need to bother with an additional QA step via some online testing tool.

        Sadly some things never happen until there are rules in place to enforce this. Have stricter accessibility rules for Content Management Systems might be a good place to start.


  • Some great advice here, thanks for sharing. Rule number 1 should be a golden rule for every website administrator.

  • “People expect links to be underlined.”
    Like in this article? ;) I don’t think this is true anymore. As long as links have a different color than the surrounding text, people will assume it’s a link.

    • Dobie

      Another thing to consider that users with dyslexia find underlined links extremely difficult to read. So by underlining links, you make them less accessible to a large population. I agree that having colors a different color with enough contrast with a on focus cue is the best accessibility option.

  • Matthew Magain

    Great article Gian—as much as being a useful checklist as a reminder of what’s important when creating websites. Nice work. :)

    • Accessibility Oz

      Thanks Matt!

  • christiane

    Thanks for this article, it is exactly what I was looking for my lesson on programming websites with accessibility features !

    • Accessibility Oz

      Have a look at our Accessibility Factsheets too –

  • Good article with lots of information.

    Re your point about negative tabindex values, I don’t think that using -1 should necessarily be an accessibility issue. Using a tabindex of -1 on an element allows it to receive focus ‘programmatically’ ie using javascript. This is a useful feature in some situations.

    What would be an accessibility issue is to give an item a tabindex of -1 if it is intended to be something that visitors should just tab to.

    • Accessibility Oz

      Yes there are some instances where tabindex=-1 is ok, but they are rare. Sometimes it is just easier to say “avoid this altogether”. The same goes for ONKEYPRESS – there are some instances where it’s ok, but most of the time when we see it is a major accessibility problem.

    • Mallory

      Graham, to make something focusable you can also give it tabindex of 0, gives JS the same abiltiies.

      However I use negative tab indices all the time, esp in e-commerce to prevent 100-tabs-of-death for a single product. It’s better keyboard usability to have a single working link to the product, while for mousers and touch it’s good to have large clickable areas.

  • westernbridge

    Thanks for the article. I didn’t realize Rule #2 uppercase text was so troublesome for certain readers. I was surprised when you said some screen reader software read such links letter-by-letter, even if it’s only modified in the CSS. I’ve decided to drop all instances of all-caps in my links and headlines (I assume it would apply to plain text as well). It’s just not worth it if it’s going to trip up some readers.

    • Accessibility Oz

      Yes, screen readers have problems with all capitalised text – so, great to hear you’re removing your instances!

    • Dean Hamack

      The answer to the all caps issue with screenreaders is to use CSS instead:

      text-transform: uppercase

  • Dan Smith

    Rule 12 is interesting – “All links should be created using A HREF or AREA. The use of ONCLICK on random elements, such as SPAN, IMG and DIV is not permitted”.

    One of the ‘selling points’ of WAI-ARIA is that it allows developers to make non-optimal markup accessible by adding ‘aria-‘ roles and attributes. For example, one could make a span into a ‘hyperlink’ via the ‘link’ role ( Of course the developer would then need to add scripting to make the ‘link’ behave like a native element, and it’s obvious that it would just be easier to use a native element in the first place.

    Regarding the use of ‘more’ links, I’ve also found the aria-describedby attribute to be useful in providing additional information to these.


  • cyberlooks

    Hi Dan,

    I absolutely agree with your post.

    It is a real pain working with Editors sometimes. And I must say that I have been looking for a long time to find the best solution. Not really for accessibility but for client comfort.

    I have found a very good one but they don’t offer real accessibility features. The only thing they “do” is asking “Are you sure? You haven’t added an alternative text in your image”.

    In fact this is more than other editors do, but still.

    Maybe I should write them a proposition, but I have made the experience that large companies don’t really care about the needs or ideas of their clients.

    I just expereinced this with WordPress which has an extremely bad media manger and people are complaining about it a lot, but the developers can’t be bothered.

    But this is not the subject :)


    Rob van Linda

    • Dan Smith

      Hi Rob,

      Many Content Management Systems are open source and extendable (Drupal, WordPress, SilverStripe etc). I think there is an opportunity for someone to build a WYSIWYG plugin that can provide the features that we need. I wonder if any developers here would like to contribute?


  • Accessibility Oz

    Hi Sander
    I don’t have any control over how Sitepoint displays my article!
    If you don’t underline your links then they absolutely must meet colour contrast requirements AND have an additional cue on focus.

  • Accessibility Oz

    Yes but the ARIA-DESCRIBEDBY still isn’t accessible to keyboard only users, so it can’t be relied on to provide additional information

    • Dan Smith

      Are you referring to ARIA-DESCRIBEDBY with elements that aren’t natively focussable, or across the board?

      This demo works in XP SP3 + IE8 + JAWS 13.0.1006 when the Read more link is tabbed to: “Read more, Same page link, Article Heading, Article Description”

  • Accessibility Oz

    Hi Dan
    I’m not talking about screen reader users. I’m talking about people with physical disabilities that can’t use the mouse and are entirely reliant on the keyboard. The ARIA-DESCRIBEDBY content is not available to them.

    • Dan Smith

      Hi Gian,
      In that case don’t those people see the surrounding text content, and in doing so have a better idea of what ‘Read more’ relates to?

      • Accessibility Oz

        Hi Dan,
        Yes that’s true in most cases. However if they are positioned far away from the content (ie the bottom right of a content block where the information is at the top left) it can still be difficult for magnifier users to know what it refers to.

  • cyberlooks

    Hi Dan,

    I think that this is a whole buch of work and that it will need a team.

    Beside that are there manyeditors which can be sused instead of the standard editor (which are mostly really basic and have a uncomfortable usability).

    I alwys buy a very comfortable editor which makes it extremely easy for my clients to work. And that one is not open source, so it isn’t possible to change to code.



  • James Edwards

    I think “click here” is okay in links AS LONG AS the link text also provides context — for example “click here to return to the login page”. There’s nothing about the term “click” that implies mouse interaction — click is a universal action that’s not tied to any particular mode.

    Have you considered the value of “aria-label” with links? Since only screenreaders announce the text of aria-label, it could perhaps be used to provide context to a link that isn’t present for other users, so that (for example) the links make sense in abstraction.

    I’ve used it for image replacement, where a BUTTON element has no text content at all, it’s just an icon implemented as a CSS background, but it does have aria-label to describes its function for screenreaders.

    • Accessibility Oz

      Hi James
      I believe that non-web people will think “click” is tied to mouse interaction. It’s something we all understand as actionable by the keyboard, but remember we work in the web all day, every day. Your random non-web person may not understand.
      I think of ARIA-LABEL (and ARIA-DESCRIBEDBY) as being useful for only screen reader users and there are a lot of other people with disabilities who use the web (eg keyboard only users, magnifier users, joystick users).

      • James Edwards

        I don’t think a random non-web person needs to understand, beyond the context of their own interaction. Perhaps a typical mouse-user doesn’t know that they can click things with the keyboard, but a keyboard user does, and only a keyboard user needs to know about keyboard interaction.

        Essentially, if you had a big button that said “click this button”, I don’t believe there’s a user in the world who wouldn’t understand that — whether they click it with the mouse, the keyboard, or by touch or some other interaction.

        The idea with ARIA-LABEL is that it could be used an enhancement that’s just for screenreader users. So the question is — are there people, who aren’t screenreader users, but who do need links to make sense out of context?

        • Accessibility Oz

          Hmmm. I think it needs some user testing!

    • Mallory

      “click here to return to the login page” still breaks the other big usability rule, that users skim text. Screen reader users do it too. Everyone does, we’re all lazy. Nielsen has studies showing people read the first few words of things like headers, links, and first sentences.

      Meaning (link) “Return to login page” is still better, unless your link styles are nonexistent (I will add silly “click here” text junk if a graphic designer forces me to make links look like regular text).

  • James Edwards

    What WAI ARIA is also very clear on, is that ARIA semantics should be reserved for cases where equivalent native semantics don’t already exist, or where there’s a reasonable case for extending them.

    The “link” role could be used to say that an entire piece of markup is a link, and that’s a valid use-case.

    But for simple text-based hyperlinks, there’s really no need to use the link role, because links already do that job.

    • Dan Smith

      Hi James,

      That’s why I wrapped ‘selling points’ in quote marks, because although I have read literature suggesting that WAI-ARIA is useful for making ‘valid’ span/div based markup more ‘accessible’, I absolutely agree with you that where there is a semantic element that natively supports keyboard accessibility, that should be always be the first choice.

      Out of interest, what is the difference between an HTML5-style block link wrapping a piece of markup, or a generic element with a ‘link’ role in its place? Is the latter less verbose in screen readers?

      • James Edwards

        If the element has an aria-label attribute, then the screenreader will read that instead of the element contents. Apart from that, I don’t know what the behaviour is, as I’ve never yet needed to do that.

  • Frederik Krautwald

    Amazing that huge company Web sites, like Adobe’s, doesn’t comply with WCAG2 regarding visual clues on focus. Obviously, Adobe is not for colorblind people (I should have known).

  • Iris

    Thank you for this amazing article. A lot of interesting information I never thought of and well explained too. Really good read.

  • zepe

    I have a need to hide several links, but at the same time have them easy and quick for me to access

  • Vincent François

    Great article, very precise and detailed stuff.

    In your rule 9, I’m suprised to see that you do not advice to use a list of links instead of a big span with links inside.

    And for each and every of your rule, I think you should mention wether the rule is based formaly on a WCAG success criterium or a damn good and useful accessibility idea, based on returns from real users.

Get the latest in Design, once a week, for free.