Skip to content

Category: physical impairment

A11y 101: 1.3.1 Info and Relationships

A11y 101: 1.3.1 Info and Relationships

Published on January 13, 2025

Whenever I come across a a violation of 1.3.1, I have a primal need to look deeper. I investigate because I believe if something falls under this success criterion, it is most likely improperly classified. It is extremely important that we understand the relevant context, information and relationships of content. Frequently, I observe that this particular success criterion is misused. It often serves as a catch-all for “Where does this go?”

So then what does go here?

Per WCAG, 1.3.1 Info and Relationships is:

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Cool. We used the original words to define it. I didn’t like third grade English when I was in third grade.

Let’s look at the intent:

The intent of this Success Criterion is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes. For example, the presentation format changes when the content is read by a screen reader or when a user style sheet is substituted for the style sheet provided by the author.

Now this is better. We’re given a breakdown and example. The intent is to ensure that what is visually indicated as structural, explanatory, and informational is available to everyone. This includes people using different presentation formats.

Structural

When talking about structure, it is crucial to distinguish between visual structure and code structure. We need to consider both.

When we look at our mock-up of a page, we want to absorb it visually. Is the most important item in the page grabbing the eye? Does the way it is designed lead you to the next thing you want to say or a primary CTA

(Call to Action)? Take it all in, then we start deciding what HTML elements best represent all those pieces of the page. We begin to think of how we order them. Should it be in a landmark like header, aside, footer, main, or nav? Or is does it need a textual element like headings, anchors, paragraphs, lists, or quotes?

Information

We need to ensure that any information expressed visually is communicated non-visually. If a button is disabled, how do we inform a screen reader user it is disabled? How does a screen reader user know if a Menu is opened? This is the information we should be looking for. In many cases ARIA attributes will be the answers to provide this information.

Relationships

Under relationships we find little programmatic lines connecting the page together. We might specify via aria-label that the first navigation is the “Primary navigation.” Forms point to a more direct relationship in how we set up labels, inputs, and error messages. Using the label’s “for” attribute we build a relationship of the name and input. Aria-describedby with the ID of an error message is another bridge creating a relationship.

Here’s my problem

Much of the time these are not errors of information or relationships. They’re a failure of properly using HTML or ARIA. Sometimes both.

In my example of using the landmarks to construct the basic layout, it isn’t a violation. But we didn’t provide an accessible name. That’s a violation of 4.1.2, so why dump it here?

My disabled button? Case of missing aria-disabled, a 4.1.2 issue.

Headings used out of order? Not a WCAG SC.

Headings not sized to their importance? Now you have a 1.3.1 violation! The visual size provides a hierarchy of importance. On the code side we do this with heading elements H1 – H6.

The Fix

Info and relationships are important on the web. They provide context and details that may not be picked up right away. Anything we do on this account visually needs to be conveyed programmatically too. But that doesn’t mean everything that falls into this bucket belongs. Dumping things in here can harm your clients. You might not provide them enough context to resolve their issues.

Look deeper at the issue. Is it a matter of a screen reader not announcing something? Look at the code, is it missing ARIA? Does it apply to another criteria? Make sure you flag it the right way. And don’t flag it twice, once here and once under the other SC. If it fits under another SC, then fixing it under that criteria will fix it for 1.3.1 as well.

Have a thought, feedback or concern about this article, let’s discuss it on BlueSky or LinkedIn.

Comments closed
Ticketing Challenges: Finding Wheelchair Accessible Concert Seats

Ticketing Challenges: Finding Wheelchair Accessible Concert Seats

Published on October 24, 2024

I love concerts. People performing live music is one of my greatest pleasures. Music is critical to my soul and is beyond crucial for keeping up my mental health.

My wife is less thrilled with concerts, but is always up for a fun time with the right people. Weird Al announced a tour with Puddles Pity Party. Two of our favorite artists. One of the stops is our home town just after our anniversary. One of our closest friends is also a fan and knows Puddles. Off I went looking for tickets!

Checking out the tickets I saw that Ticketmaster and StubHub were selling them. I know that resellers like StubHub tack on additional costs and fees. I do my normal thing and head directly to Ticketmaster instead.

My wife has POTS, so when we go out she is in a wheelchair. I have a vestibular disorder that makes standing for long periods impossible. It is made worse with loud environments and big crowds (Sounds like I shouldn’t go to concerts, huh?). So we can only go to shows that have seating & wheelchair accommodations.

The location they are playing at is mostly general admission to stand on the field. It’s a stadium, so there is some seating. Ticketmaster showed only 1 wheelchair accessible ticket. Most of the seated areas were marked “sold out” a day after release. I decided to check StubHub for those “sold out” areas.

