Accessibility Is Easy …
Except for When It Isn’t

• Under Engineered Select Menus - Adrian Roselli
• CodePen - Table row selection updates right panel
• Accessibility Theater
• Fartboard - An Accessible Farting Soundboard
• SC 1.4.1 Use of Color
• SC 1.4.11 Non-text Contrast (Level AA)
• SC 2.1.1 Keyboard
• SC 4.1.2 Name, Role, Value
• SC 4.1.3 Status Messages (Level AA)

(upbeat music) So the presentation is called Accessibility is Easy, except when it isn't.

So hi, State of the Browser folks, or as my phone mail app had it, "State of the Bro".

That's what it showed when my speaker announcement came out.

And I have to say Dave, a bit judgey.

I know, I'm old and fat, but I have feelings.

Yeah, thank you.

Strange, normally we do the thank yous at the end, but I wanted to start by saying thanks to Dave Letorey for accepting my proposal to speak here, because I'm not exactly a known quantity on the speaking circuit of late.

I've not spoken at the web event for almost 20 years, and only recently spoke-- broke that drought at CSUN ATC this year in March.

For those that do not know, CSUN is the California State University Northridge, and the ATC is the Assistive Technology Conference.

For many years, it was the biggest accessibility conference and I believe it still is the largest for face-to-face conferences.

But there are also now some excellent online events such as ID24, which happened two days ago, and Axe-Con.

I mention this because I was petrified at the lead up to CSUN.

I'm shaking right now at the prospect of public speaking.

But in the end, it went well.

And afterwards, I was like, yeah, I could do this again.

It's amazing how this little wave of relief at the end of the presentation can erase all of those stressful moments and the lead up to it so easily.

So I'm looking forward to that same feeling in about 20, 25 minutes-- no, 30 minutes, actually.

I have got my timing's all right, I think.

So after CSUN, I immediately forgot that this was a nerve-shredding experience and looked for speaking opportunities.

So yeah, thanks, Dave.

You could have said no.

So a tiny bit about me.

I do have a bit of imposter syndrome here, because when I look at the list of speakers for this event over the years, it does make me think, what the heck was I thinking?

Another reason that I feel like an imposter is because I've only been to one London Web Standards meet up.

And my main memory of it was that Jake Archibald was about to head off to Poland for some web conference, I think, and had a copy of Krakow in Your Pocket, surely the most unfortunately named book in that series.

(audience laughing) And I'm sure there was some discussion about web standards, but that's what I remember from the event.

And the reason I have not been to many more of these is because I live in the beautiful town of Swindon.

So why would I want to leave?

(audience laughing) The image shown has a very colorful upbeat Swindon banner, which is somewhat in contrast with what could best be described as a post-apocalyptic view that Swindon Town Center.

Now, despite my very infrequent visits to events like these, or speaking gigs generally, I have been involved with accessibility for over 20 years.

Some of you might also remember this old website that I used to run called Accessify.

Emphasis is on used to.

The domain still exists, but it's absolute dog shit now.

I really wish I'd kept the domain.

Now, most of that 20-year stint was as a developer who always wanted to influence and shape accessibility.

And often, that was a frustrating experience, as I did not have any real power or remit.

But I've been working exclusively in the accessibility arena now for around five years.

And every day, I see the same shit I've been trying to fix for the last 20 years or so.

So what am I going to talk about today?

There's the low-hanging fruit.

This is the part of the presentation where I explain the where and the why of accessibility being easy.

I'll cover just a dash of the basics to show you how simple changes can have a great effect.

The t-shirt I am wearing now, courtesy of Steve Faulkner, has the phrase "Button up, buttercup!" which can give you a hint about that part.

Then just to show you what some people in this room probably think is fairly simple stuff, I will share some examples of absolute markup horror shows.

Finally, I'll move on to the more juicy fruit, where I'll show you some complex UIs that need a little bit more thought.

I'll explain the issues they present.

It won't be this one.

(audience laughing) I'll cover what WCAG SCs they fail, and I'll demo fixed versions.

