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.”

Links Should Be Underlined

Conventionally, links have always been underlined. With the rise of frameworks and CSS usage, the amount of underlined links has started to decline in favor of using text-decoration:none on anchor tags and only changing the color of the link to differentiate it from other text. This is no good. Links should continue to be underlined for the sake of all of your users.

It is hard for most users to differentiate a link from other text if they are different in color alone (especially colorblind users), but it also makes it more difficult for the user to determine if it is a link at all. Some users may think the different color is meant to show emphasis instead of denote a link.

Another problem is that some users may skim paragraphs in search of links. These links stand out more when they are both underlined and a different color from normal paragraph text.

The only exception to this is navigation bar links. Most people understand that your navbar will take them to other places on your website, so there’s no need to underline these links.

Descriptive Links

It’s important to create links that concisely describe where the link points to. For example, if I was sending you to the blog post mentioned above, instead of saying “to visit my blog post, click here” I would say “Check out my blog post on designing for all users.” When the user clicks on “my blog post on designing for all users” they know exactly what to expect when they get there – a blog post about designing for all users.

Some users elect for their screen readers to read through the links on the page as a way of skimming the text. If all of your links are just “click here,” “more,” “here,” etc., it makes it hard for screen reader users to know where the link will take them to. Hearing all of these links out of context can also be very confusing and disorienting for the user to experience.

Using the word “link” in your links also is redundant if you’ve already followed my recommendation above on underlining the link and used a tag to denote your link. The user will be able to tell that it’s a link based on the underline. A user who relies on a screen reader would know that it was a link because typically screen readers tell the user when they’ve encountered a link.

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.”

Readability is Important

It’s important for all of your content to be easy to read and concise. While there aren’t a lot of guidelines that say whether your paragraphs are accessible or not, there are a few things to keep in mind when writing content for a website:

Keep it short

If you can say something in 5 words instead of 20, say it in 5. People typically don’t like to read. They especially won’t read something if they think it’s too long.

Passive Voice

Don’t use passive voice unless absolutely necessary. Using the direct alternative tends to be easier to understand and shorter than its passive counterpart.

Redundancy

Saying the same thing twice in different ways is usually just a waste of effort. Users rarely will benefit from having the same thing said to them twice. (This bullet point is a good example of what not to do.)

Variety

If your content is long, try to vary the length of sentences within your paragraphs and even the paragraph lengths themselves. Varying the length and sentence structure helps encourage your users to focus.

Readability also includes typefaces, spacing, type setting, line height, etc. For the sake of keeping this blog post under 50 pages and rehashing too many things that are already taken care of in Bootstrap and Ensemble, we’ll stick to some basic ways to help make your paragraphs more readable.

Justification

It may be tempting to use text-align: justify; on your paragraphs so that they’re all even on both sides. Though this works in print form, it doesn’t carry over to web as easily and is actually considered bad practice for web content. While it may make your paragraphs appear a little neater, the readability of your content suffers. Since justifying content tries to make all of the lines in your paragraphs equal, the spacing between words and breaking up words can be distracting for your user. Hyphenating words across lines isn’t even supported by some major browsers, and even if it is, the Javascript used to do it is extremely large because it needs to be able to reference every English word to find the best way to hyphenate them.

Your users will only care that your content is left justified. Jagged lines on the right side of your page should be the least of your worries when it comes to usability and readability.

Contrast

Make sure your main content has sufficient contrast. If you’re not sure if your content has sufficient contrast, check the background color and font color with WebAIM’s Color Contrast Checker. The contrast between the text on your page and the background is very important when ensuring your content is readable. 4.5:1 for large text (18+ point font, typically) and 7:1 for normal text (14+ point font, typically) or higher if possible. High contrast between the background and the foreground is helpful for all of your users.

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).

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.

The Doctype Declaration

