HTML & landmarks

Alright. It’s time to talk about HTML landmarks and what you need to know right now. This information is adapted from atomica11y.com, atomic a 11 y. com, and from TheBookOnAccessibility.com.

You’ll notice this lesson isn’t titled accessible HTML and landmarks, because if you created an HTML page that isn’t accessible, you didn’t actually create an HTML page. All you did was make crappy decoration, and that’s not what we’re here to do today. Listen, we can’t possibly cover every accessibility piece of code, every rule, and every nuance about HTML pages today. But what we can do is instill in your mind that there are rules and requirements you need to follow, and that you can go look all of this up with complete demos and code examples on atomica11y.com.

To be sure we’re talking about the same thing. When we say HTML, that means hypertext markup language. And if you didn’t know that, shame on you. A web page or an HTML page is something you can visit. There’s stuff you can read and click on, and there are inputs you can type in. This pretty much covers the vast majority of what we consider to be an HTML page.

To make our web pages accessible, we have to be sure we don’t create barriers for any people with the following disabilities. Starting with low vision, we’re talking about people who are using their desktop device, they’re using their smartphones, they may be increasing the default font size, using magnification tools, or pinching and zooming in on a handheld device. Considerations for cognitive disabilities include remembering information, difficulty navigating complex processes, or just needing more time to complete tasks. When we’re talking about people with motor disabilities, we’re talking about people who can’t use a mouse or tap on their screen or can’t do so with precision. So they may use a keyboard, a Switch device, which is something akin to a game controller, or they may be using voice command to operate their device. When we’re talking about blindness, we’re talking about people who are using their desktop device. They’re using a handheld device, but they’re using an application called a screen reader that reads to them what’s happening on their screen in combination with a keyboard or on a handheld device with a sequence of taps and swipes.

Starting with low vision, we want to accommodate people who resize the default text on their device. This is different from hitting Command or Control plus on your browser and zooming in in that way. We’re talking about literally resizing the default font up to 200% with no loss of information. Oftentimes, you’ll find that people who change the default font size on their handheld device would say they don’t have a disability. They just like the larger text because it makes it easier to read.

We also want to ensure that we’re supporting landscape or portrait orientation. If you have some clever pop-up that comes up from the bottom, We want to think about how much of the screen real estate that that is taking up, and is that interfering with the ability to read what’s on screen?

We must also make sure that pinching and zooming in on a handheld device is enabled. Another way we accommodate people with low vision is we ensure that content can zoom in the browser up to 400% without horizontal scrolling. If you’re designing responsive mobile-first applications and websites at 320 pixels, you’re going to be covered on this.

For people using the keyboard, the arrow keys scroll the page up and down. Or when using a screen reader, the arrow keys read each individual piece of content line by line. The tab key enters the page and visibly focuses only interactive elements. Now, I cannot emphasize this enough. Interactive elements are components like links or buttons or inputs that the user actually interacts with. Items like headings or paragraph text are not focusable. For people using a mobile screen reader, they will use a series of swipes or taps to read and move focus within the page. Anyone using a screen reader must be able to understand and determine the name of the web page they’re in and be able to navigate any landmarks or forms that are discoverable with screen reader shortcuts.

Let’s listen to a screen reader demo of page titles. Basic web page demo. Atomica11y. Selected. Tab. Group. Close tab. Button. Coffee Roast Guide. Atomica11y. Tab. Group.

You see that each of these two pages that are open in this browser right now have unique names.

Html pages must have a unique name. It’s crucial that you understand that this is not the heading level one of the page. These are completely different things. The title lives in the head of the code of the HTML page. The heading level one is the visual page title that you read in the main content. They don’t have to be perfectly identical, but they should be a close match. This is important because anyone coming to this page, whether they have a disability or none, will want to know that they are in the right place. This is incredibly important for search engine optimization as well. Google reads your page much in the same way a screen reader does, looking for programmatic meaning from the title and those headings.

Landmarks are a way to navigate page structure for people using screen readers. You will almost always have these three landmarks. The header often contains a navigation landmark named main or site menu, and a search feature. The main content landmark is exactly that. It contains the main content of the page.

The footer landmark will often contain site map navigation and any legal info. Now, here’s the tricky thing. A screen reader reads the header as banner and the footer as content info, and that’s okay. Let’s watch a demo.

Landmark’s menu. Five Items banner. Site menu navigation. Main. Content information. Site map navigation.

If you find yourself creating a page with many different types of content in the main landmark area, it can be helpful to break that up into sections. Sections are read as regions in most screen readers. If you have multiple forms per page, make sure that every form has an aria-label associated with it so that it’s easy for someone navigating by form landmark to identify the different forms.

And lastly, we must declare a language in the HTML element itself. This is so important because it affects the pronunciation the screen reader will use on your page.

Let’s consider when it’s okay to deviate from accessible patterns. Maybe you saw Apple or Google do something. Look, just because Apple and Google are big, successful companies doesn’t mean everything they do had people with disabilities your disabilities in mind from the beginning. Maybe your manager thinks that something inaccessible just looks cooler. But as a designer, as a developer, it’s your responsibility to advocate for people who are using your product. So do the right thing. Maybe someone is telling you that this project is on a tight deadline and there’s just not time to understand all of this HTML landmark business. That’s nonsense. It doesn’t take any longer to write accessible code than it does to write code that creates barriers for people with disabilities. Or maybe your developers are saying it’s just not possible to add the proper HTML attributes and landmarks to your page. There are plenty of examples on atomica11y.com they can implement into their own code.

And that’s the end. Go forth and come back when you need help. You can always find detailed information on atomica11y.com. And if you’re building an enterprise accessibility program, thebookonaccessibility.com is for you. Thank you.