WCAG 1.3.1 or “Pretty is Not a Structure”

Welcome to No Stress Web Success. I’m Lisa from Five Penny Web Studio. This is our series, Accessibility for Humans.

If you’re new here, this show is for the person who’s responsible for the website and doesn’t have a big team behind them. Maybe you’re an executive director who also approves the newsletter and updates the events page. Maybe you’re the whole marketing department. You didn’t go to school for web development, and you shouldn’t have to. You just want a site that works for the people you serve.

Today, we’re starting one of the most important rules in the web accessibility guidelines. Its name is WCAG 1.3.1, and the title is Info and Relationships.

I know that doesn’t sound fun, so here’s the plain English version: A page can look beautifully organized and still be a jumble to someone who can’t see it. Pretty is not a structure.

This rule is big, so I’m splitting it into two episodes. Today is Part 1. Part 2 comes out next week.

Let’s start with a simple idea. Your website tells people things without using words. A heading looks bigger and bolder, so you know that it’s the title of a section. A list has little bullets, so you know these things go together. A label sits right next to a box on a form, so you know what to type there. A different background color tells you this is a sidebar, not the main story.

If you can see the page, you can take all of this in without even thinking about it. But not everyone sees your page. Some of your donors, volunteers, board members, and the people you serve use screen readers. This software reads the webpage out loud, or turns it into braille. Other people navigate by voice or by keyboard. They don’t see your design. They get what’s built into the page underneath.

So here’s the whole rule in one question: When your page shows that something is organized a certain way, is that organization also built into the page itself?

Think of it like a building. A sighted person walks in and sees the signs, the hallways, the reception desk. A person using a screen reader needs the building to have its own directory—one that says “Reception is here, the offices are down this hall.” The signs on the walls aren’t enough.

One honest note before we go on: What I’m giving you is a way to look at your site, a kind of checklist. Some of the items are right at the heart of this rule. Others are just really good habits that support it. I’ll try to tell you which is which, so you don’t panic over something that is a “nice to have,” but also so you don’t miss something that really matters. And you do not have to become a developer. You just have to know what to look for, and what to ask for.

Start with the Big Picture – Page Areas

When I look at a page, I don’t start with a single sentence or a single button. I start with the big picture. Can someone quickly tell what the major areas of this page are?

Think of the signs in an airport. You don’t walk every hallway to find your gate—you look up, you see “Baggage Claim,” and you go there. Most web pages have the same big areas:

• The top of your page (your header)—usually your logo and maybe a donate button
• The navigation menu—the links that take you around your site
• The main content—the reason the person came to this particular page
• The footer—the bottom of the page, with your address, contact info, and policy links

When those areas are built into the page properly, a screen reader user can jump straight into the one they want. They can skip the menu and go right to the story. They can jump to the footer to find your phone number. That’s your airport sign.

If the page is not labeled correctly, those areas are just boxes that happen to be styled to look like a top, a menu, and a bottom. They look right, but to a screen reader, it’s one long flat page with no signs.

Here are the questions I’d ask about any page:

1. Are the main areas actually identified, or do they just look separate? You can’t tell by looking—and that’s the point. This is a great question to ask your web developer if you have one: “Does our site mark the top, the menu, the main content, and the bottom as real page areas?” Most modern WordPress themes do this, but it’s definitely worth confirming.
2. If you have more than one menu—like a main menu at the top and another one in the footer—can someone tell them apart? Those should have short names, something like “Main Menu” and “Footer Menu.” Otherwise, a screen reader just says “Navigation… Navigation…” and the user has to guess which one it might be.
3. Does this help people get where they want quickly? That’s the real test. These areas are not there to satisfy a checklist. They’re there so a person can skip the repeated stuff and get to the part they came for.

And one reassurance: A page does not need every possible area. A simple page might only have a header, the main content, and a footer—and that’s perfectly fine. More isn’t better. The goal is areas that are clear and useful.

The Main Content Area

We’re going to zoom into the main content because it earns its own spot. Here’s what I check: Does the page have one main content area, and does it hold the real content for the page? One—not zero, and not three.

Think of it as a “Start here” button for the page. When a screen reader user lands on a new page, one of the fastest things they can do is jump straight to the main content and skip your logo, your menu, and your search box—all the stuff that’s the same on every page.

The other thing I look for is the opposite mistake: things getting lumped into the main content area that don’t belong there. Your sidebar, your site-wide menu, the newsletter signup that shows up on every page—those aren’t the main content, and they shouldn’t be treated like they are.

Picture a page with your logo and menus at the top, one news article in the middle, and your footer at the bottom. The article is the main content. The top, the menus, and the footer stay separate. A screen reader user can get to your article in one or two keystrokes.

