Accessible HTML and CSS Techniques to Ensure Your Website is Accessible to Everyone

illustration of computer screens displaying code symbols

We’ve noticed that businesses, schools, government organizations, and anyone else with a website first learns about web accessibility when they hear about a website accessibility lawsuit, such as those against Beyoncé, Winn-Dixie, or Domino’s Pizza. Obviously, these businesses did not understand the importance of web accessibility. Aside from running the risk of a lawsuit, the lack of implementing accessibility during development, and with every update thereafter, could potentially exclude 61 million adults in the U.S. alone.

Both Hypertext Markup Language (HTML) and Cascading Style Sheets (CSS) affect a website’s accessibility. Working together, they offer powerful tools to increase a website’s accessibility, search engine optimization (SEO), and overall user experience. We’ll explore some of the ways these languages improve or destroy your website’s accessibility. 

Accessible HTML

A large portion of making an accessible website involves using semantically correct HTML. Thankfully, content management systems, such as WordPress, apply HTML for you. Before you breathe a complete sigh of relief, it’s important to note that it’s your responsibility to ensure it’s applied correctly. Otherwise, assistive technology users will be confused when they attempt to navigate your website. Too often we see websites misuse HTML just to make things visually appealing. 

First, let us explain a little bit about HTML. Each HTML element is represented by a start and end tag, has a purpose, and tells a browser how to display content. You can’t see the HTML tags when just viewing a website; however, you can see them if you look at the source code. Here are a few examples of common HTML elements:

  • Paragraph
    <p>paragraph text</p>
  • Heading level 1
    <h1>heading text</h1>
  • Heading level 2
    <h2>heading text</h2>
  • Unordered list with list elements
    <ul><li>list element 1</li></li>list element 2</li></ul>

Other HTML elements include ordered lists, tables, forms, links, etc. Each one of these elements has a purpose. For example, an unordered list element tells a browser to display items as a bulletted list. It also tells a screen reader the content within the list element is a list and distinguishes individual list items. Screen reader users will use shortcut keys to quickly navigate through list items. Similar to lists, they will also use shortcuts to navigate tables, links, buttons, and other web page elements.

Accessible HTML Headings

One of the most common misuses of HTML we see is with a heading element. A good heading structure is not only important to the visual appearance of your page, but when applied correctly in HTML, the SEO, mobile responsiveness, and overall user experience improve. For example, if you are a sighted user, you notice the title of this article because it is in a larger font size. For the title to be semantically correct, the text must be wrapped in a heading tag. If you view the source code of the page, it will look like this:

<h1 class="entry-title" itemprop="headline">Accessible HTML and CSS techniques to
ensure your website is accessible to everyone</h1>

The h1 is the HTML tag and the class and itemprop are attributes of that tag used for styling and functionality. Too often, we will see the HTML look something like this:

<p style="font-size: 2em; font-weight: bold;">Accessible HTML and CSS techniques to 
ensure your website is accessible to everyone</p>

The user decided they wanted something to visually look like a heading so they applied a style to the paragraph tag. Here are some of the negative effects of this poor technique:

  1. Assistive technology, such as screen readers, do not recognize the text as a heading. When a user scans the page for important topics they expect to be in a heading, this heading is not found. As a result, the content relating to it may be skipped altogether. Additionally, including at least one h1 element on each web page is a recommendation for a web page to be accessible.

    To get a better illustration of this, try reading a page with a free screen reader, such as NVDA if you’re on a PC or VoiceOver if you are on a Mac/iPhone/iPad. With the screen reader, compare the following pages and notice how the good semantic HTML pages are easier to understand.
  2. Search engines give more credit to keywords located inside heading tags. As a result of not using a heading element, the chance of search engines finding the content and displaying it in search results is decreased.
  3. HTML has some styles applied by default. For instance, if an h1 element was used, the styles that the developer applied manually would have applied automatically since the default font size for an h1 element is 2em and the default font-weight is bold. Not having to manually apply styles speeds up development. We’ll explain more about styles in the next section, titled Accessible CSS. (Of course, our Accessible CSS title not only looks like a heading but is presented as a heading in HTML as well.)

