WCAG 1.3.1 Part 2 or “Pretty is Still Not a Structure”

Welcome back to No Stress Web Success. This is Accessibility for Humans. I’m your host, Lisa Bowers, founder of Five Penny Web Studio, and this is Part 2 of our look into WCAG 1.3.1, Info and Relationships.

If you’re new here, quick context: This show is for people who are responsible for a website and don’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 one-person marketing department. Either way, you’re the person who gets the email that says, “Hey, can you fix this on the website?” And you’d like to understand your site well enough to keep it healthy yourself.

Last week, we asked one big question: Is the structure you can see also in the markup? We covered landmarks, the main region, headings, and lists. If you missed it, go back and listen to the previous episode—it sets up everything we’re doing today.

Today, we get into the places where I see nonprofit websites struggle the most, because they’re the places that matter most to your mission: your forms, your tables, and anything that relies on color or layout to say something. Donation forms, volunteer signups, event registrations, board lists, program schedules—those are the pages where somebody is trying to give, join, or get help. So let’s get into it.

Forms

Let’s start with forms, because if a form doesn’t work for someone, they can’t donate, they can’t register, and they can’t ask for help. This is where accessibility stops being theoretical.

The question for forms is: Are the labels and the groups actually connected to their controls?

Here’s what it means in plain language. On screen, you see the words “Email Address” sitting next to a box. Your eyes connect them instantly. But to a screen reader, those two things only go together if the form is built to connect them. If the label is just sitting nearby, the screen reader may announce “Edit text, blank,” and the person has no idea what to type.

Check number one: Does every field have a real programmatic label?

Not text that just looks like a label.

You may be thinking, “Lisa, I don’t write code.” Totally fine. Here’s a check you can do yourself in about a minute: Click directly on the label text next to the field. If the cursor jumps into the field, the label is connected. If nothing happens, it probably isn’t. It’s a quick test, and it catches a lot.

A very common trap I want to flag: Placeholder text is not a label. That’s the gray hint text inside the box that disappears when you start typing. It looks tidy and designers love it, but it vanishes the moment someone starts typing—which is hard on anyone who loses their place or has trouble remembering. And depending on how it’s built, it may not be announced reliably. Use it as a hint if you like, but keep a real visible label.

Check number two: Grouping

Some questions are answered by a set of controls. Think of a set of radio buttons like “How would you like to receive updates?” with options for Email, Text, or Mail—or the donation amount buttons: $10, $25, $50, Other. Those options belong to one question, so the group needs a meaningful name (usually what’s called a legend). So a screen reader user hears the question along with each option. Without it, they hear “Radio button, twenty-five dollars,” and they may not know what the twenty-five dollars is for. With it, they hear the question first.

Here’s the example I’m going to use to explain this to your board: A person should be able to tell which question a group of radio buttons answers, and what each option means.

Check number three: Instructions, required fields, and error messages

Are they connected to the right field? That red asterisk next to Email—if the form doesn’t also say “required” in a way a screen reader can pick it up, some people won’t know. And the error messages are the big one. If someone submits your volunteer form and a red message appears at the top that says “There was a problem,” but it doesn’t say which field or what to fix, a person who can’t see the red highlighting is stuck.

What I want you to take away here is that instructions and errors should be tied to the specific field they’re about. A good form says in text: “Email address: Please enter an email that includes an @ sign,” and that message is connected to that field.

Practical advice for the real world, where you probably didn’t build your forms from scratch: Most of you are using a form plugin, or the form tool built into your donation platform or website builder. So here’s what I’d do:

• Test one form with your keyboard only. Press Tab to move through the fields. Can you tell what each one is? Can you reach every control, including the Submit button?
• Then look for settings in your form tools for field labels, required field indicators, and error messages.
• And if you’re evaluating a new form or donation tool, ask the vendor directly: “Are your form labels and error messages accessible to screen readers?” Their answer tells you a lot.

Tables

These show up more than you think on nonprofit sites: program schedules, board and staff lists, grant amounts, annual report numbers, event calendars.

First, a distinction: There are data tables and there are layout tables. A data table holds information where rows and columns relate to each other—like a schedule with days across the top and programs down the side. A layout table is a table used just to position things on a page. Layout tables are an old habit and they cause confusion, so for anything new, use proper layout tools and keep tables for actual data.

For your data tables, the question is: Are the row and column headers marked as headers?

Here’s why. Picture your annual report table. Columns for 2024 and 2025. Rows for Program Services, Fundraising, and Administration. A sighted person looks at a number and glances up to see what it means. A screen reader user needs the table to tell them. When the headers are marked correctly, as someone moves through the cells, they hear something like “2025, Program Services, 82%.” When they’re not, they hear “82%” and have to guess what that’s about.

A few other things I check:

• Is there a caption or some nearby context that says what the table is? Even one sentence helps (“Weekly Program Schedule – Fall 2026”).

And a warning I want you to hear, because it’s so easy to fall for: A table that looks clear on screen can still be confusing if its relationships aren’t encoded. If you build a grid by hand with spaces and tabs, or by pasting an image of a spreadsheet, it might look great and communicate almost nothing to a screen reader. And an image of a table is worse, since there’s no structure at all.