Now, I just slipped in some jargon, which a good percentage of you probably know, but you know what they say about assumptions.

• And everyone knows.

• Oh, no, audio!

We need the audio.

• And answer.

• Sorry, rushed tech check.

We haven't got audio running through here.

Can I have a little bit of help here, 'cause I'm gonna need the audio.

(keyboard clacking) Oh shit.

That's not a good move either.

(audience laughing) I conveniently put water there 'cause I thought I'm gonna get a dry mouth.

And now I've tipped it all over the lectern.

Smooth.

Thank you.

Yeah, how do I get audio through here?

• There's, have you got audio out?

• I need a jack, don't I?

Sorry, with all the rush to get this working.

(audience chattering) Yeah, but it's only coming through my speakers, it's not coming through them.

(audience chattering) - Can I?

• Mm-hmm.

(audience chattering) [LAUGHTER] Wow.

Sound.

Decimator.

Can we just-- [TAPPING] H21.

I'll put that there.

Oh, yes.

• Yes.

Don't know if that'll do.

• Right, we'll just see if this is gonna work.

Right.

Let's see.

• Samuel L Jackson speaking: "When you make an assumption, you make an ass out of U and umption".

• Right.

Well, that ruined that one, didn't it?

Okay, yeah, yes, that's right, Samuel.

So let's get some of the jargon out of the way for those who may not be familiar.

WCAG is Web Content Accessibility Guidelines.

These are the W3C's guidelines for how we should create web content to make it accessible.

I think we're on safe ground here and we don't need to explain what W3C is.

SC is Success Criterion.

In the WCAG guidelines, issues that may affect users are grouped into four main categories, Perceivable, Operable, Understandable, Robust, and they are numbered.

When auditing a website, accessibility nerds have very dull conversations or arguments that consist primarily of numbers.

"Ah, that's definitely a 1.1.1 failure, but it's also a 2.5.3, plus there's a 1.4.11 issue to flag."

Like Amy with her existential crisis, we are also fun at parties.

ARIA is Accessible Rich Internet Applications.

This is a set of documentation that defines ways to make web content and web applications more accessible to people with disabilities, especially with dynamic content.

"A11y," this is the abbreviation that you will often see for accessibility.

It's an A, then 11 for the number of characters that have been removed, then a Y.

Is it pronounced "Ally," "Alley," A-11-Y?

Depends on who you ask.

I go with "Alley," so in case I say that (I try to avoid saying it)

but if I do, that's what I mean by it.

And finally, there's AT for Assistive Technology.

Typically, we're referring to screen readers, but it can include more things like, for example, refreshable Braille displays.

Right, let's start with the basics.

The old classic, a button.

Some of you might be thinking, oh no, not this old chestnut again.

And I completely agree.

At a recent conference I attended, there were three presentations back to back that all gave the example of using a button, and I thought I'd gone to ButtonConf by mistake.

Actually, there is a ButtonConf that exists.

I was trying to Google it, trying to find a funny image or whatever, and turns out there is one.

It's got nothing to do with buttons.

Go figure.

So I'm guilty of it too, having written an article covering this very issue and related issues on the TPGI blog.

But it is a useful way to make a point.

So I will cover this very briefly.

If you are repurposing non-semantic div or span elements as buttons, you will need to make sure that they are keyboard focusable and operable with tabindex, that they are exposed to assistive technology as buttons using the HTML role attribute.

You'll need to style them to CSS to look like buttons.

To be frank, you'd probably want to style native buttons with CSS too.

And scripts are needed to ensure that states are updated and correctly conveyed to assistive technology, such as, is the button pressed?

Is this thing expanded?

And you're creating yourself a lot of work, and it's not particularly robust.

So you could just use a button.

Now, using real buttons is all well and good, but it can only get you so far.

For most sites, this will represent just a small percentage of the UI of your interactive elements.

Of course, unless, of course, your website is pretty much only a collection of buttons, like a soundboard.

Now, if your website were just a collection of buttons, you can very quickly improve the accessibility of it by changing from non-semantic divs to buttons, particularly if you've not made those buttons keyboard operable.

