Introduction

Accessibility is the practice of making your websites usable by as many people as possible. We traditionally think of this as being about people with disabilities, but the practice of making sites accessible also benefits other groups such as those using mobile devices, or those with slow network connections.

You might also think of accessibility as treating everyone the same, and giving them equal opportunities, no matter what their ability or circumstances. Just as it is wrong to exclude someone from a physical building because they are in a wheelchair (modern public buildings generally have wheelchair ramps or elevators), it is also not right to exclude someone from a website because they have a visual impairment. We are all different, but we are all human, and therefore have the same human rights.

Accessibility is the right thing to do. Providing accessible sites is part of the law in some countries, which can open up some significant markets that otherwise would not be able to use your services or buy your products.

Building accessible sites benefits everyone:

Semantic HTML Elements

As you learn more about HTML — read more resources, look at more examples, etc. — you'll keep seeing a common theme: the importance of using semantic HTML (sometimes called POSH, or Plain Old Semantic HTML). This means using the correct HTML elements for their intended purpose as much as possible.

Semantic HTML doesn't take any longer to write than non-semantic (bad) markup if you do it consistently from the start of your project. Even better, semantic markup has other benefits beyond accessibility:

  1. Easier to develop with — as mentioned above, you get some functionality for free, plus it is arguably easier to understand.
  2. Better on mobile — semantic HTML is arguably lighter in file size than non-semantic spaghetti code, and easier to make responsive.
  3. Good for SEO — search engines give more importance to keywords inside headings, links, etc. than keywords included in non-semantics, etc., so your documents will be more findable by customers.

People sometimes write headings, paragraphs, etc. using line breaks and adding HTML elements purely for styling, something like the following:

            <span style="font-size: 3em">My heading</span> <br /><br />
    This is the first section of my document.
    <br /><br />
    I'll add another paragraph here too.
    <br /><br />
    1. Here is
    <br /><br />
    2. a list for
    <br /><br />
    3. you to read
    <br /><br />
    <span style="font-size: 2.5em">My subheading</span>
    <br /><br />
    This is the first subsection of my document. I'd love people to be able to find
    this content!
    <br /><br />
    <span style="font-size: 2.5em">My 2nd subheading</span>
    <br /><br />
    This is the second subsection of my content. I think is more interesting than
    the last one.
HTML Images

Whereas textual content is inherently accessible, the same cannot necessarily be said for multimedia content — image and video content cannot be seen by visually-impaired people, and audio content cannot be heard by hearing-impaired people. We cover video and audio content in detail in the Accessible multimedia, but for this article we'll look at accessibility for the humble <img> element.

We have a simple example written up, which features four copies of the same image:

          <img src="dinosaur.png" />

      <img src ="dinosaur.png"
      alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human,
       with small arms, 
      and a large head with lots of sharp teeth." />


      <img src="dinosaur.png" aria-labelledby="dino-label" />


      <p id="dino-label">
        The Mozilla red Tyrannosaurus Rex: A two legged dinosaur standing upright like
        a human, with small arms, and a large head with lots of sharp teeth.
      </p>

The first image, when viewed by a screen reader, doesn't really offer the user much help — VoiceOver for example reads out "/dinosaur.png, image". It reads out the filename to try to provide some help.

When a screen reader encounters the second image, it reads out the full alt attribute — "A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth."

In this case of the third image, we are not using the alt attribute at all — instead, we have presented our description of the image as a regular text paragraph, given it an id, and then used the aria-labelledby attribute to refer to that id, which causes screen readers to use that paragraph as the alt text/label for that image. This is especially useful if you want to use the same text as a label for multiple images — something that isn't possible with alt.

Content Highlighting
Emphasized text

Inline markup that confers specific emphasis to the text that it wraps:

            <p>The water is <em>very hot</em>.</p>

      <p>Water droplets collecting on surfaces is called <strong>condensation</strong>
      </p>
          
            strong,em {
                color: #a60000;
              }

You will however rarely need to style emphasis elements in any significant way. The standard conventions of bold and italic text are very recognizable, and changing the style can cause confusion.

Color and color contrast

When choosing a color scheme for your website, make sure that the text (foreground) color contrasts well with the background color. Your design might look cool, but it is no good if people with visual impairments like color blindness can't read your content.

There is an easy way to check whether your contrast is large enough to not cause problems. There are a number of contrast checking tools online that you can enter your foreground and background colors into, to check them. For example WebAIM's Color Contrast Checker is simple to use, and provides an explanation of what you need to conform to the WCAG criteria around color contrast.

Screen Reader Accessible Content

There are many instances where a visual design will require that not all content is shown at once.

Screen reader users don't care about any of this — they are happy with the content as long as the source order makes sense, and they can get to it all. Absolute positioning (as used in this example) is generally seen as one of the best mechanisms of hiding content for visual effect because it doesn't stop screen readers from getting to it. On the other hand, you shouldn't use visibility:hidden or display:none, because they do hide content from screen readers. Unless of course, there is a good reason why you want this content to be hidden from screen readers.

Screen Reader Only Content

There are occasional instances where content should be made available to screen reader users but hidden from sighted users. In the vast majority cases, content that is available visually should be available to screen reader users, and vice versa. Verbose cues or instructions that are only read by screen reader users usually do more harm than good. However, there are a few cases where information or meaning is apparent visually but may not be apparent to screen reader users. In these rare cases, it may be appropriate to cause content to be read by a screen reader, but have the content remain invisible to sighted users.

            
    HTML:
              
    <div class="sr-only">This text is hidden.</div>
            
    CSS:
            
    .sr-only {
      position:absolute;
      left:-10000px;
      top:auto;
      width:1px;
      height:1px;
      overflow:hidden;
    }
Reference

The documentation on this page is taken from MDN