As seen in the screen reader examples provided above, using semantic HTML applies to more than just heading tags. Every HTML element must be used for the purpose it is designed for.

We’ve posted free resources to help you learn and apply web accessibility into your workflow.

Access to free resources

How web accessibility benefits business owners

If you are a business owner, you may be familiar with the term bounce rate. The bounce rate of a website is the rate of how long users stay on a website. Unlike conversion rates that we want to be high, our goal is to have a lower bounce rate. The lower the bounce rate, the longer people are staying on the website. 

On the contrary, a higher bounce rate indicates a poorly constructed site. A website that lacks accessibility would be considered a poorly constructed site. A poorly constructed website includes things like non-responsive design, lack of color contrast, and missing form labels.

Our goal is to keep people on our website longer so that they discover more reasons why they should choose us over our competitors. A study found that 71% of disable web users will leave a website when it is not accessible. This is a large enough percentage to have a significant impact against the overall bounce rate. Business owners must prioritize web accessibility to avoid potential loss of customers.

How web accessibility benefits developers and Google

If your web developer argues that web accessibility does not benefit them, then it may be time to find a new developer as it’s just undeniable how vital web accessibility for developers is, especially nowadays. Developers aim to create high quality websites and know that the cleaner the code is, the faster their websites will run. If a website’s load time is slow or a website fails to rank high in search results, the development team is responsible. Cleaner code means faster, high quality code. Semantically correct code is cleaner code. Accessible code is semantically correct. This means that code is written according to specifications. HTML elements (code) have semantic meaning. Developers optimize a website’s accessibility and performance by using code as it is intended. 

Aside from having fewer bugs and making a website load faster, semantic code also helps search engines such as Google and Bing to index the content and achieve higher search rankings. For example, let’s say that a web page is about comparing web development platforms such as WordPress and Shopify. The page visually uses headings to organize its content. The code of the page uses paragraph tags with classes (used for targeting styles) to create the visual appearance of headings like this:  

Accessible UI controls

Another example of HTML uses for its intended design is with user interface (UI) controls. UI controls are the part of a web page that users interact with. Examples include buttons, links, and form controls. A browser’s default behavior for UI controls, such as buttons, allows a user to interact with them using only their keyboard.

To demonstrate this example, place your cursor at the top of this page. Put your mouse aside and press the Tab key on your keyboard. The first link you will come to is a skip link we added for accessibility. This link allows keyboard only and screen reader users to quickly skip the page navigation menu so they don’t have to tab through the entire menu on each page of our website. As you continue tabbing, you will notice a focus indicator on each link you tab to.

Depending on the browser you view this page with, you will see a solid or dashed outline. It’s okay to remove the default outline only if it’s replaced with another visual focus indicator. Otherwise, we create an accessibility barrier because keyboard-only users will not know where their focus is. As you can imagine, this would lead to quite a bit of confusion.

Using semantic HTML does not mean your website has to look plain and uninviting. It’s actually just the opposite. In the next section, we’ll discuss how semantic HTML combined with a little CSS improves your website’s experience for everyone including both visual and non-visual users.

Accessible CSS

We use CSS to control how we display HTML elements on a web page. It’s just as important to use accessible CSS as it is to use accessible HTML. Once we take advantage of the default styles applied while using semantic HTML, we can use CSS to make it appear visually in a way that matches our branding without affecting a web page’s accessibility—as long as we apply it correctly.

Using CSS to allow keyboard accessibility

The most common mistake we see in CSS is removing a link’s focus indicator. As mentioned above, this creates an accessibility barrier, unless we replace the focus indicator with another style. Be default, browsers use an outline style to display a visual focus indicator. While this is a helpful well to rely on automated accessibility, it’s also an example of how accessibility always includes manual testing. For example, Chrome’s default outline style is a blue outline around a linked element as seen here:

focused linked text in chrome with blue outline

While this is okay if the background is white, if the background was blue, we could not see the focus indicator.

focused linked text in Chrome with blue outline and blue background

The outline is declared but it does not pass color contrast requirements, so now we have another issue to fix. 