StubHub showed there are tickets in areas where Ticketmaster said tickets were sold out and I’m thinking, “Options!” StubHub does not provide a way to filter for disabled seating!

Previous Outings

We went to see Marc Maron last year. I opted to buy, from TicketMaster, an “Accessible seat” on an aisle. Upon arriving to the facility, the accessible seat was a regular seat. No where in the purchase process did it say it wasn’t wheelchair compatible.

The onsite TicketMaster people helped move us to the ONE wheelchair seat as it wasn’t sold. There was only space for one chair and one companion. And of course another wheelchair user showed up and they stuffed them in with us.

I learned from this that even if TicketMaster says there is accessible seating, it may not be wheelchair friendly. And the only way to actually buy accessible tickets is to call the venue.

We aren’t going to see Weird Al or Puddles. The one “accessible” seat won’t work for a wheelchair user.

Comments closed
You Need Accessibility Testing

You Need Accessibility Testing

Published on January 5, 2016

This probably isn’t the first time you’ve heard it. Somewhere along the line somebody asked you how well your site or application works for people that are blind. You probably mumbled something along, “They don’t use our stuff,” or maybe, “I don’t know, does it matter?” The short answer is, yes it matters. And you want to pay attention to why.

Accessibility isn’t Just the Blind

Accessible products and websites are often built with the blind in mind, however what it means to be truly accessible runs much deeper than that. Accessible by it’s very nature means that anyone, anywhere, with any tool of their choosing can use it. This means the disabled, which is not just the blind, but those with hearing, neuro-diversity, mobility, physical, and learning disabilities; and it means the abled that are compromised by other means.

Economics plays a huge part in accessibility. AOL still has 2 million people using dialup internet. This is an economic issue. ISPs have decided it isn’t beneficial enough to run faster lines to these areas or they are on fixed incomes and can’t afford the rising cost of internet access. Developing nations don’t have access to the funds to buy the latest and greatest technology, so they use products released years ago to get online.

As developers we all cheer when we hear that Microsoft is dropping all support for browsers below Internet Explorer 11 next week, but how does someone in an African country who can’t afford to upgrade from XP going to feel when we don’t support IE9? And what if that great new mobile application you created only works on iOS 9+ and Android 4.4.4? Many lower income folks in the developed and developing worlds have phones that are 2, 3, 4, or 5 years old and don’t support the latest things we can do with the web or mobile.

Building accessible products and sites means taking all this into account. It is using responsive web design to make sure your content is readable on all devices regardless of size. It is using solid HTML to make sure the content is parseable by a variety of technologies on the client side from browser, to apps, to refrigerators and TVs. It is using progressive enhancement to make certain that the product is usable even when the CSS or Javascript fail to load. It requires building products that while that may be single page applications running on Angular, React, or Ember continue to be useful applications when the CDN doesn’t connect or the connection is slow. It means setting a performance budget so that we aren’t trying to load 3 megabytes of data to run a blog. Knowing to reduce images, minify scripts, use CDNs to load things faster, and trying your darndest to limit any single page to something that will load in under 4 seconds and be usable.†

But Why?

Getting back to the disability side of things, recently the DOJ has taken to pushing through that public websites are liable to be accessible to the disabled. There is recent legislation that is forcing airlines to improve their websites. Netflix, Target, H&R Block, and eBay have all been sued by disabled people because their websites weren’t accessible.

You probably have a good idea what a lawsuit brought in federal court would cost your company even before remediation and damages are incurred. Why get sued when you can save money fixing the problems first?

I’m Here to Help

Your competitors haven’t solved this problem yet. Many are in the same boat as you and don’t know where to start.

With over decade of experience in front end development, user experience design, and accessible development I can get you ahead of the curve. Working together we can do a proper assessment of your website in all the major assistive technologies to make certain any deficits are found before you end up in court. With an active assessment done and a remediation plan in place you can resolve many legal actions before they get started.

Once you know where the problems lay, I can work with or train your team on how to resolve those issues bringing your site up to par with WCAG 2.0 AA standards. This is the standard level used by the Canadian, United Kingdom, Australian, and Japanese governments to write their web accessibility legislature. The European Union has used it to craft theirs; and the United States has similar legislation based on WCAG 2.0 AA facing it for a vote.

Contact me to set up a time to discuss your needs so we can set your product or site off as a differentiator in your industry because it is accessible.

† 4 seconds is a magic number that will cause people to think your app is slow. If your customer is using dialup, then a 500kb page will take 1 minute and 13 seconds to download. Sure 3 megabytes is instantaneous on your home cable connection or 4G smartphone, but in the developing world it could be a minute.

Comments closed