What You Need To Know About Accessible Links

Below is a link to some great,  common sense accessibility advice, fifteen rules to code by- thanks to Gian Wild.  Gian rightly focuses on practical accessibility  rather than compliance with mostly outdated regulations (like the 18 year-old Section 508!) A few excerpts:

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.

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!

The article:
https://www.sitepoint.com/15-rules-making-accessible-links/

Sample Section 508 Audit and Primer

Here's a little primer on tagging PDFs for Section 508 compliance, just four pictures worth a thousand words each- this is from an AIM document audit:

Screenreaders like JAWS read the content of standardized "tags" in PDF documents out loud. The name of the tag informs the screenreader as to what the content is- say a top-level heading <H1>, paragraph text <P>, a table <Table>, list <L>, etc. Correctly formed, ordered tags can give a blind reader almost as much information as the sighted reader has- the screenreader can scan the page and "see" the headings, lists, navigate through tables, etc.

So accessibility is all about the quality of the tags. Let's look at the doc. Well, first off, we look at the document properties. Sorry, they are empty, screenreader can't do much with that. But it doesn't matter, because, notice in the lower left, Where it says "Tagged PDF: No"? That tells the screenreader to take a hike, won't read a thing. Kind of a red flag, accessibility-wise, I'd say:

​

Easy enough to edit the meta-data and denote it as a tagged PDF, as there are some tags. Let's read!!!

First thing the screenreader would read out loud is the contents of the first tag. What do we have? look in the left column, the first tag in the document is the page number 63. Oops.... well that's not right obviously- page numbers should not be read out loud, to begin with, but we know right off we have reading order issues:

​

The first section of the tag list is all page numbers. In the next section we finally get to the title page.

Below: First tag is the logo, <Figure> tag- oops....it should have "alt text" like "LA Health Plan logo" to inform our sight-impaired user. Title gag is next, I've opened it up to show what the screenreader sees, "Medi-cal Program". But the title should be tagged <H1>- this one has a <no_paragraph_style> tag that the screenreader just sees as regular paragraph text. (Note: automatic PDF checkers would "pass" this; you can tag a doc as one big <P> tag and fool them...).

Big deal, you say, but wait, it gets better:

​

(What do you suppose those items to the left and outside the page are about? It is tagged content. We'll skip over it for now- certainly not content that needs to be read aloud. Sloppy tagging, at the least, hopefully just stray blank tags.The screenreader will call out "blank" and "Figure- no alternate text exists" as it passes through, doh...)

The real problem with this document, and the final slide in our lesson, comes right away after the cover page. There are NO TAGS on the body of the document. The screenreader would stop after the title page. 

​

The next tags in the tag list are for the back cover, nary a tag in between.

This document is not accessible or compliant with Section 508, I guarantee it. This doc needs a complete remediation job.

Contact http://508compliantdocumentconversion.com/ ASAP!!!!