7 days of unlimited WordPress themes, plugins & graphics - for free!* Unlimited asset downloads! Start 7-Day Free Trial
  1. Web Design
  2. Accessibility

Accessibility: What’s Your Markup Saying to You?

Scroll to top
Read Time: 20 mins

Today we’re going to look at accessibility and semantics. Let’s start with a question: have you ever used a screen reader? If the answer’s no, you should try it - it might well change the way you approach your HTML markup for ever!

During this article we’re going to look at the structure of a web page, the way in which screen readers interpret that structure, and improvements we can make to our own markup to enhance accessibility.

A Quick Word About the Demo

I pulled together a sample web page in order to demonstrate how specific markup is processed by screen readers. I also wanted to demonstrate semantic HTML5 markup at its most basic - something which I hope you find useful. Lastly, I know how you lot like source file downloads to come with a tutorial, so enjoy pulling it apart!

a11y demoa11y demoa11y demo
The demo

The demo is a simple, flexible one column page. It’s not responsive, but is well set up to be made so should you want to: it uses relative horizontal units (%), and relative units (em) for the fonts. Images are flexible and alter in size according to the dimensions of their parent container. It also uses a couple of groovy Google fonts. Light-weight and clean.

The Web Standards Model

If you’re a regular visitor to the site, you’ll have heard time and time again that when building a website it’s important to separate concerns. This is all part of what we recognize as the web standards model; comprised of structure, presentation, and behavior.

Structure we build in the form of our HTML markup, presentation is our styling (how the content appears in any given user agent) which we tackle with CSS, and the behavior of a web page, front-end interactivity, which we usually achieve with javascript.

Keeping these three aspects of web design separate is beneficial to us in practical terms - it’s far easier to maintain content which is divided like this and not all jumbled together.

Separating concerns is also beneficial in terms of understanding. We, human beings, usually process a web page thanks to how it’s delivered via a browser. But there are other ways in which a web page is accessed, not least of which being by Search Engine Robots, who crawl the raw structure of pages in order to accurately categorize and rank the content.

Then, we have Assistive Technologies (AT) such as screen readers. Screen readers interpret computer interfaces and say what they see, helping the visually impaired to use them. Web pages are one such example of interfaces, and screen readers read the content as it’s presented to them in the markup. Confusing and messy markup logically results in accessibility problems, even though the rendered web site may appear faultless in the browser.

Note: It’s important to bear in mind that, while this tut focuses on the visually impaired, optimizing accessibility benefits users restricted in other ways too (motor, auditory, cognitive etc.)


Even if you’ve haven’t grasped what’s meant by Semantics you’ll have probably heard the term thrown around a lot. Semantics in web design refers to the meaning given to HTML markup. The move away from table-based layouts saw huge improvements in the semantic value of (X)HTML markup, table cells made way for <div> tags (divisions), unordered lists (<ul>) became commonplace, and we started using things like <em> (emphasis) instead of <i> (italic) to further distance our markup from presentational code.

Currently, the web design community is getting to grips with HTML5 markup, and thanks to a wide array of new elements we can describe our markup in more detail than ever. Primary navigation still usually takes the form of an unordered list, but it can now live nested within <nav> tags, which perfectly describe what it’s doing there.

For help with proper semantic HTML5, check out what the guys over at HTML5Doctor.com are up to.

Have You Ever Used a Screen Reader?

It’s surprising how few web designers have actually used screen readers. Testing your work from the perspective of someone who’s visually impaired can be as rewarding as it is frustrating, but I recommend you try it at least once. Screen reader tools can be pretty tough to grasp, so make sure you recognize the difference between poor accessibility and simple incapability to use the software..

Screen readers use alternative navigation (via the keyboard) to highlight, process, and interact with various elements on the screen. Jumping between the controls on your browser and the controls within a webpage can be tough to begin with! However, once you’ve gotten to grips with using the tools, the (in)accessibility of your markup will become clear.

There are several commonly used examples, here are just a couple of them for your reference:

Note: Interestingly, according to demographic research performed by webaim.org, the largest portion of screen reader users cite Internet Explorer as the browser they commonly use when reading web pages. Microsoft’s interpretation of the CSS spec not getting in the way there I guess..

Example Markup

I often get tutorial submissions for web page builds which, although they look perfectly fine in the browser, and they make use of the correct doctype, often leave it there for HTML5. That’s a shame, because it doesn’t take much effort to bring on board some HTML5 semantic markup.

Let’s start with an example document. To begin with, rid yourself of any doctype that looks similar to this:

For valid HTML5 we need nothing more complex than this:

Let’s now flesh out the rest of our basic web page:

This is fairly typical of how we would have structured a page before HTML5 elements headed our way. It’s perfectly fine, and can be styled without any real problems.

We have a home-main div, which itself sits nested within a wrapper div. Within home-main we find a couple of article divs, and we’re going to complicate things further in a second by jamming some more divs in there.. watch this..

You see? To each article div we’ve added an image, nested in a div so as to bind it to its caption, plus another div which acts as a footer at the bottom.

Now let’s add some presentation; some CSS styles. Firstly, some reset styles, taken in their entirety from Eric Meyer:

Then we’ll add our own styles. You’ll notice a couple of alien fonts, grabbed from the Google fonts API and applied using @font-face. The rest is self-explanatory, and the result demonstrates little in the way of complications.