What you can do: If your editor lets you toggle a “Header Row” option on a table, turn it on. And if you have a table that’s really a picture, consider rebuilding it as a real table.

Color, Styling, and Placement

Now the sneakiest category. This is where the meaning of something lives only in how it looks.

Here’s the question: If the styling disappeared, would the relationship or meaning still be available?

Think about the ways we communicate without words:

• Color alone (red for errors, green for open, a color-coded events calendar where each program has its own color)
• Bold or larger text alone (a line that’s just bolded to act as a heading, or to mean “important”)
• Indentation or spacing alone (things tucked under other things to show they belong together)
• Position or proximity alone (the form on the right, the note below, a caption that only makes sense because it’s next to a photo)
• A symbol with no text equivalent (a little star, a check mark, an icon that means something to the person who designed it)

If you remember one example, make it the red text. Say your form shows an error in red. If the only thing that says “this is an error” is the color red, then someone who’s colorblind, using a screen reader, or looking at a black-and-white printout misses it entirely. The fix is easy: say it in words. “Error: Please enter your email address.” Color can still help people who see it—it just can’t be doing the job by itself.

Same thing with that color-coded calendar. If blue means Youth Programs, make sure it’s explained with a legend of colors—and then add the word “Youth” to each event. The color becomes a nice extra, not the only signal.

This one is actually where you as a leader can help the most. When your team is writing content or choosing designs, build a habit of asking: “If someone couldn’t see the color, would they still know what this means?” That one question catches a lot.

A Simple Page Review Order

I’m going to walk you through the order I use when I review a page. Pick one important page—your donation page, your volunteer page, or your homepage—and follow along. You don’t need to be technical to do this.

1. Find the major regions: header, navigation, main content, footer. Do they make sense?
2. Find the primary content. There should be one main area.
3. Move through the headings. Do they tell the story of the page?
4. Look at anything that looks like a list. Is it really a list?
5. Test your forms: labels, groups, instructions. Click on your label—does the cursor pop into the input field?
6. Check your tables. Are the headers marked?
7. Hunt for meaning that lives only in color, styling, or placement.
8. Compare what you see with what the page actually says underneath. Does the structure on the screen match the structure in the markup?

That last step is a big one. A free browser extension like WAVE or your browser’s built-in accessibility tools can help you see the structure underneath. Or turn on the screen reader that’s already on your computer or phone and just listen for a few minutes. It’s humbling, and it’s very educational.

How to Turn Findings into Action

For each issue you find, write down four things:

1. Where it happens (which page, which section)
2. What relationship the page is trying to show (for example, “This label goes with this field”)
3. How it is being shown right now (for example, “It’s just text sitting next to a box”)
4. What would fix it (for example, “Connect a real label to the field,” or “Mark the first row as a header”)

Why those four? Because that’s exactly the note you hand to a web developer, a volunteer, or a vendor. It’s specific, it’s fair, and it’s easy to act on. You’re not saying “the site is inaccessible.” You’re saying, “Here’s what’s happening, and here’s the fix.” That’s how you stretch a small budget.

Common Mistakes I See

1. Treating one or two checks as the whole of 1.3.1. Having one main landmark or having no skipped headings is not the entire criterion. They’re good starting points, but 1.3.1 is bigger.
2. Assuming that it’s accessible because it looks clear. If you can see it, it’s easy to believe everyone can. That’s the trap this whole series is about.
3. Confusing a visual style with real structure. Big bold text is not a heading. Typed dashes are not a list. A box beside some words is not a labeled field.
4. Calling every heading-level skip a definite failure without looking at the whole outline. Use judgment and look at whether the structure still makes sense.
5. Adding markup without checking that it’s accurate. More isn’t better. A label that says the wrong thing, or a landmark that wraps the wrong content, can make a page more confusing than before.
6. Fixating on one component and missing the relationships across the full page. A perfect form on a page with no headings and no main region is still a hard page to use.

If you take nothing else from this, take this: You don’t have to fix everything at once. Start with the pages where people give, join, and ask for help. Fix those first.

Closing the Loop

So let’s go back to the question that tied these two episodes together: Does the page’s markup communicate the same meaningful organization and relationships that the visual presentation communicates?

Landmarks and headings are a strong starting point, but a good review also covers your lists, your forms, your tables, and anything where meaning depends on color, style, or placement.

And here’s the encouraging part: You don’t have to be a developer to ask these questions. You just have to be willing to ask: “Is what I see also what’s there?” Everything else is a skill you can build, one page at a time.

Before I go, a couple of things.

First, there’s a major PHP vulnerability that was brought to light yesterday. The patch should be released today, and some hosting providers have already gained access to update and secure the servers. PHP is the language running your WordPress site and your e-commerce site, so having this secured is critical. Reach out to your hosting provider immediately. Ask them specifically if they are aware, how they are handling it, and whether your site is vulnerable. If you have a web developer, ask them: “What version of PHP am I using?” There are still a lot of sites out there that are using older versions that may not get this update.

Secondly, I’d love to hear from you. If you have questions or feedback, or a page on your own site that you’re wrestling with, head over to fivepennyweb.com and send me a note.

And if this episode helped, please take a minute to leave feedback on the podcast—a rating or review wherever you listen. It helps other nonprofit and small-team leaders find the show.

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.