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

computer screens displaying web code symbols

We’ve noticed that businesses, schools, government organizations, and anyone else with a website first learn 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 HTML ans CSS 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 to implement best practices and make HTML and CSS files accessible. 

HTML Accessibility

A large portion of making an accessible and ADA compliant 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 not all HTML elements are equal when it comes to accessibility and 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 and ignore standards for accessibility 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, as examples of Hypertext Markup Language accessibility, 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 version of a metric that measures 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. Following the web accessibility guidelines can significantly contribute to reducing this rate. The lower the bounce rate, the better, because it means people are staying on the website longer. This is often adhered to within various web entities and is incorporated within their policies pertaining to user retention.

On the contrary, a higher bounce rate indicates a poorly constructed site version, particularly if it fails to meet web accessibility standards. A website that ignores the importance of accessibility and lacks necessary elements would fit this description perfectly. Elements of a poorly constructed site include things like non-responsive design, lack of color contrast, and missing form labels.

Our primary aim 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 a staggering 71% of disabled web users will leave a website version that does not fulfill accessibility requirements. This is a large enough percentage to significantly impact the overall bounce rate. Hence, all business entities must incorporate accessibility requirements into their policies to avoid a 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 seek services elsewhere. The value of web accessibility for developers, especially in today’s digital version of the age, is undeniable. Developers take pride in crafting high-quality websites and understand that cleaner code paves the way for a faster and more proficient website. If a website’s load time is slow or it fails to rank high in search results, the development team is usually held accountable. HTML elements (code) have semantic meaning, and web entities optimize their website’s accessibility and performance by using code as intended.

Apart from reducing bugs and enhancing loading speed, semantic code also aids search engines such as Google and Bing in indexing the content, thus facilitating higher search rankings. Let’s imagine a webpage version constructed to compare web development platforms like WordPress and Shopify and how its organization of content using heads and visual elements can increase its potential visibility.

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.

CSS Accessibility

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 to HTML and CSS files, 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 for having more accessible HTML and CSS to transform people’s digital experiences while interacting with your website. 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

doctor viewing test results

Digital Accessibility in Healthcare

Yes, digital accessibility is imperative in the healthcare industry! Find out why it matters and how it costs to ensure equal experience to everyone.

Read more about Digital Accessibility in Healthcare 0 comments
Laptop computer with web statistics information in the screen.

Web Accessibility Laws and Legislation

More often than not, a website is the first impression for potential customers. Because of this, it’s no surprise that today, web design is a $38.3 billion industry.

Read more about Web Accessibility Laws and Legislation 6 comments
employees checking website for WCAG 2.2 compliance

What’s new in WCAG 2.2

Version 2.2 of the Web Content Accessibility Guidelines (WCAG) is here! Find our checklist for new success criteria and the guidelines of the latest version.

Read more about What’s new in WCAG 2.2 0 comments