If I were building a soundboard, I'm not going to lie, it would probably be a fart soundboard.

[LAUGHTER] Now, here's the markup with non-semantic divs.

Not accessible at all.

And here's the fixed version for this pretend soundboard, where the only change is literally to swap the div elements for buttons.

Minimal changes in the markup, but big improvements for accessibility with barely any overhead.

Actually, I lied when I said that was a pretend website.

Because to create the screenshots of the UI and the underlying markup, I obviously had to build something.

And it's just not within me to create an inaccessible farting soundboard.

So yeah, that exists.

I'm not demoing it, but there is a link to the fartboard at the end for people with a similar mental age to me when it comes to jokes.

Now, you would think the buttons are a pretty simple thing and people should get them right.

But time and time again, I've been proved wrong.

Recently, I saw this tweet which read, "Senior developer quiz using only HTML and no JavaScript.

make a link that will navigate to another page.

(audience laughing) It's supposed to be sarcastic, but really it's painfully on the money.

Developers with galaxy brains in many areas often balls up most basic fundamentals of the web, and you cannot get much more fundamental than links and buttons.

Some of you may be thinking, this is just hyperbole.

People don't screw things up that badly, do they?

I fear that this audience may not have seen some of the horrors that I have seen, so let me share some with you now.

We have a channel in Teams at TPGI, which-- well, basically, we share examples of this sort of stuff.

It's-- what's it called?

Didn't hit the markup, is the channel name.

So we get some real beauties, which we share.

And this is just a small selection of some of them that we've come across.

First one, is this a link put?

It's a button implemented as an input with type equals button, which is not a common approach, but it is still valid HTML.

But then, why not wrap that in a link, and then remove the link semantics by giving it a roll of presentation?

Or just use a button!

Another classic example of link button confusion, or as we shall call it, the LUTTON.

Here we have a perfectly focusable link that has a tabindex added for no reason whatsoever.

Oh, and of course, they want it to be a buttons instead, so we've given it a roll of button.

the logout button, but hey, let's just completely overwrite that logout button with a totally different accessible name of my account, thus ensuring that dictation software users can't select that button, and non-cited screen reader users will always log themselves out when they thought they were just going to view their account.

OK.

Now we have a collection of div elements that really are a list.

So you know they could have used the proper markup like UL, LI, that sort of thing.

But instead, they tried to convince assistive technology users that it's a list by providing an aria-label of list on the parent container and an aria-label of list item for each and every item.

This is a list item.

This is a list item.

It's not fooling anyone.

[THUD] Oh, fuck.

[LAUGHTER] Scared myself there.

What the hell is this?

So you take a <div>, then you redefine it as a button.

Then you mysteriously indicate that it is checked with aria-checked.

despite it not being a checkbox.

And then just to confuse things further, you add are_it_expanded equals true, which would suggest that it's a disclosure.

It's not.

And all of that is wrapped around a link, which has no href because it's not a link.

It's not a link because inside of that is a heading, an H5 heading.

H5, whoever gets there.

Seriously, what are people smoking before writing this stuff?

The most hilarious part of this is that visually and functionally, despite all that crap markup, This component looked and behaved like a radio button.

The animated gif shows a cat gesticulating in time with the words, what the fuck are you doing?

I have a theory about how mark up like this is created.

The video clip shows a mannequin head on the end of a robotic arm, which is then mashed and rolled across the keyboard.

It's a good theory as any.

Oh, what happened?

Ah.

Really?

(audience laughing) I'm scared.

You can't just fix any crappy old markup with ARIA.

(audience laughing) The image shows a red car with the wheels sideways on the front of the vehicle and a bumper that runs down the side and it says, "We can fix it with ARIA."

Remember, the first rule of ARIA is, if you can use a native HTML element or attribute with the semantics behavior you require already built in, instead of repurposing an element and adding an ARIA role, state, or property to make it accessible, then do so.

You can actually fix some pretty atrocious markup with ARIA if you know what you were doing, but it's not robust.