And here’s something I want you to hear clearly: Having one main content area is not the same as passing the rule. It’s a helpful check, and it’s easy to do, but this rule is much bigger than that. Try this: Have your web developer or whoever supports your website confirm that every page on your site has one main content area. That’s a five-minute check with a useful answer.

Headings

Headings tell people what a page is about and how it’s organized. Here’s the big topic, here are the sections, here are the smaller pieces inside each section. And this is the part I really want you to hear: Headings are about meaning, not about how big the text looks.

Here’s the first thing I check: Is this a real heading, or is it just regular text that someone made bigger and bolder to look like a heading? I see this on real sites all the time. Someone is typing up a page, they want a section title, so they select a line and click Bold and make it larger. It looks exactly like a heading, but to a screen reader, it’s just a line of text—and it doesn’t show up when a person asks the screen reader, “Show me the headings on this page.” It is invisible as a heading.

The good news is that fixing it is something you can do yourself. In your website editor (or in Word or Google Docs), there’s a dropdown that usually says “Paragraph.” Click it, and you’ll see choices like Heading 1, Heading 2, Heading 3. Those are real headings. Use that dropdown instead of bold and big. That one habit fixes a huge share of heading problems.

Second thing I check: Do the headings follow the shape of the content? Let me give you an example—picture it as an outline. The page title is the biggest topic. Under it, a section called “Account Setup.” Under that section, two smaller pieces: “Choose a username” and “Set a password.” Then back up a level, a new section: “Troubleshooting.” That is a title, two sections, and the first section has two parts inside it.

Now here’s the test question: Could someone move through the headings alone and understand how the page is organized, without ever seeing the design? If yes, you’re in good shape.

A couple rules of thumb:

• Your page should have one main title, which is the Heading 1 (or H1).
• Your sections are Heading 2.
• The parts inside those sections are Heading 3.

Here’s the nuance (and I mention it because I see a lot of reports getting this wrong): Don’t treat every skipped heading as a failure. If you jump from a Heading 2 to a Heading 4, it can be a warning sign, and it’s worth taking a second look. But the real question is whether the outline still makes sense. Sometimes a skip is a sign someone picked a heading because they liked its size, and that’s worth fixing. Sometimes the page is still perfectly clear. Look at the whole outline and use your judgment.

Lists

This one’s quick, but it’s everywhere on nonprofit sites: ways to volunteer, program requirements, steps to apply, what to bring.

The question is simple: If something looks like a list, is it built as a list?

Most editors have a button for a bulleted list and a button for a numbered list. When you use those buttons, the page knows it’s a list. A screen reader will say something like “List, five items,” so the person knows how many things to expect and when the list ends.

But it’s very common to fake it. Someone types a dash at the start of each line, or a bullet symbol, or types the numbers themselves, or just presses Enter between lines. On screen, it looks like a list. To a screen reader, it’s just a stack of unconnected lines.

Here’s a real-life example. Say your volunteer signup page says:

• Step 1: Fill out the form.
• Step 2: Attend orientation.
• Step 3: Choose your shift.

If each step is its own separate paragraph, a sighted person sees a sequence. But the page itself just has three unrelated lines. If you use the numbered list button, the page knows it’s a sequence.

One more thing to keep in mind: If the order matters, use the numbered list. If it doesn’t, use bullets. Steps to apply = numbered. Things to bring = bulleted.

And a bonus: Real lists keep their spacing and look consistent, even when someone makes the text bigger or uses their own settings.

Putting It Together

Today we asked one big question: When a page looks organized, is that organization also built into the page?

• Are the major page areas labeled so people can jump around?
• Do we have one main content area so the real content is easy to find?
• Headings that are real headings, not just big text?
• And lists that are built as lists?

Those are a great start. And notice that most of them are habits you can build yourself, in your editor, with no code. But they’re only the start.

Next week, in Part 2, we’ll cover the places where I see the most trouble on nonprofit websites:

• Your forms (the donation form, the volunteer form, event sign-up forms)—whether the questions are connected to the right boxes, and what happens when someone makes a mistake
• Your tables (like schedules and board lists)
• And what I call “meaning that hides in color”—like a red message that only works if you can see red

Then I’ll run you through a simple page check you can run yourself. So come back next week for Part 2 of WCAG 1.3.1.

In the meantime, if you are interested in testing your own website, I will put the links and descriptions to two different Google Chrome extensions that I use quite often—WAVE and SilkTide—and you can install those in your Google Chrome and test out your own website for some of the various things that we’ve talked about today.

As always, if you have questions, feedback, or if you’re struggling with a page on your own website, head on over to fivepennyweb.com, send me a note, and I’ll be happy to reply to you.

If you found this episode helpful, please take a moment and leave a review. It helps us and it helps other nonprofit and small business leaders find our show, and we’d like to know how we’re doing and what we can do to better help you.

Once again, this has been Accessibility for Humans, part of the No Stress Web Success Podcast. I’m Lisa, and I will see you next time.