This principle states that all content must be in a format (or available on demand in a format) which can be readily perceived by the user. Said another way, your websites should be designed such that anyone can 'read' the content, regardless of any disability they may have. Many users with disabilities will use assistive technologies; for example those with visual impairments may use a screen-reader, which reads out what appears on the screen, or a text-to-braille converter. The goal then is to facilitate these assistive technologies.

Please remember that the guidelines here are not exhaustive, so you should always refer to the Web Content Accessibility Guidelines.

Provide Text Alternatives for Images (1.1)

Use the Alt Tags for Images

This is perhaps the most common advice for improving accessibility. If your website contains any images, then these are ignored by screen-readers unless you use the alt tag. 

Note that the alt description might not necessarily be a description of what the image is, but rather what the image is trying to convey. The alt tag says in words what you're trying to say with the image. 

While this advice is mostly suited to editors, I raise it here because theme developers will often provide for a logo instead of text to convey the name of the website or company. In this instance, it is probably best to use the site's name (get_bloginfo('name')) as the alternative description:

echo '<p class="site-title"><a href="' . esc_url( home_url( '/' ) ) . '"><img id="logo" alt="'.esc_attr(get_bloginfo('name')).'" src="' . $logo . '">' . get_bloginfo('name') . '</a></p>';

Alt tags should not be used for purely decorative images, otherwise you are essentially forcing the user to sift through excessive and unnecessary information.

Provide Alternatives to CAPTCHAs

If your plugin creates a form, you may require some sort of confirmation that it is being accessed by a person rather than a computer. If you decide to provide the user with an image or audio clip, which they must then interpret, you should explain this, in text, and provide an alternative form of CAPTCHA to accommodate different disabilities.

Ensure Content Can Be Discerned (1.4)

Don't Rely Solely on Position, Colour or Shape to Convey Meaning

This guideline will largely apply to plugin developers, but can also apply to themes. If colour, shape or position are used to convey a meaning that is not discernible from the text, that meaning is lost on users who are colour blind or blind.

For instance, a typical example might be contact form buttons relying solely on an icon from the popular icon font Font Awesome:

<button><span class="fa fa-envelope fa-lg"></span></button> 
<button><span class="fa fa-times fa-lg"></span></button>

The purpose of these buttons is readily evident to a sighted user, but for those relying on screen readers there is no indication what the buttons do. If, for design purposes, you want to avoid using text, you should specify the label using the aria-label attribute.

<button aria-label="Email">
    <span class="fa fa-envelope fa-lg"></span>
</button>

This is just one example of the ARIA protocol, which we'll cover in more detail in the next article.

Ensure There Is Sufficient Contrast Between Text and Background

This is an almost obvious requirement. Even for a well-sighted person, a website with a low contrast between text and background is difficult to read and can cause eye-strain. For those with vision impairments, an even greater degree of contrast is required, which is why the WCAG states that background and text colour should have a contrast ratio of 4.5:1.

It's not immediately obvious what that ratio looks like or means, but there are a variety of tools that help you check the ratio:

• http://leaverou.github.io/contrast-ratio/
• http://juicystudio.com/services/luminositycontrastratio.php#specify
• http://www.colorsontheweb.com/colorcontrast.asp

Larger text has a lower requirement of 3:1, and logos, text that is pure decoration or not visible, and 'disabled' text/buttons do not have a contrast requirement.

Although most themes offer their users the ability to adjust the colours used on the website, it's a good idea to ensure that at least the default colours (or available 'palettes') meet the minimum contrast requirement. Later in this series we will look at building a feature into your theme which warns the user if they are selecting colours with insufficient contrast.

Avoid White Backgrounds

The British Dyslexia Association recommends avoiding pure white backgrounds for text and instead using an off-white colour, cream or a soft pastel colour. The reasoning behind this is that the brightness of a white page can 'dazzle' the reader.

For those suffering from Scotopic sensitivity syndrome (or Irlen syndrome), a too high contrast between background and text can exacerbate symptoms such as:

• text appearing to move on the page (rise, fall, swirl, shake, etc.)
• "losing " the text content and only seeing rivers of white through the text
• text appearing fuzzy

These symptoms make reading difficult and uncomfortable, and can cause eye fatigue, eye-strain, drowsiness and headaches.

In view of the previous section, the best advice is to ensure good contrast, but not too much contrast. As preferences with vary between individuals, quite what constitutes "too much" will be down to personal judgement.

Organise Your Page Structure (1.3)

A structured layout, with appropriate use of headings, makes it easier for users to understand the information being presented to them. Screen reader users rely somewhat on a 'sensible' structure to help them find their way around a page.

Structure Your Theme's Layout

A quick way to test this is to view your theme with CSS and JavaScript disabled. A better way is to use Lynx which is a text-based browser. If your site's structure causes the content to appear in a disorganised fashion then it'll be hard for users using Lynx or other assistive technologies to read your website. Because users relying on such technologies do not have the advantages that CSS and JavaScript bring in aiding orientation on the page, and the flow of content, it's important that the correct reading sequence is obvious without them.

This is fairly simple to achieve: ensure HTML mark-up reflects the intended visual order. This is quite natural, and if you find that your website doesn't read well without CSS, then you've probably intentionally deviated it. As a general rule of thumb your website should follow the pattern:

• Title
• Navigation
• Main content
• Side content
• Footer

Use Headers Appropriately

This one is pretty easy to get right. The rules are simple:

1. Use <h*> tags for headers only—not just to apply a particular style to some text.
2. Search engines and screen readers both use header tags to structure your page, so think about how you're using them. They should reflect the page's structure.
3. Use them in order: <h3> should be nested inside a <h2> and <h2> inside a <h1>. (This follows from (2)).

One question that is often asked is: Should my site title be inside a <h1> tag? The W3C recommendations indicate that while there are some cases where this would be a valid thing to do, in the context of WordPress themes, it's probably best not to use <h1> tags for the site title. There are a couple of reasons:

1. The site title should be included in the <title> tag. While this is often overlooked and a bit ugly for visual users, it is the first thing read out by screen readers. Therefore wrapping the site title in <h1> gives it redundant prominence to screen reader users, while making the title more obvious for sighted users can be achieved without use of the header tag.
2. The header tags are used to organise information. Your site title isn't particularly useful for such a purpose.

Regardless of what you decide, the subsequent headers on your page should sit below it. So, articles in "The Loop" or your page titles should have <h2> tags if you've used the <h1> tag for your site title, and <h1> tags otherwise.

After the post content, most themes will display the post's comments. It's natural to have "Comments" as a heading, as it's a logical break from the content, but as its tied to the post content, the heading level should reflect this. The most logical thing to do is to have the "Comments" header one level underneath the post title.

Here's an snippet from a single.php:

<div id="content" role="main"> 
    
    <div id="post-<?php the_ID(); ?>" <?php post_class(); ?>> 
    
        <h1 class="entry-title"> <?php the_title(); ?> </h1> 
    
        <div class="entry-content"> 
            <?php the_content(); ?> 
        </div><!--.entry-content--> 
    
        <?php comments_template(); ?> 
    
    </div> 
    
</div>

In my example I've used an <h1> tag for the post title, so the comments template (comments.php) might then look something like:

<div id="comments"> 

    <h2 class="comments-title"> 
        <?php printf( _n( 'One Comment on %2$s', '%1$s Comments on %2$s', get_comments_number(), 'mytheme' ), number_format_i18n( get_comments_number() ), get_the_title() ); ?> 
    </h2> 
    
    //... 
    
</div>

Ensure Your Site Responds Well to Increased Text-Size (1.4)

Some users with mild visual disabilities may rely on enlarging font-sizes rather than assistive technologies such as screen magnifiers. In view of this, the WCAG guidelines specify that your site shouldn't "break" when the text is enlarged by up to 200%. "Break" here means text disappearing, colliding, overflowing out of its containers, or more generally the layout of the site being disrupted so that it is difficult or confusing to read.