It's not right.

And if you do, Steve Faulkner, author of the ARIA rules, will come and kick you in the nether regions.

In fact, he's here in the audience right now, so he could personally administer a kick-in if you try this sort of nonsense.

To reiterate, don't make complicated stuff when you can have all that complicated stuff provided for free.

The image shows a hideous vehicle that appears to have been made out of a collection of entirely mismatched panels.

And the caption reads, use a button, but I can make my own button.

Right, time for mini quiz.

And there's just one question.

I'm going to make it easier, though, by providing multiple choice answers.

The question is, what is this thing?

It's opened using a button, then shows a menu-like set of options.

But it also has a close button and a curtain underneath.

Audience participation time.

Put your hands up if you think it is a menu.

Ooh, no one.

A dialog.

Is it a disclosure?

I'm quite happy that not many people put hands up.

Because actually, anyone who had hands up, you're wrong.

It's a die menu closure.

[LAUGHTER] which of course is not a thing, but you try telling some developers that.

The point is there are patterns for things I mentioned, for all of the three things.

This dire menu closure has features of each pattern, and frankly, the developers who do this sort of thing need to pick one and do it right.

When auditing such things, it's tricky to know sometimes what to report any issues against.

Is it a poorly implemented dialog, or is it a badly implemented menu?

Who knows what they were aiming for.

Okay, so the examples I'm gonna show in the next section are going to be mock-ups or recreations of real interfaces that I've audited.

I can't show the real interfaces because of client confidentiality reasons, but these are functionally equivalent to the real thing.

Oh, and clearly, as you will see in a moment, I'm not a designer.

OK.

So in this example, the user makes a selection from a table of data, and a more detailed view of that data is shown in the right panel.

The table is ever-present, taking up 3/4 widths, or at least it was in the original version.

And the panel for the details is also ever-present, taking up the remaining quarter width.

Is there a pattern for this?

Well, there are patterns that exist for various parts of this-- the table as a whole, the button elements.

But there's nothing that really ties this particular interaction together in any standard way.

And the challenges this one presented were, how do you make a table row clickable?

What's the accessible name that's exposed to AT users?

Because there's potentially a lot of wording when that whole row is interactive.

Now, obviously, this is just dummy data.

But in the real thing, there was a lot of information, which had been a really big accessible name if the whole row was exposed.

What-- oh, managing focus.

Should focus move when the row is selected or not, from left to right?

And what should be announced for screen reader users?

Should it be a summary of the displayed data, all of the data that's displayed?

And there was quite a lot of data in some of these, or just a confirmation that the panel is updated.

Now, in the original version, the problems that we noted were, there was no keyboard operability, first of all, because they were relying solely on a mouse flick on the row.

So it failed 2.1.1 Keyboard

There was no content update provided for assistive technology users when the right section was updated.

So it failed 4.1.3 Status Messages.

There were also numerous issues related to color that are not shown in my dull recreation here.

So to address the keyboard issue, one cell of the table needed-- at least one of the table cells needed a focusable button, which I have lazily indicated here with the eye emoji.

As I said, I'm not a designer.

The ability to select a row with a mouse can still happen, but you can't wrap a button around a TR.

So you have to get a bit more creative with JavaScript to solve that problem, because they do want this whole row clickable.

You can't just say, no, you're going to have that little button there.

To indicate that the row is focused, although technically it's just a child element of the row that's focused, we can use focus within in the CSS.

And when a row or button is activated, a brief message is relayed to the screen reader users indicating that content in the details panel has been updated.

SCREEN READER OUTPUT: Entering table caption of some kind table.

SCREEN READER OUTPUT: Row one view details inside panel, toggle button.

SCREEN READER OUTPUT: Row two view details inside panel, toggle button.

SCREEN READER OUTPUT: Results panel updated.

SCREEN READER OUTPUT: Row two table cell data.

An example just showing each button is focusable with the Tab key and is exposed as a toggle button.

But I want you to ignore that it's a toggle button, because there isn't really a toggle on/off effect here.

