This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

It’s important for your users to know where they are on your page at all times. This is especially true for your keyboard users, who often find it difficult to determine their location on a webpage.

Some elements, such as those that use divs, do not automatically receive keyboard focus or allow the user to navigate to them via the keyboard. Elements that are clickable but wouldn’t receive focus normally, such as infographic boxes in Ensemble, need to have the tabindex=”0” attribute added to them. Interactive elements should always be accessible. This way, keyboard users can navigate to them, see that they have received focus, and hit enter to navigate to the same place a mouse user would be able to navigate to.

For elements that are mostly text, such as paragraphs, keyboard focus isn’t necessary, although some users may find it helpful. To make sure blocks of text receive focus, add the tabindex=”0” attribute to your paragraph tag. This will addition will only enhance the experience of your keyboard users without adding any unnecessary visual noise for your mouse users.

Interactive elements that are written using semantic HTML have keyboard focus features baked in. Some examples of these would be <input type=”[text,email,tel,etc/checkbox/radio]”>, <button>, <select>, and <textarea>. Even though these elements are typically accessible, it’s important to always test your page for keyboard accessibility by tabbing through and making sure the tab order is logical.

Browsers typically implement their own focus styles, which are usually fuzzy blue halos or dotted lines. I like to use the browser default, but there are other ways to add styles to make focus more obvious than what is implemented by the browser. It is important, however, to NEVER remove or add styles that contradict the browser’s default implementation of focus styles. These are very important and help a variety of users.

An example of an improved focus style would be gov.uk’s implementation. They give the focused element a different background color from the rest of the text on the page.

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

Screen readers start out by first, as we discussed in the last blog post, announcing the page title. The next thing it starts to announce is the navigation bar. If this isn’t the first page the user has visited on your site, they may not want to hear the navigation spiel over and over again. It will also help keyboard users to not tab through every link in your navigation to get to where they need to go in your main content. “Skip to Content” links can help your users bypass blocks of repeated content and generally have a better experience on your website.

It is important for this skip to content link to be the first element in your body tag for it to be beneficial. These skip links shouldn’t be visible by default because a lot of your users won’t need it (and it’s kind of an eyesore). To show your skip content link to those who actually need it, just add class=”sr-only sr-only-focusable”. This ensures that screen readers will read the skip content link immediately after announcing the page title and will be the first thing your keyboard users can navigate to.

<main id=”main”>

The main element is used to contain the main content of the page (of course). This content will be unique from page to page. According to the W3C HTML Editors Draft, the main element “consists of content that is directly related to or expands upon the central topic of a document or central functionality of an application.” It was introduced to HTML5 formally as a way to map the ARIA role “main” to an HTML element, (ideally) eventually phasing out the need for role=”main”.* Many screen readers and other assistive technologies recognize the main tag as where the main content of the page begins and gives the user a way to bypass repetitive content, such as navigation bars.

Since the main element represents the main content, it should be used only once per web page. It also can’t be used as a child element of any other document outline element, such as <article>, <aside>, <footer>, <header>, and <nav>. Also, it is important to make sure your navigation bar is not included in your <main> element since it is repeated on all of the pages of your website.

Some people still print out web pages. This is very possible since we work with clients that sometimes need to go out in the field and have the information we provide to them on hand. The main element also makes it easier for us to accommodate users who print out our web pages. The main element helps these users by targeting an area of our page that has all of the information they need to be able to print (i.e. data tables) and none of the stuff they don’t (i.e. navigation elements).

*NOTE: You should still use role=”main” until all browsers map the role to <main> automatically. I believe IE11 and earlier still don’t. In older versions of IE, it may be necessary to add document.createElement(‘main’); since it doesn’t recognize main as an element.

This UX Accessibility Blog Series, “Setting Up An Accessible Web Page,” will walk you through the basic elements of an accessible web page in hopes that you can take what you’ve learned and apply it to more complex pages. This blog series is loosely based on Heydon Pickering’s book “Inclusive Design Patterns: Coding Accessibility Into Web Design.”

Let’s Recap

The title element on your page is the first thing users see to know where they are. In the UX Workshop Series: Web Accessibility presentation, I made the analogy that the title of the page is much like the title of a book. The title of the book is printed on the spine (usually) so that before you even pick up the book, you know what it is. Imagine if all books had blank spines and covers, leaving you to search through the pages to see what book it was and what it was about. This is how your users feel when your title is either missing or doesn’t describe the purpose of the page.

Also, having a descriptive page title satisfies Guideline 2.4.2 of WCAG 2.0: “Web pages have titles that describe topic or purpose”. This is a Level A Guideline, meaning it’s a base guideline to follow to ensure your website is accessible.

Making Your Title Accessible and Inclusive

Since most assistive technologies announce the page title before doing anything else, it’s usually your user’s first impression of your website. If your page title just says “CMS.Net” on a create order page or “FNC, Inc.” on a contact page, that’s a poor first impression. Give your users a little heads up as to what they can expect from the page by changing the previous titles to “CMS.Net – Create an Order” or FNC, Inc. – Contact Us”. If your site is uses a layout and different body, make sure your title changes to reflect the purpose of that particular page.