Firefox does a slightly better job by using a black and white dotted outline as seen here:

focused linked text in FireFox with dotted outline

Again, depending on the background color, we may still have accessibility issues with color contrast, as seen here when applying a blue background:

FireFox default outline with a blue background

Hopefully, no one would ever use this combination of colors, but you get the point. Take advantage of the default styles that browsers apply and then apply better, accessible styles using CSS as needed. 

To improve the accessibility of the link in this example, we can add a 2px dashed outline. Here is the result:

text with 2px dashed outline alternating black and white

We can improve this even a bit more by offsetting an outline and including a box shadow style in a different color so that we are always sure to provide sufficient color contrast regardless of the background color.

improved outline with black offset outline and white box-shadow

Of course, you still need to test color contrast ratios, especially if you are using something more than just black text on a white background. This brings us to another major accessibility concern affected by CSS—color contrast.

Using CSS to ensure color contrast accessibility 

In our recent article, Getting Business Websites and Employee Portals Ready for Coronavirus Telecommuting, we explained how to test color contrast ratios. Businesses often worry that they will lose their branding if they do not apply their brand’s colors to every element of their website. A good developer, who knows how to apply accessibility, will know how to incorporate your brand’s colors to ensure both branding and accessibility are accounted for.

Here are places we use hard-to-pass colors when they are not within the contrast ratio of 4.5:1 as specified by the Web Content Accessibility Guidelines (WCAG):

  • Image borders and/or outlines.
  • Focus indicators along with another color that is within the correct ratios. For example, use the color that does not pass contrast as the outline and also include a text-underline or other indicator that does pass color contrast testing.
  • Decorative elements such as line separators that do not add meaning to the page

Pro tip: The most difficult colors to pass are red, orange, and yellow. If your brand includes these colors and you are struggling to include them where they will be within the color contrast ratios needed for accessibility, use these colors for your decorative elements. Our eyes can play tricks on us so, unless you are using black and white, don’t just assume your colors are within the recommended ratios. Likewise, don’t just assume that because it’s red, orange, or yellow it doesn’t pass. There are color combinations that include these colors and are within the recommended color contrast ratios.

Combine HTML and CSS for a robust accessible website

We only covered a few techniques you can use to improve your website’s accessibility. Using these techniques, along with others that are personal to your branding, will ensure you achieve the accessibility, SEO, and user experience benefits your website deserves. Focus first on the HTML, and then add CSS where needed.

Do you have a unique HTML or CSS technique you use to improve your website’s accessibility? Let us know. We’d love to highlight it for you. 

If you’re struggling with applying semantic HTML or accessible CSS, let us know how we can help. Together, we will create an accessible web and give all users the experience they deserve!

2 Comments

Comments are closed.

Avatar for David Gevorkian

By David Gevorkian

David Gevorkian started Be Accessible because of his passion for delivering exceptional customer service. Prior to Be Accessible, he spent much of his early career working for financial institutions in sales, treasury, and product management. David earned his Master’s in Business Administration from Salve Regina University in Newport, Rhode Island. He discovered a common need for web and mobile accessibility during his previous roles, and as a result, he created Be Accessible to make accessibility in reach for any type of business. David is a strong advocate for creating aesthetic and accessible products usable by all people across the world.

Contact Us

Please complete all fields.

Recent Posts

Man looking at robot wondering if automated scans are better than manual website testing

Automated vs Manual Web Accessibility Testing

There are many accessibility barriers that are easier to find using automated testing tools.

Read more about Automated vs Manual Web Accessibility Testing 0 comments
Rocket by Be Accessible

Get ready to accelerate your digital accessibility with our automated accessibility testing tool

Ensure WCAG 2.1 AA compliance with our easy to use automated accessibility testing tool that evaluates your code and content helping you achieve an accessible website.

Read more about Get ready to accelerate your digital accessibility with our automated accessibility testing tool 0 comments

How Often Should My Business Perform a Full Web Accessibility Audit?

At minimum, we recommend a web accessibility audit once a year depending on how often you update your website.

Read more about How Often Should My Business Perform a Full Web Accessibility Audit? 0 comments