And I didn't notice that until I recorded this.

And I played it back a little while ago and realized I'd got a slightly older version of this interface.

In the final version, it's just announced as a button, which is also nicer for screen reader users because it's just generally less verbose.

There's still some issues to address here, though.

Larger tables means that multiple tab stops are required for keyboard users to get through the table and into the details panel.

In the audited version of this, it was something like a 40-row table.

That's a lot of tab stops.

For non-sighted and low-vision users, getting to the more detailed content revealed on the right is a little bit tedious.

And there were no landmarks provided for AT users, which would have provided a quick way to jump between these regions.

So we can make a number of improvements here.

Firstly, we can reduce tab stops for keyboard users in that table and allow users to navigate using the up and down arrow keys.

This means that once the desired row is selected and activated, the next tab stop would be inside.

What's going on?

Does everyone call with purple?

I'm going to just move back a little bit.

Yeah, the next tab stop would be inside that right panel.

We can add landmarks to the two regions, which provides a quick method for screen reader users to jump between the sections.

And we could also provide further keyboard support for non-screen reader users who cannot make use of those landmarks.

Here we can see the roving tabindex in action.

So you can see what the key presses are here with Shift and Tab and arrow keys.

So the first element becomes focusable, and then you can navigate up and down using the arrow keys.

And then quickly jump to the right-hand section with Tab.

Now let's take a look and listen to landmarks being exposed to assistive technology.

SCREEN READER OUTPUT: Landmarks menu.

SCREEN READER OUTPUT: Select a region.

SCREEN READER OUTPUT: Details panel region.

SCREEN READER OUTPUT: You are currently on a region in heading level 2.

SCREEN READER OUTPUT: Details will appear here.

SCREEN READER OUTPUT: Additional details related to the button titled row 7 table cell data.

With hindsight I would have actually named that first landmark slightly different because it's selector, T-O-R, but it sounds like it's giving a command to 'select a region'.

So I'd probably rename that now.

It's interesting when you listen back to it, and it could be misleading.

Finally, here we can see focus being moved between the two sections using left and right arrow keys.

So added keyboard support to jump quickly between those two sections.

There are still some fine details to consider on this.

What if adding left and right navigation with the arrow keys interferes with AT?

Could this help actually be a hindrance for some?

It might be a good idea to have this sort of keyboard support provided as an optional user preference.

We can add aria-selected on the row to make sure that the AT users know which row is currently selected.

At the heart of this UI, though, was the question of how to manage or not manage focus.

Should you move the focus to that right panel when something is selected instead?

If this was treated as a dialog, if they had implemented it-- because you can have a dialog that appears on the right that doesn't have to take over the page-- then it would have been a no-brainer.

have used focus to take you to that section and then have some way to jump back.

But they didn't have any of that.

So it couldn't be implemented as a dialog, so it needed a bit more creativity.

Right, next example I'm going to show you is multi-select menu.

In the same way that we often find ourselves saying, why not just use a button, the number of times people reinvent the select element is-- it's off the charts.

Complicated constructions using various iron attributes to allow someone to choose an item from a list are 10-a-penny.

And in most cases, this comes down to select elements being basically difficult to style, unlike the humble button, which is usually what prompts developers to take this route.

It turns out that many of the styling hurdles can be overcome, and Adrian Rosselli has covered this in detail in a post entitled Under Engineered Select Menus.

The select element is great for single selections, but if you want multiple selections, it gets a little bit more tricky, and many people struggle with the keyboard operability of this.

It's one of the rare occasions where I would recommend complicating the markup just a tiny bit.

So if you think about it, a multi-select interface is essentially the same as a list of checkboxes.

By their very nature, you can select as many as you wish and in any order.

And you don't need to worry about having to remember some quirky keyboard modifier to make multiple selections.

There we go.

Is there a specific spot that's doing this?

I don't know what's going on here.

Probably dumping water over the laptop's not a good move anyway, is it?

Right, there we go.

We're back.

OK, so there's some markup there for the list of checkboxes.