The Doctype declaration tells the web browser what version of HTML your web page is written in so that the browser can render it correctly. Even though your page may be complex and have a lot of different bells and whistles, it’s still a document (hence the “doc” part). Documents are just an interface to deliver content to your users. Leaving out this little <!DOCTYPE html> tag can cause the browser to render the content in a lot of strange ways, aptly named “quirks mode” (read more about quirks mode on MDN).

Any time you have elements rendering weirdly, just check to make sure <!DOCTYPE html> is the very first line on your page before hunting for the solution via CSS or trying to compare your implementation to that on Ensemble.

The Lang Attribute

The lang attribute of the element tells the browser what “human” language the website/document is written in. It’s frequently left out of web pages by developers, but its inclusion is very important. One very common usage of the lang attribute is that it helps all of your users fill out forms on the page. The browser takes the page language to determine what dictionary to use to compare text areas against so that any spelling errors that the user makes are evident prior to form submission. Also, the page language helps any third-party translator translate to your user’s native language and helps search engines easily index your website.

Not having a page language declared or declaring the wrong page language could cause a screen reader to use the wrong accent or pronunciation of words. As Heydon Pickering says in his book “Inclusive Design Patterns,” “if <html lang=”en”> is present but the text is actually in French, you’d hear a voice profile called Jack doing a bad impression of French, rather than a French profile called Jaques using authentic French pronunciation.” Computer Braille display users also benefit from having the correct page language set, since even though the French and English alphabets are fairly similar, in Braille, there are many more differences between English and French. Therefore, not only is it important to declare a language, but it’s equally as important to declare the correct language.

Declaring a page language also helps browsers choose and render system fonts with appropriate character sets. This is more important in languages like Chinese, but can be equally as important for English, Portuguese, etc. Having your content render in fonts that don’t have the correct character sets is certainly inaccessible and not at all inclusive.

Sometimes, you’ll have quotes or blocks of text that may be in a different language from that of your page language. To switch page languages for a paragraph, just put your lang attribute in the paragraph tag you’re using for content in a different language. Take, for example, your page content was in English, but you had a paragraph that was in Portuguese:

Not only does the lang attribute do all of this work for you, but it’s so easy. Just add it to the html element of all of your pages. If your page uses a layout, it’s even easier. There’s really no excuse to leave this out.

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 an 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.” First, we’ll describe the type of design used to create accessible content (inclusive design) and how it relates to accessibility.

What is Inclusive Design?

Inclusive design isn’t just about designing for those with a disability, it’s about designing for every single person that could possibly use your web page to accomplish a task. That could be taken as disabled, elderly, millennial, educated, uneducated, etc. Any sort of demographic you can come up with needs to be able to use your web page as effectively as any of the other demographic groups.

As developers, we tend to design for people who are like us, namely people who are very comfortable with computers. We’ve all thought at some point, “well, I know how to use it so it shouldn’t be a problem.” That is the exact opposite of the “inclusive design” way of thinking. Some people, even if they aren’t disabled, are very uncomfortable around computers, to the point where they think they might break a computer if they touch the keyboard. We need to consider those people as well when we’re developing a new product or updating an existing one.

What is the difference between “Inclusive Design” and “Accessibility?”

Inclusive design simply describes a particular way of designing your web page that includes anyone and everyone that could possibly ever want to use your website, as stated above. Web accessibility, in its most basic form, aims to help those with a diagnosable disability. Inclusive design helps everyone. Web accessibility (though is often helpful for everyone) aims to help those with some kind of barrier in their way to accomplish these tasks – also known as a disability. As Heydon Pickering says in his article “What the Heck is Inclusive Design?”, you can think of it this way: inclusive design is the means and accessibility is the end, but you also get much more than accessibility out of inclusive design.

Closing Thoughts

In this blog series, I’m going to go through some of the things you can do to make your products accessible from the very beginning. Accessibility shouldn’t be an afterthought and certainly is not just a feature. Just plugging in some aria attributes and roles is not enough. We can’t wait until the end to make things accessible. By using inclusive design from the beginning, we can make using Corelogic FNC’s products a better experience for every user.