Well, hello 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 went out and I have to say,
a bit judgy Dave. I know, I'm old and fat but I have feelings!
So yeah, thank you. Well, normally the thank yous come at the end but I wanted to start
by saying thanks to Dave LeTorey for accepting my proposal to speak here.
I've not spoken at web events for almost 20 years and only recently broke that drought
at CSUN ATC in March this year.
For those who do not know, CSUN is the California State University Northridge and the ATC part
is the Assistive Technology Conference.
For many years it was the biggest accessibility conference.
I believe it still is the largest for face-to-face accessibility conferences, but also there
are now some excellent online ones such as ID24, which happened just two days ago, and
Axe-con.
I mention this because I was petrified in the lead-up to CSUN at the prospect of public
speaking, but in the end it went well and immediately afterwards I was like "ah, yeah,
I could do this again".
It's amazing how that little wave of relief at the end of a presentation can erase all
those stressful moments in the lead up so easily. After CSUN I immediately forgot this
was a nerve-shedding experience and looked for speaking opportunities. So thanks Dave,
you could have said no. 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 wonder what the
heck was I thinking. I also feel like an imposter because I have only ever been to one London
Web Standards meetup.
And my main memory of it was that Jake Archibald
was about to head to Poland for some web conference, I think.
And he had a copy of "Krakow in Your Pocket."
Surely the most unfortunately named book in that series.
I'm sure that there was some discussion
about web standards at that meetup,
but that's what *I* remember.
The reason I have not been to any more of these
is because I live in the beautiful town of Swindon.
So why would I want to leave?
The image shown has a very colorful, upbeat, Swindon banner, which is somewhat in contrast
with what could be best described as a post-apocalyptic view that is Swindon Town Centre.
Despite my very infrequent visits to events like these, or speaking gigs, I have been
involved with accessibility for around 20 years. Some of you might also remember this
old website that I used to run, Accessify.
Emphasis on 'used to'.
The domain still exists, but it's absolute dog shit now.
I really wish I had not sold that domain.
Most of this 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.
I have been working exclusively in the accessibility arena though for 5 years now, and every day
I see the same shit I've been trying to fix for the last 25 years or so.
So what am I going to talk about today?
First of all there's the old low hanging fruit.
This is the part of the presentation where I explain why and where accessibility is
easy.
I'll cover just a dash of the basics to show how simple changes can have a great effect.
The T-shirt that I'm wearing now, which has the phrase "Button up, buttercup" can give you
a hint about that part.
Then just to show you what people in this room probably think is fairly simple stuff,
I will share some examples of absolute markup horror shows.
Finally, I will move on to the more juicy fruit where I will show more complex
UIs that need more thought.
I'll explain the issues that they present, I'll cover what WCAG SCs they fail and I'll
demo a fixed version.
I just slipped in some jargon, which a good percentage of you probably know, but you know
what they say about assumptions.
Samuel L Jackson speaking: "And everyone knows when you make an assumption you're making an ass out of you
and umption."
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 don't need to explain what W3C is.
SC = Success Criterion
In the WCAG guidelines, issues that may affect users are grouped into four main categories
Perceivable, Operable, Understandable, and Rebust, and each of them are numbered.
When auditing a website, accessibility nerds have very dull conversations or arguments
that consist primarily of numbers.
Oh, 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. You know, that kind of thing. We are fun at parties.
ARIA equals 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 is accessibility.
This is the abbreviation
that you will often see for accessibility.
It's an A, then 11,
for the characters that have been removed, then Y.
Is it pronounced alley, ally, A-eleven-Y?
It depends on who you ask.
I go with 'alley', so just in case I say that,
I try to avoid it,
but in case I do, that's what I mean by it.
Finally, there's AT for assistive technology.
Typically this will mean screen readers,
but it could also be a refreshable Braille display.
So let's start with some of the basics.
And we'll kick off with the classic, a button.
Some of you might be thinking,
"Oh know 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 had gone to ButtonConf by mistake!
I am guilty of it too, having written an article covering
this issue and related issues on the TPGi blog.
But it's a useful way to make a point.
So I will cover this very briefly.
If you are repurposing non-semantic divs or span
elements as buttons, you will need to make sure that they
are keyboard-focussable and operable with a tabindex
attribute.
they are exposed to assistive technology as buttons
through the HTML role attribute.
You can style them with CSS to look like buttons,
but to be frank, you'd want to do that with real buttons too.
Scripts are used to ensure that states are updated
and conveyed to assistive technology,
such as is the button pressed, is this thing expanded?
You're creating yourself a lot of work
and it's not particularly robust.
So, you know, 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 interactive elements.
Unless, of course, your website is pretty much
only a collection of buttons, like a soundboard.
If your website were just a collection of buttons,
you could quickly, very quickly improve the accessibility
it by changing from non-semantic divs to buttons, particularly if you have not made these buttons
keyboard operable. And if I were building a soundboard, I'm not going to lie, it would
probably be a fart soundboard. Now here is 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 developments for buttons. Minimal changes in the markup, but
big improvements for accessibility, with barely any overhead. Actually, I lied a bit back
then when I said that this is a pretend website. To create the screenshots of the UI and the
underlying markup, I had to build something, and it was just not within me to create an
inaccessible farting soundboard. So, yeah, that exists. No, I'm not demoing. But there
is a link to the accessible fartboard at the end for people with a similar mental age to
me when it comes to jokes. So you'd think that buttons are a pretty simple thing and
people should get them right. But time and time again, I've been proven 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. It's supposed to be sarcastic, but really
it's painfully on the money. Developers with galaxy brains in many areas often balls up
the 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
the horrors I have seen. So let me share with you some right now.
We have a channel in Teams at TPGI which, hang on, I said the T word, I need a drink.
I need a stronger drink. In one of our Teams channels we share some of the absolute beauties
that we have come across while auditing. This is just a selection of many of the horrors
that we have come across. We'll start with something nice and easy. Is this a 'linkput'?
It's a button implemented as an input with type of button. It's not common approach but
it's still valid HTML. But why not then just wrap that in a link and then remove the link's
semantics by giving it a role of presentation? Or why not just have a button?
Anoher example of link button confusion here or as we shall call it a "lutton". Here we
have a perfectly focusable link that has had a `tabindex` added for no reason
whatsoever. Oh and of course they want it to be a button instead so they've given
it a role of button. It's a logout button but hey let's just completely overwrite
that logout "lutton" with a totally different accessible name of "my account",
thus ensuring that dictation software users can't select that "lutton" and
and AT users will always log themselves out
when they thought they were actually just going to view their account!
And now we have a collection of div elements that really are a list.
So, you know, they could have used proper list markup, like UL, Li, that sort of thing.
Instead, they tried to convince assistive technology users that this is a list
by providing an ARIA label of "list" on the parent container
and an ARIA label of "list item" for each item.
This is a list item, this is a list item.
What the hell is this?
Okay, so you take a div
and then you redefine it as a button.
Then you mysteriously indicate that it is checked
with aria-checked,
despite it not being a checkbox.
Then, just to confuse matters further,
you add aria-expanded=true,
which suggests that it's a disclosure.
It is not.
All of that is wrapped around a link,
which has no `href` because it's not a link,
and it's not a link because inside of that link
is a heading, an H5 heading!
Seriously, what are people smoking
before writing this stuff?
The most hilarious part of this is that visually
and functionally, despite all of that crap markup,
this component 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 this. The video clip shows a showroom dummy head on the end of
a robotic arm which is then mashed and rolled across a keyboard. Well, it's as good a theory
as any. You can't just fix any crappy old markup with ARIA. 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 and 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 actually can fix some pretty atrocious markup
with ARIA if you know what you're 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 in the audience right now
and can personally administer a kicking
if you try this sort of nonsense.
To reiterate, don't make complicated stuff
when you can have all of 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!"
Time for a mini quiz.
It's very mini, there's just one question.
I'll make it easier though,
by providing multiple choice answers.
And the question is, what is this thing?
It is opened using a button,
then it shows a menu-like set of options,
but it also has a close button and a curtain underneath.
So, audience participation time.
Put your hands up if you think it is a menu.
Put your hands up if you think that it is a dialog.
Finally, put your hands up if you think it's a disclosure.
Okay, well, you're all wrong.
It's actually a diaMenuClosure, which of course is not a thing at all,
but you try telling some developers that.
The point is that there are patterns for all of those three things I mentioned.
Each has expected roles that are exposed to AT,
and those roles imply certain expected behaviors for AT users.
This diaMenuClosure 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.
What is it a poorly implemented dialog?
Or is it a badly implemented menu?
The examples I show in the next section are going to be mockups or recreations of real
interfaces that I've audited.
I can't show you the real interfaces because of client confidentiality reasons, but these
are functionally equivalent to the real thing.
Oh, and clearly I am not a designer as you are about to see.
In this panel, 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 three quarter width, or at least it was in the original
version that I audited.
The panel for the details is also ever present taking up the remaining quarter width.
Is there a pattern for this?
There are patterns that exist for various parts of this, the table as a whole, button
elements inside the table, but there's nothing that ties this particular
interaction together in any standard way. The challenges this one presented were
around how do you make a table row clickable, and what is the
accessible name that will be exposed to AT users. There's potentially a whole lot
of wording if that whole row is interactive. Managing focus should
focus move when a row is selected or not. What should be announced for screen
reader uses, a summary of the displayed data, all of the data displayed, or just confirmation
that the panel has updated.
In the original audited version, the problems that we noted were there was no keyboard operability.
It relied solely on mouse clicks, so it failed 2.1.1 keyboard. No content update was provided
for assistive technology users and failed 4.1.3 status messages. There are also numerous
issues related to color that are not shown in this recreation.
To address the keyboard issue, one cell of the table needed to have a focusable button,
which I have lazily indicated with the eye emoji button here. Not a designer, see?
The ability to select a row with the mouse can still happen, but you cannot wrap a
around a element though. You have to use a bit of JavaScript to solve that problem.
To indicate the row is focused, although technically it's a child element of the row, we can use
:focus-within in the CSS.
When a row or button is activated, a brief message is displayed to screen reader users,
indicating that content in the Details panel has been updated.
SCREEN READER SPEECH: Entering table caption of some kind table.
SCREEN READER SPEECH: Row 1 view details inside panel.
SCREEN READER SPEECH: Toggle button.
SCREEN READER SPEECH: Row 2 view details inside panel.
SCREEN READER SPEECH: Toggle button.
SCREEN READER SPEECH: Results panel updated.
SCREEN READER SPEECH: Row 2 table cell data.
In the example just shown, each button is focusable with the Tab key and is exposed as a toggle button.
But I want you to ignore the fact that it's a toggle button because there isn't really a toggle on/off effect here.
And I didn't notice that I'd recorded a slightly older version of this.
In the final version, it's just announced as a button, which is also nicer for screen reader users because it's less verbose.
There are still some issues to address here though.
Larger tables mean that multiple tab stops are needed 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.
For non-sighted and low vision users, getting to the more detailed content revealed on the right is a little tedious.
Also, there were no landmarks provided for AT users, which would have provided a quick way to jump between these regions.
We can make a number of improvements here then.
We can reduce the tab stops for keyboard users in that table
and allow the user to navigate using the up and down arrow keys.
This means once the desired row is selected and activated,
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.
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.
Next, let's take a look and listen
to the 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
SCREEN READER OUTPUT: row 7 table cell data.
And finally, we can see focus being moved between the two
sections using the left and right arrow keys.
There are still some fine details to consider on this.
What if the left-right navigation interferes with AT?
Is this help actually a hindrance for some?
It might be good to provide this keyboard support
as an optional user preference.
We can add aria-selected on the row
to clearly indicate which is the selected row.
But at the heart of this UI was the question of how to manage
or not manage focus. Do you, or should you, move focus to that right panel when something
is selected? Treating that panel as a dialog would allow for that, but this is not how
the page was working.
Onto the second example, 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 just off the
charts. Complicated constructions using various ARIA attributes to allow someone to choose
an item from a list, are ten-a-penny. In most cases this comes around because elements are
difficult to style, unlike the humble , which is usually what prompts developers to take
this route. It turns out that many of the styling hurdles can be overcome and Adrian Roselli has
covered this in detail in a post under engineered select menus. The element is great for
single selections, but if you want multiple selections it gets a little more tricky and
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.
Custom s frequently fail 2.1.1 keyboard
and 4.1.2 name role value.
A multi-select interface is essentially the same thing
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.
It's useful to group the checkboxes in a list, as this will provide AT users with an indication
of how many checkboxes are present. If it were a collection of radio buttons, that would be exposed
by default. If you have a really long list of checkboxes, you might want to consider using
using a roving `tabindex` on these, so that you can easily tab to the next focusable elements
on the page after the checkboxes, using the arrow, up and down keys to navigate, and then
space to check and uncheck.
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 is presented as a pop-up menu?
Could you use the defined pattern for a menu?
You could, and if you do, you should make sure you get it right.
But as my earlier examples have shown, people can make a mess of such things.
I look at this and I see a simple disclosure, which does still 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 multiple selection, select, it's arguably easier for
users to interact with. Here's how it looks and how it sounds for a screen reader user.
*SCREEN READER OUTPUT*
Pineapple on a pizza, controversial.
But more than anchovies, really?
Really?
Now let's take a look at a theater seat chooser.
I have not had to audit one of these,
but I sure as heck have had to use one plenty of times.
In this section, I could show a real example,
as it is not one of a client that I've audited.
But before I show that, these typically fail
on the following.
2.1.1 keyboard, where there is mouse only seat selection.
1.4.1 use of color, where the legend for seat types
is only differentiated by color.
4.1.2, name, role, value,
where the seats have no name, hang on a minute.
U2: ♪ Where the streets have no name ♪
Sorry about that, I couldn't help myself.
Let's take a look and listen to Cineworld's 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,
SCREEN READER OUTPUT: Seat unavailable, inaccessible, accessed companion.
SCREEN READER OUTPUT: You are--
So that's what the legend sounds like,
but ultimately, this is of no use to non-cited users,
as there is nothing that ties the legend to the seat types.
As you will find out shortly, it's just a list of words.
When booking a seat in a theater, cinema, or flight,
typically you're presented with this top-down view
of the seating arrangement.
For a sighted user, it's easy to grasp the layout
and pick 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,
which are implemented as buttons.
SCREEN READER OUTPUT: - Screen, button.
SCREEN READER OUTPUT: You are currently on a button, CA-14, button, CA-13,
SCREEN READER OUTPUT: button, CA-12.
(upbeat music)
- Note that in this 131 seat cinema,
The accessible seats are at the back of the cinema, but requires the keyboard users to
press tab 120 times to get to those seats.
I'm not going to force you to listen to all 131 seats, you got the idea from that clip.
Then again, the user won't actually know when they have reached the accessible seats, because
the accessible seats are not exposed as such.
SCREEN READER OUTPUT: "Button, button, CH2.
SCREEN READER OUTPUT: You've button, CH1."
The irony is strong.
Selected seats, which are shown in red in the UI, are not exposed as such to AT users.
Once selected, a seat is set as disabled.
Also, seats are automatically suggested and assigned when the seat picker is first loaded.
There's no way for a screen reader user to tell that those are the seats that have already
been selected on their behalf, or whether they are not selectable for some other reason.
To give credit where it's due, they do at least provide a status update for screen
reader users for what seats have been selected after any seat is chosen.
That little bit of praise aside, they could do so much better.
Achieving WCAG AA conformance is good, but it's really just a starting 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 that a read.
It's a great article, Accessibility Theatre.
I won't go into the level of detail that he does in the article now, we don't have
time.
I'll just say that he's covered all 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, and
no reliance on color alone to convey seat status.
Here's a quick demo.
SCREEN READER OUTPUT: A. Selected toggle button.
A2. Selected toggle button.
SCREEN READER OUTPUT: A1. Selected toggle button.
SCREEN READER OUTPUT: B1. Top C1.
SCREEN READER OUTPUT: D1. Top E1. Top F1.
SCREEN READER OUTPUT: Toggle button. G1.
SCREEN READER OUTPUT: D. H1. H1. H2.
SCREEN READER OUTPUT: Toggle button.
SCREEN READER OUTPUT: Next to sound booth.
SCREEN READER OUTPUT: are currently on a toggle button inside a group to select H1 toggle button. 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.
Doug has even made it possible to navigate entire blocks of seats so you can quickly choose balcony,
mezzanine etc.
So, to recap, using native HTML elements is great, but may only get you so far depending
on the complexity of the UI.
You should reach for ARIA and approved patterns when native elements are not up to the job.
And for more complex interfaces that have no precedent, use all of 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.