It's useful to group the checkboxes in a list, because this will then provide AT users with an indication of how many checkboxes are present.

Should I just-- [LAUGHTER] If it were a collection of radio buttons, that number would be exposed by default.

Now, if you have a really long list of checkboxes, you might also want to consider using a roving tabindex on these, like with the table rows, so you can easily tab to the next focusable element on the page after the checkboxes.

So using the up and down arrow keys to navigate and space to check or uncheck.

Now, aside from this being a list of pizza toppings, it doesn't look much like a menu in the web sense of the word.

But what if this was presented as a pop-up menu?

So it's the same markup, just styled differently.

Should you use the defined pattern for a menu for this?

You could.

And if you do, you should make sure you get it right.

But as my earlier examples have shown, people make a mess of such things.

But I look at this, and I see a simple disclosure, which does require some ARIA, but a minimal amount, which opens a panel containing a list of checkboxes.

While it's not as simple to build as a simple multiple selection select-- it helps if I can put the brackets on select there-- it's arguably easier for users to interact with.

So here's how it looks and sounds for a screen reader user.

SCREEN READER OUTPUT: Choose pizza toppings.

SCREEN READER OUTPUT: Collapse button main.

SCREEN READER OUTPUT: You are currently-- choose pizza toppings.

SCREEN READER OUTPUT: Expanded button.

SCREEN READER OUTPUT: Cheese.

SCREEN READER OUTPUT: Chuntick tick box, chip tomato.

SCREEN READER OUTPUT: Chuntick tick box, pineapple, anchovies, spinach.

SCREEN READER OUTPUT: Chuntick tomato, cheese.

SCREEN READER OUTPUT: Chuntick tick tick, cheese.

SCREEN READER OUTPUT: Tick tomato, chuntick tick tomato.

• Am I gonna do it?

SCREEN READER OUTPUT: Tick box, pineapple.

SCREEN READER OUTPUT: Chuntick tick box.

• Will I?

SCREEN READER OUTPUT: You are currently on a tick box.

SCREEN READER OUTPUT: Ticked pineapple, tick box.

Pineapple on a pizza, controversial.

But more than anchovies, really?

Okay.

In this third example, we'll take a look at a theater seat chooser.

Now I've not had to audit one of these, but I sure as heck have had to use one plenty of times.

In this section, I'm gonna show a real example.

This is from CineWorld, as it's not one of a client that I've audited.

Before I show that, these typically fail on the following.

(audience laughing) No!

Ah!

I've spoiled the joke.

(audience laughing) Pretend you didn't see that as well.

(laughing) Ah.

Hang on.

[INAUDIBLE] This went so smoothly in rehearsal.

[LAUGHTER] [BEEP] It doesn't help when the speaker notes scroll off screen.

I think, ah, that's the end of that section.

No.

OK, so before I show that, these typically fail on the following.

2.1.1 Keyboard, where there is mouse-only seat selection.

I think you know where I'm going with this.

1.4.1 Use of Color, where the legend for seat types is only differentiated by color.

4.1.2 (joke spoiled) Name, Role, Value ... where the seats have no name.

[LAUGHTER] [MUSIC PLAYING] [LAUGHTER] [APPLAUSE] I'm really sorry about that.

But still, wouldn't be the first time that you've got unsolicited U2 foisted upon you, right?

[LAUGHTER] OK, let's take a look and listen to CineWorld Seat Picker as I attempt to secure two seats for Barbie.

SCREEN READER OUTPUT: You're one step away from your booking confirmation.

SCREEN READER OUTPUT: It's time to pick your seat.

SCREEN READER OUTPUT: Available, selected, booked, unavailable, seat unavailable, inaccessible, access companion.

Can we up the volume a little bit?

This one's a bit quieter.

So that's what the legend sounds like, but ultimately this isn't actually of no use to non-sighted users because there's actually nothing in this interface that ties this legend to the seat types.

When you actually go to pick the type of seat, There's nothing that connects it.

So it's just a list of words really when not wrong, but they're just useless to a screen reader user We're booking a seat in the theater cinema or flights.

