Broadly speaking this is the principle that your website must be able to be safely navigated for all users. This includes the guideline that your entire website should be accessible by using the keyboard alone. Furthermore, the way your website responds to user input (by keyboard or otherwise) should be predictable, clear and safe. 

This last point refers chiefly to ensuring that any potentially seizure-inducing feature of your site is disabled by default, and users warned before enabling it. This principle also provides guidelines on providing 'enough time' for users to complete tasks, but we don't cover it here.

Keyboard Accessibility (2.1)

Being able to navigate and use your site with only a keyboard is one of the most important aspects of accessibility. Blind users will rely on keyboards almost exclusively, and those with motor disabilities may have difficulty controlling a mouse, and so also rely on keyboard access. Some individuals may have little or no use of their hands, and rely on larger keyboards, mouth sticks, head wands, single-switch, or Sip 'n' Puff. 

You can find descriptions of these devices on the WebAIM website, but they all essentially channel user input into keyboard strokes. If your website isn't accessible by keyboards, then all users relying on these devices will be unable to use your site.

Fortunately, making your theme or plugin keyboard accessible is relatively simple. Here are some key points:

Ensure Your Entire Menu Can Be Accessed by Keyboard

A lot of themes rely on hovering over a menu item to reveal any sub-menus. This is fine, but generally the sub-menu will not appear if the parent menu item has focus (rather than hover). If you duplicate any relevant rules for :hover and apply them to :focus also, this will get you halfway there: the sub-menu items will appear as the user tabs across the menu. However, once the user tabs down to the sub-menu, the parent menu loses focus and the sub-menu disappears. This can be corrected using JavaScript. Details on this and how to provide a non-JavaScript fallback will be covered in the next article of this series.

Don't "Trap" Users

You do not need to do anything to make 'native' form inputs (select, input, radio, etc.) keyboard accessible. However, should any aspect of your page (including form fields) gain focus, it must be possible to move away from it using only a keyboard—otherwise the user is effectively trapped. This is normally default behaviour, so you should just avoid overriding it.

Make Navigating Easy and Clear (2.4)

This guideline has two types of recommendations: make finding where the user currently is obvious, and make getting to where they want to go easier. 

Part of following the recommendations in doing this involves something a lot of themes already do: Have a consistent navigation menu across pages, highlight the current page, and allow users to quickly determine where they are on the site (e.g. with breadcrumbs).

Styling :Focus Properly

A key part of being able to use a keyboard to navigate around a web page is being able to see precisely what has currently got focus. The element which currently has focus should be visibly different, and distinguishable from the rest of the page. For this reason you should avoid outline:none; unless you are going to provide alternative styling:

a:focus{ 
    outline: none; 
    background: #ee7b00; 
    color: #fff; 
}

Focus Order and Tabindex

Another important part of keyboard accessibility is that tabbing behaves predictably and in a natural way. For instance, if the focus is currently a form field, I would expect that the next tab should take me to the next field in that form. If tabbing causes the focus to jump up and down the page erratically, then this will frustrate and disorientate the user.

Avoid using tabindex: The tabindex attribute allows you to alter the order in which elements are reached by tabbing. However, if you followed the advice in article 2 of this series regarding the DOM structure, the tab order should reflect the "natural" order of the page. While tabindex has its uses, these are rare, and its use to 'patch' poor site structure can create further issues. The best method is to avoid using tabindex, and instead have your theme produce a logical DOM structure, with CSS used to alter the visual presentation.

Avoid "Read More" or "Continue Reading"

Screen reader users will often jump between links, skipping the text between, and at each link the screen reader will read out "link [link text]". As such, it's incredibly unhelpful to such users if they repeatedly hear "link read more", "link click here" or "link continue reading". Adding context to the link in this case simply involves providing the post's title. So instead of "Continue reading", we have "Continue reading [post title]".

To do this in a WordPress theme, we simply need to hook onto the excerpt_more filter and append our "continue reading" link:

//Adds "continue reading X" link 
function mytheme_continue_reading_link() { 
    return '<p class="read-more">' 
        . sprintf( 
            __( '<a href="%s">Continue reading %s</a>', 'mytheme' ), 
            esc_url( get_permalink() ), 
            esc_html( get_the_title() ) 
        ) 
        .'</p>'; 
        
} 
        
    
//Replaces "[...]" (appended to automatically generated excerpts) with an ellipsis and mytheme_continue_reading_link(). 
function mytheme_auto_excerpt_more( $more ) { 
    return ' &hellip;' . mytheme_continue_reading_link(); 
} 
add_filter( 'excerpt_more', 'mytheme_auto_excerpt_more' );

This gives the "read more" link proper context. However, there are a couple of improvements that can be made.

Firstly, the addition of the article title will typically ruin the aesthetics of the theme and, for sighted users, will be redundant, as the position of the "read more" link in relation to the article title and excerpt will make the context obvious. To get around these problems, we can "hide" the article title, but in a way that screen readers will still read them.