The page title is also important for the following reasons, as outlined by the University of Washington’s Accessible Technology post “Providing an Informative Title”:

Appears in title bar or tab in most browsers

Appears as the bookmark name if the page is saved as a favorite

Identifies the page in search results

Another way to make sure your title is accessible is to ensure there are no duplicate page titles in your website. This can cause confusion to anyone looking at your sitemap. Also, duplicating page titles is just bad practice (a theme you should be seeing – accessibility and inclusive design techniques are just good practice).

Progressive enhancement is a core piece of web accessibility and inclusive design. According to Wikipedia, “progressive enhancement is a strategy for web design that emphasizes core webpage content first.” It’s mostly about building your website from HTML up. This means adding all of your fancy stuff (CSS and Javascript, if you will) after ensuring that your content is understandable on its own.

Using progressive enhancement, the end result of your website will be much stronger since you’ll be planning out your project and presenting a functional system using the most basic web technologies. According to Sam Dwyer in his article “Progressive Enhancement: What It Is and How to Use It,” this allows you have a strong foundation to fall back on as you introduce more complex technologies (like CSS and Javascript) to the project.

Not only will your project be stronger, but it’ll be much easier to maintain. With your foundation done and stable, you and other developers on your team can focus more on the complex sections of the system without having to worry much about what you already have.

It’s also good for your users (of course). If they can repeatedly visit your website successfully, they’ll come to know your brand as being reliable. Any disabled users will have the benefit of knowing they can visit your website without worrying about if their specific assistive technologies will work with your content.

Steps to Developing with Progressive Enhancement

Create your page with semantic markup.

This will only be the content of your page. If your page is a form, this will only be the markup for the form in plain, semantic HTML.

Add any PHP, Ruby on Rails, etc. needed to make your form functional.

Make it look a little prettier.

Add some CSS (classes from Ensemble/Bootstrap) to make it look more appealing.

By simply developing your project a little differently, you’ve hopefully gained a better understanding of your project’s requirements, made our clients happy with a stronger product, and sleep a little better knowing you’ve created a better and stronger solution that helps more people.

Accessibility Help

If you have any questions about accessibility, don’t hesitate to email me at ksween@fncinc.com. I’ll be happy to help and answer your questions to the best of my knowledge.

Improved Search Engine Optimization

“More” what? What does “More” mean? We have no context for what this means, where this link will take you, or why. This is a common problem among users that use screen readers. Just like you and I, screen readers “skim” websites to find what’s interesting. Typically, links are interesting, so the screen reader will read ONLY link text. It’s easy to see why this could be problematic. If a user’s screen reader is just reading “more,” “click here,” “here,” etc. it isn’t helpful for that user. Your user should not have to click on the link to find out what it is for. (Guideline 2.4.9)

At this point, I assume you’re wondering what any of this has to do with search engine optimization (SEO). Search engines look for keywords when crawling the web. Keywords in links are more useful than plain text, thus increasing the chance that your website will be found using search engines. If your links just say “more,” you just missed out on a great deal of page views, which for some people or companies could mean lost customers.

User Experience

Although we have a department dedicated to UX at FNC, UX is EVERYONE’S responsibility. How ALL users interact and experience a website or product is everyone’s problem. Making your website accessible is a great way to start thinking about situations all of your users could be in.

We like to think that people who are blind, deaf, or have a learning disability are the only ones that are helped by the web accessibility guidelines we’ve learned about previously. This isn’t the case. We’re all affected by temporary disabilities in our daily life. Take, for example, the following scenario:

You’re outside looking at Facebook on your phone. It’s extremely bright outside, therefore hard to see your Facebook feed. This is one way to simulate having a visual disability. By going to the accessibility settings on your phone and increasing the contrast (for example Settings > General > Accessibility > Increase Contrast on iPhone), it makes everything on your screen easier to see. If you’re also walking while browsing Facebook, it might be hard for you to click on links or “like” a post. This is similar to the challenges people with motor impairments face every day.

At any point in our day, we could be on the spectrum of disability.

Legal Repercussions

If you’re not making your websites and products accessible, you’re discriminating against 1 in 5 people that try to use your products.

Both Harvard and MIT have been sued by the National Association for the Deaf in 2015 for failing to provide closed captioning for their online educational videos. Both universities argued that the current laws do not explicitly state that universities to caption web videos even though it would be the right thing to do for their disabled students.

Regardless of the outcome of this case, being the defendant in this situation is much more expensive than the cost of handling accessibility in development. If Corelogic FNC were to be sued, it could give the company bad publicity. This would keep new clients from considering Corelogic FNC’s products and could cause current clients to stop using our products.

Increasing Your Potential Audience

Half of people over the age of 40 start to lose the ability to focus on things close up. More than 37 million adult Americans (about 15%) are hard of hearing or completely deaf. Over 22 million adult Americans (nearly 10%) have trouble seeing or are completely blind. It’s estimated that as many as 15% to 20% of Americans are affected by a learning disability or disorder. In general, about 1 in 5 people have some kind of a disability. This is why it is SO important to make our products and websites accessible. So many people are being excluded from certain products because of something they can’t help.