Typically you're presented with this top-down view of the seating arrangement For sighted user it's easy to grasp the layout and pick the seats For a keyboard only user.

It's not always so straightforward Here's the experience for a screen reader user having to tab through every single seat implemented as buttons screen

Button, you are currently on a button.

SCREEN READER OUTPUT: C a 14 button c a 13 button c a 12.

Yeah. Okay, we won't go for all of these. So in this 131 seat cinema, the accessible seats are at the back requiring people to tab through 120 times to get to those seats.

Um, but you know, the funny thing is that when they actually get to those seats and when they've reached the accessible seats, they won't know because they're not exposed as such.

SCREEN READER OUTPUT: Ton ton. C H two, you are ton c h one

Irony. Selected seats, which are shown in red in the UI are not exposed as such to at users.

And once a selected seat is, is once a seat is selected, it says disabled.

The thing is, when you launch this thing, it automatically suggests and picks a seat for you.

So a screen reader user going through this doesn't actually know that the seats have been assigned. They dunno, those are the seats that they've, they've had assigned for them.

SCREEN READER OUTPUT: Dim button, you are currently on a button. This item is dimed, but seat D eight.

So, you know, there's, there's no way of saying why that is not, uh, available.

That button is, is it, is it because the seat's being selected or is it for some other reason that it's, uh, unavailable?

To give credit where it's due though, they do at least provide a status update for screen reader users for what seats have been selected after any seat is chosen.

SCREEN READER OUTPUT: Seat J5, seats J5, J7 are currently selected.

So, that little bit of praise aside, they could do so much better.

Come on, there we go.

Achieving WCAG AA conformance is good, but it's still really just a starting point.

point, this interface is a classic example of where you can make it so much more useful for everyone.

In a recent post on TPGi's blog, my colleague Doug Abrams has covered this in detail.

And I encourage you to give this article a read.

It's really good.

It's called Accessibility Theater.

I won't go into the level of detail that he does in the article now, but we don't have time for that.

I'll just say that he's considered all of the angles and has come up with a user interface that considers everyone's needs.

There's a much better keyboard-only experience.

There's clear messaging for non-sighted users about the layout, obstacles, access points, no reliance on color alone to convey seat status.

Here's a quick demo.

SCREEN READER OUTPUT: Selected toggle button.

SCREEN READER OUTPUT: A2, selected toggle button.

SCREEN READER OUTPUT: A1, selected toggle button.

SCREEN READER OUTPUT: B1, top C1.

SCREEN READER OUTPUT: D1, top E1.

SCREEN READER OUTPUT: Top F1, toggle button.

SCREEN READER OUTPUT: G1, D1, H1, H1, H2, toggle button.

SCREEN READER OUTPUT: Next to sound booth.

SCREEN READER OUTPUT: You are currently on a toggle button.

SCREEN READER OUTPUT: Inside a group, to select H1, toggle button.

SCREEN READER OUTPUT: Aisle seat next to left entrance.

Note how the seating can be easily navigated in all directions using the arrow keys, and how seats next to aisles or the sound booth are clearly identified.

Come on.

Come back.

There we go.

Doug's even made it possible to navigate entire blocks of seats so that you can quickly choose from balcony, mezzanine, et cetera.

SCREEN READER OUTPUT: Orchestra left, group with 12 items.

SCREEN READER OUTPUT: Orchestra center, group with 24 items.

SCREEN READER OUTPUT: Orchestra right, group with 12 items.

SCREEN READER OUTPUT: Mezzanine left, group with mezzanine center, mezzanine right, balcony left, balcony center, balcony right, group with 12 items.

So to recap, using native HTML elements is great, but they can only get you so far depending on the complexity of the UI.

And you should reach for ARIA and approved patterns when native HTML elements are not up to the job.

For more complex interfaces that have no precedent, use those smaller and medium building blocks as much as you can, and then test, test, and test again with as much AT and as many users as you can to see if you've hit the sweet spot.

Thank you, for real this time.

[APPLAUSE] [ Applause ]