This means we cannot use display:none or visibility:hidden; as screen-readers understand these properties and will ignore the content. Instead we can position the text off-screen or use the clip property:

.screen-reader {
    position: absolute!important;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0,0,0,0);
    border: 0;
}

There are plenty of different examples of "screen reader classes"; this particular one is taken from Bootstrap 3. Next, add the appropriate class to the article title, specifically replacing line 5 above with:

__( '<a href="%s">Continue reading <span class="screen-reader">%s</span></a>', 'mytheme' ), 

Secondly, while this would give users an indication as to where that link was pointing, they would still have to listen through "link continue reading..." before reaching the post title. Ideally you should put redundant information at the end of the link text, or omit it from the anchor tag entirely, to reduce the time it takes to identify a link. 

Another benefit to screen reader users of not preceding linked text with redundant information is that screen readers will often generate a list of links on a page. If a lot of your links start with the same text, this can make finding a desired link harder—particularly if the link for your contact page is under "H" because it reads "How to contact us".

Use the <title> Tag Properly

The <title> tag should be used to identify the current location of the user. This is read out by screen readers, and appears in search results and on the screen window and browser tab. To make it easy for users to identify where they are (or what the search has found), this title tag should contain the page's title and the website name. Ideally the website name should come last, so that people using screen readers do not have to listen to the name of your site on every page load before they hear the page title.

The title tag can be added to a theme with:

<title><?php wp_title(); ?></title>

To add the site title:

/** * Append site title to page title */ 
function mytheme_wp_title( $title, $sep, $seplocation ){ 
    return $title . ' | ' . get_bloginfo('name'); 
} 
add_filter( 'wp_title', 'mytheme_wp_title', 10, 3 );

Skip to Content

Typically websites will have a common header and navigation menu which, with the exception of highlighting the user's current position, will remain exactly the same. Having to tab through all these links, or listen to a screen-reader repeat them on every page load, is tedious and frustrating. Those of us with good (enough) eyesight and motor skills can immediately jump down to the content—and we can make this just as easy for those that don't.

If you're in your WordPress admin, and press Tab after the page loads, you'll notice a link that says Skip to main content appears on the top-left (If you press tab again, a Skip to toolbar link will appear). This link sits at the very top of the page, so that it is the first link that receives focus when tabbing, and the first link of the website read out by a screen-reader. Following that link jumps the user straight to the main content, skipping out all the unnecessary links and site logos in between.

Creating a skip to content is a great way of making your website easier to navigate, and it's incredibly easy, requiring only a minor bit of HTML and some CSS. 

First the HTML. The link should go at the very top of your page, immediately under the <body> tag. In most themes this will be the header.php file:

</head> 

<body> 

    <a class="skip-link" href="#main">
        <?php _e( 'Skip to main content', 'mytheme' ); ?>
    </a> 
    
    //Rest of page content

The only things to note here are:

1. The href value, in this case 'main'. This must match the ID of the element that contains the page's content.
2. The class of the link, which we'll use for styling.

Regarding (1), your loop will then look something like:

<div id="main" class="hfeed" role="main"> 

    <?php if ( have_posts() ) : ?> 
    
        //The Loop
    
    <?php else: ?>
        
        //No posts found... display search
      
    <?php endif; ?> 
    
</div>

and your page templates might look something like:

<div id="main" 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> 
        
    </div> 
    
</div>

Now all that remains is to add some styling to the link. 

First, we want the link hidden but not hidden to screen-readers, so we'll position the link off-screen rather than using display:none (in which case screen-readers ignore it). 

Secondly, when it gains focus we want to make the link obvious, so it is clear that a previously hidden link is now visible and has focus.

.skip-link { 
    position: absolute; 
    left:6px; 
    top:-100px; /* position offscreen so it's not visible, but can receive focus*/ 
    z-index: 100000; /* Position above WordPress' toolbar */ 
    font-size: 1em; 
    font-weight: bold; 
    display: block; 
    background: #ee7b00; 
    color: white; /*Style the link so that's clear*/ 
    height: auto; 
    width: auto; 
    line-height: normal; 
    padding: 15px 25px; 
    text-decoration: none;
    -webkit-transition: top 1s ease-out; 
    transition: top 1s ease-out; 
} 

.skip-link:focus { 
    top: 5px; /* Move onto screen */ 
    -webkit-transition: right 0s; 
    transition: right 0s; /*Animate, to make its appearance obvious */ 
}

Make Navigating Your Site Safe (2.3)

Lastly, be aware that some people are susceptible to photosensitive epileptic seizures. This can be caused by flickering or flashing effects. Last December Jeff Chandler removed a "snow" effect from WP Tavern after a visitor warned him that it could trigger a seizure.

This isn't limited to seizures—it can trigger migraines or panic attacks in some individuals. Nor is it limited to snow effects—a video, carousel or audio file autoplaying can also trigger these. 

Although this is largely an editor's decision and as developers it is not our job to prevent auto-play, we can at least discourage it, by disabling it by default. Jeff mentions in his article that he couldn't find a plugin providing the "snow" effect which visitors themselves could play.