In fewer than 200 (un-condensed) lines of CSS, we’ve styled our page nicely. Nothing too fancy–centered headings and menu items, a nice large font size (100% of the browser’s default, usually 16px), and images whose containers float to the right. The most complicated of the styles is arguably the dual box shadows on the menu items and the image containers. Anyway, styling doesn’t fall within the scope of this tut, but feel free to pick it apart as you want.

Improved Accessibility

There are several areas where we could have improved accessibility in our markup. For a start, the <img> tags are missing the alt attribute. Browsing the site under normal circumstances would breeze over that issue, but anyone with images turned off would be oblivious to there ever having been an image. Screen readers will, at best, state that there’s an image present, but they can’t tell the user any more than that.

Use the alternative text as a chance to describe the image. This will benefit users, search engines, and therefore also you.

The document is also severely lacking in semantic meaning, users navigating your page with a screen reader can’t determine any hierarchical value within the text. A div with a class of footer says absolutely nothing about the contents to anyone (except you), it simply allows your CSS file to target it.

In terms of maintenance, it’s also difficult to distinguish all the nested <div> elements present; the sheer number of them further demands the need to comment your closing elements. Trying to maintain order in sections of markup like this is tricky!

Let’s then swap out some of the superfluous div tags for more semantic elements:





Here’s the complete HTML markup, polished up with glorious semantics:

So what are the improvements we’ve made? Well, in addition to adding alt attributes to our images, we’ve used the following seven elements:

  • <header>: We’ve used this at the top of our document where our main heading and navigation are. We could also use this tag as a header for sub sections of the markup (such as articles).
  • <nav>: This tag plays host to anything which acts as navigation in a web page. Our primary navigation is the perfect example, but nav tags can also wrap pagination (for example).
  • <section>: We just have the one section, but this is a great tag for grouping associated content.
  • <article>: An article can be described as a chunk of information which can stand independently from its surrounding content, without losing meaning. In our case, we have two articles, each consisting of a title, some text, accreditation, and a relevant image.
  • <figure>: The figure tag allows us to contain our images, then also associate meta information such as..
  • <figcaption>: Our caption has now been placed in such a way that it’s associated with its sibling image.
  • <footer>: We have a footer at the foot of our page (hmmmm) but, like header tags, these can also be used in sub sections, as we’ve demonstrated within our articles.

Try using elements such as these whenever you can. Use div tags, by all means, but only if you can’t think of a more appropriate semantic element. In terms of styling, you can’t really go wrong, and at the moment it’s no crime if you use elements in the wrong place. You have to start somewhere, so don’t be afraid of using articles and sections imperfectly.

With some slightly edited CSS, the result in the browser is...no different.

How Does a Screen Reader See It?

Here’s our design, as seen through the eyes of Google Chrome’s screen reader extension, and OSX’s VoiceOver.

When VoiceOver is left to process an entire web page (Control-Option-A) it strolls through the DOM sequentially, dictating whatever content it comes across. Latest versions allow you to specify points on favorite web pages which you can jump to, but whether the cursor finds itself looking at a link, a list, a paragraph, or an image, it reads it as best it can.

Our efforts have gone unnoticed!

You might notice, aside from the weirdly attractive voice, that VoiceOver made no mention of our navigation being placed within a <nav> tag, and completely ignored any presence of articles. This is the reality of the situation at the moment; HTML5 isn’t yet well supported across screen readers, our efforts have gone unnoticed! In much the same way that markup and styling standards are slowly (but surely) implemented by browser vendors, so screen reader developers find themselves in the same situation.

To stay up to date with the status of HTML5 accessibility and screen reader development, you can do much worse than keep an eye on Bruce Lawson. He’s often pushing the issue, blogging about it, and talking about it. Alternatively, check out www.accessibleculture.org for regular screen reader product testing.

Help in the Form of WIA-ARIA

WIA-ARI-WHAT?! The WIA (Web Accessibility Initiative) ARIA (Accessible Rich Internet Applications) is a specification which helps assistive technologies interpret HTML markup. It uses attributes to describe elements in several ways:

  • Role: An element’s purpose (yeah, ok, its role)
  • State: An element’s current state (think checked check box)
  • Property: Any one of a ton of properties (such as the horizontal position of a slider)

Particularly where states and properties are concerned, you can imagine they’d be otherwise difficult for assistive technologies to interpret. We can happily add ARIA attributes (within limits) to our markup, and crucially, they validate as part of the HTML5 spec.

WAI-ARIA is intended to be a bridging technology. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page. www.w3.org

Here’s an example of how we could further improve our markup - we take this:

..and we add this:

Again, this is valid HTML5.

We’ve added a role attribute of navigation to our nav element, which might seem counter-intuitive, but for the time being it helps. (Some) screen readers will now properly recognize our navigation. Further down the line, when the HTML5 spec has been properly adopted by devices of all kinds, the element nav will imply an ARIA attribute of navigation (and ditto for other elements), rendering it unnecessary.

We can also add a role to our header:

And finally gain our article some deserved recognition:

For more details on available roles and how to use them, check out Virginia DeBolt’s comprehensive introduction to ARIA roles.

So we’ve finally updated our markup to improve accessibility. Take a look at the finished article, though to notice any real difference you’d need to view it with a suitable screen reader of course. Your best bet at the moment would be to test using JAWS, or NVDA as these score highly for their handling of both HTML5 semantics, and ARIA attributes.


I hope this article has helped you gain better perspective on the role you can play in improving accessibility across the web. Practice standards-based web design, pay attention to developing technologies, and even if your efforts can’t yet be used fully, you’re at least future-proofing your work. Thanks for reading (or listening)!

Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Web Design tutorials. Never miss out on learning about the next big thing.
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.