Use Relative Font-Sizes

Because modern browsers have become better at resizing text, using relative font sizes is not as important as it used to be (although IE9 doesn't resize font sizes defined in pixels). Regardless, it's still recommended to use relative font sizes (percentages, ems or rems). The rem unit addresses some of the issues with the em unit—and although it was only introduced with CSS3, you can use it in a backwards compatible way with legacy browsers. Details of how to implement relative fonts are slightly out of scope, but you can find out more here:

• Taking the "Erm.." Out of Ems
• Font Sizing with REM

Use Fluid Layouts

However, resizing text can lead to layout problems. Text might be pushed off screen, forcing the user to scroll, or text might bleed out of its container, potentially into other text, making parts of the webpage illegible. This where a responsive (or fluid) layout can help. "Responsive" sites are designed to adapt to whatever device they are being viewed on; as such they rarely use fixed pixels for height/width or font-size. Consequently, such sites usually behave well when font-sizes are changed: their layout doesn't break.

The WCAG guidelines recommend not only that text should be able to be enlarged by up to 200%, but also that the website can accommodate the increased text size. Responsive web design can aid that because:

• a magnified screen adjusts to the 'smaller' viewport size
• elements are moved to eliminate horizontal scrolling
• non-fixed sizes prevent overlapping or cut-off text
• images are resized to fit the available space, and do not overlap with text

However, it's important to note that responsive design and accessibility are not the same thing: although they may complement each other, they ultimately have different aims. A responsive site is not necessarily accessible, and vice versa.

Use Mark-Up Correctly (1.3)

Only Use Tables to Represent Data

The use of tables as aids in a page layout is (hopefully) a thing of the past. There are also accessibility-related ramifications for misusing tables. Tables are intended to represent data or information, and as such rows and columns have an inherent meaning, and screen readers assume this when reading out data. 

A screen reader, for example, will read out the row and column number before reading out the contents of the cell. Since the cell position in tables used for purely presentational purposes is irrelevant, this information can be confusing, or at the very least irritating: the end user is being told there is some tabular structure, when really, there isn't.

Correct Use of Table Mark-Up

Most theme developers won't need to produce tables (and the WordPress posts calendar is already accessible). However, plugins may display tables through shortcodes or widgets. There are number of things to be aware of when producing the table mark-up:

• Where possible, keep tables simple. Although spanned rows/columns have been standard mark-up for many years, they are not universally supported by screen readers.

• Where appropriate, provide a <caption> element at the top of a table, describing what the table shows:

  <table> 
      <caption> ... </caption> 
      ...
  </table>

• Use <th> for table headers and <td> for table data. <th> cells should never be empty.
• Provide a scope for <th> cells, indicating if it is a row or column header: <th scope="col"> or <th scope="row">. Although the scope is often determined by the screen reader, it doesn't hurt to be explicit.
• You can use <thead>, <tbody> and <tfoot>, but they offer no benefits in terms of accessibility.

• Use the title attribute of headings to explain an abbreviation used in the cell:

  <table> 
      <caption> February 2014 </caption> 
      <thead> 
          <tr> 
              <th title="Monday" scope="col">M</th> 
              <th title="Tuesday" scope="col">T</th>
              <th title="Wednesday" scope="col">W</th> 
              <th title="Thursday" scope="col">T</th> 
              <th title="Friday" scope="col">F</th> 
              <th title="Saturday" scope="col">S</th> 
              <th title="Sunday" scope="col">S</th> 
          </tr> 
      </thead> 
      ... 
  </table>

ARIA & Forms

Accessible Rich Internet Applications (ARIA) attributes are useful in identifying the purpose of a particular part of the page, any properties (e.g. labelling a required form input as such) and state (e.g. labelling a button as disabled). Using them can help assistive technologies understand your website better, and so present your page more clearly to the end user. We'll be looking at ARIA in the next article in this series. Later on in the series, we'll also be looking at correct form mark-up, and accessible feedback.