Good morning everyone. My name is Ian Lloyd and according to Pixel Pioneers I look like
this. This picture was one that I hastily ran outside to take to send to Oliver and I kind
of wish I hadn't rushed it because the Adidas stripes on my arms reflecting in my glasses
make me look like I either have laser beam eyes or very freaky eyelashes. Still, it
could be worse. On Twitter I look like this. I do like a good gurn and this is one of my
finest achievements. Funnilly, though, someone who I met at a conference last year only knew
what I looked like from my Twitter profile pic and was having trouble tracking me down.
She genuinely thought she was looking for the human equivalent of Jabba the Hutt. On
GitHub I'm like this. Beardy, cross-eyed and based on the lights behind me having some
kind of eureka moment. And on Mastodon I'm like this. Whatever that cuddly toy thing
is working a set of DJ decks. Actually it's not a bad metaphor as I can be rather sloth-like
and I do like to think that I'm a DJ. Clearly I'm not one for consistent branding.
Before we get started, just a quick note to say that if you want to download these slides
they are available at these addresses. A11y-tools.com/PP24 or you can point your camera at this
QR code which I will show again at the end of the presentation. When I was putting this
presentation together I noticed at that time that I was after Amy Hupe in the running order.
And at that point in the presentation I was about to say that was a great presentation
there from Amy as always and that when I realised I was up after her my original thoughts went
something like this. Because she's a hard act to follow and maybe that's why Oliver
moved her slot to the end of the day but unfortunately I didn't spot this until just yesterday.
And well, I just didn't want to drop these clips because they're silly and I'm very
immature so the following video should now be treated as my reaction to realising that
running order has changed but my slides have not. So this is me, Ian Lloyd or Lloydi as
I tend to go by and I'm a principal accessibility engineer at TPGI which essentially means I
get paid to tell developers all the ways that they have messed up with regards to accessibility.
I'm basically an auditor. So auditing is nothing like that of course. I'm much more
likely to bore you to death with lengthy conformance reports. Before I specialised in accessibility
I was a web developer going back 25 years. Ish. So I get where a lot of you are from
but I'll freely admit that my front end skills have stagnated in recent years. I'm here to
learn just as much as I hope to educate. I've been a specialist in accessibility for five
years where it has been my full time role but have been nagging developers about this
topic for all of the 20 years before that. Today I'll be talking about mistakes that
I see often while doing audits. Many of them well intended but actually harmful. I'll
try to provide some course correction to steer you away from some bad habits. There will
be video and audio in this talk and all video will have captions. I'll also be describing
images shown on screen so no one gets left out. It's important that we do this and if
you remain unconvinced take it from this man. A few months back I had the privilege of meeting
(cough) name drop. Stevie Wonder at a conference in LA. Despite what it looks like in this
selfie of me and Stevie I am not wearing an apron and this was not a cookery convention.
He thanked me for all the work I did in accessibility and said it transforms lives. Okay he didn't
say it directly to me. He said it to a group of maybe 200 people but I was in the group
so it still counts. Right? Anyway let's get this started and I'm going to start unconventionally
by showing you a sausage. Here it is. If you recognise the cartoon sausage that has just
appeared on screen don't shout it out but if you do recognise this particular sausage
please put your hands up. Okay but this is all terribly sighted of me isn't it? Perhaps
not everyone can see this sausage so here's a clue for those not currently enjoying the
view. Sounding familiar? That's Chicken Man by legendary library musician Alan Hawkshaw.
In case you are not aware of library music this was music performed by session musicians
that broadcast as produced for TV shows. Think of it like the audio equivalent of stock photography
and the show that it was used on was Grange Hill and that sausage is of course the one
that flies in to view in the opening credits. Oddly a version of Chicken Man was also used
on the TV quiz show Give Us a Clue briefly.
Why the heck am I referencing a TV show from 40 years ago? There is something that's stuck
in my head from those days and it revolves around this girl and this guy. Janet St Clair
and Roland Browning. For the old farts in the audience what catchphrase comes to mind? Anyone?
I'm trying to help you Roland. I'm trying to help you Roland. Janet St Clair appointed herself
as Roland Browning's friend, counsellor and advisor but ultimately became a total
annoyance and frustrating presence for Roland and some of the help that developers provide to
enhance accessibility land in a similar fashion with assistive technology users but after this
session I hope to have pointed out some of these nasty habits. In the image showing on screen,
Janet is saying "but I just want to help you Roland and he's looking away responding with
'leave me alone!' Don't be like Janet." I've undertaken many a web accessibility audit in my
time and I've seen a few sights it's true to say and while this normally means inaccessible sites
such as no keyboard support, terrible contrast, no alternative text, you know the usual suspects,
I also see a lot of examples where the developers 'have had a go'. By that I mean that they have
clearly picked up an idea or two about accessibility along the way and have shown some enthusiasm to
make things right. But as the saying goes a little knowledge is a dangerous thing. Several
of the mistakes I see are down to misunderstanding of when it's appropriate to take a certain approach
because context is everything and sometimes it's a misunderstanding about how assistive
technology users navigate and access site content. What I'll be doing here then is running
through some typical examples of over-enthusiastic but slightly misguided attempts at making a
site more accessible. I absolutely do not want to discourage any developer from making things
more accessible but there is definitely a need to do some course correction here and there.
Given the Grange Hill reference one might say that some of these are schoolboy errors.
I'm going to be covering issues that fall into the following three topics. Naming and shaming,
how you can accidentally go overboard with naming elements. Picture imperfect, common mistakes people
make with alternative text for images. What the focus? Understand how AT users navigate a page
and how it doesn't mean making everything focussable. There are a few bits of jargon that while I
suspect most of you will be familiar with I just need to briefly cover. AT is assistive technology
thanks green readers. WCAG means work content accessibility guidelines. These are the
accessibility guidelines by which websites are judged and deemed conformant or not.
And sc equals success criterion. Each conformance issue that is found during a site order is
filed against one or possibly more WCAG sc's. For example images missing alternative text
will be 1.1.1 failures. Low contrast text would be 1.4.3. Keyboard issues will be 2.1.1 and so on.
[Spongebob laughs]
As SpongeBob has just demonstrated filing issues like this is fun.
Shall we dive in? Let's get on with the first of our three topics. Naming and shaming.
And we begin with problems caused by overriding accessible names.
Let's start with a simple 'log out' link. Here's a perfectly good one right here. It uses the correct
markup as a nice clear accessible name of 'log out'. So what could you do to break this?
This is the kind of thing I see a lot. The 'log out' link has been given an
`aria-label` of 'my account'. The intention here was to provide additional information
that this link will log you out of your account. Not that it's really needed or helpful mind.
I mean what else would it log you out of? The problem is that the `aria-label` is not providing
additional information. In fact that `aria-label` overrides the default accessible name of log out.
Why is this a problem? Let's demonstrate that with a couple of videos.
First of all we'll put ourselves on the shoes of a blind screen reader user.
In fact I'm going to hide the UI completely for this one to give you the full effect.
Visited. Link. 'my account'. You are currently on a link. To click this link press control option space.
Main. Heading level one. You are now signed out. I'm sure that's what you really wanted. Right.
So we heard a control announced as 'my account'. We tried to activate that and then found
ourselves kicked out of the application. Not exactly helpful. Now let's try this again
with the UI showing. This time we'll try to experience it from the point of view of a
sighted user who has mobility issues which means they cannot use a mouse or keyboard even to navigate.
For this example we'll be using dictation. How do you activate a control? As the saying
went in catchphrase you've got to say what you see. So here's our user Jeff who is quadriplegic
and neither can either use a mouse or a keyboard and use his voice commands. In the video that
follows note that Jeff can see 'log out' but it's not possible to activate that control by saying
what he sees because that pesky `aria-label` of 'my account'.has meant that the computer doesn't know
about any control named 'log out'. So it only logged out when it heard the phrase 'my account'. Confusing.
Right. Tap 'log out'. Tap 'log out'. Show names. Tap 'my account'.
Strange. Jeff sounds suspiciously like me don't you think? This is what the computer thinks is
going on here. In the accessibility pane in dev tools we can see that the original accessible
name 'log out' which is provided by the link elements contents is crossed out and the act name now comes
from the `aria-label`. If the thing that you can see is named something entirely different you have
failed success criteria in 2.5.3 Label in Name. Poor Jeff he just can't log out. Still it could be
worse. He could be Dave. He's having a very bad day. I'm sorry Dave I'm afraid I can't do that.
What's the problem? I think you know what the problem is just as well as I do. What are you
talking about? Well clearly HAL's talking about a flagrant failure of success criteria in 2.5.3
label in name as this highly scientific annotated photo explains. Dave is trying to open the pod
play doors and HAL is like I don't know what you're on about mate I call these my 'space hatches'
you've got to use the right terminology man because that's how HAL talks of course.
So don't override your controls accessible names with helpful extra information.
But I'd like to help you Ronald. Well you can't.
Well that's not entirely true. If we really wanted to add extra information we can put that in the
`aria-label` but it must include the visible text in it. So with an `aria-label` of 'log out' of my account
you provide that extra info but don't cause issues for assistive technology users.
Now let's look at some verbosity problems. Now we're looking at a couple of lists links in
a list so there could be a fair few here potentially. The accessible names of these links are fine
perfectly fine. Visited link log out list two items link profile you are currently on a link
but sometimes people feel the need to add lots of extra information in there which is
not necessary. Now we have extra content provided with the `aria-label` attributes
the `aria-label` content is 'log out' of 'my account'.update your profile email picture address and more
visited link 'log out' of 'my account'.list two items link update your profile email picture address and
more. This time though there is no 2.5.3 Label in Name failure as the visible text is in the
accessible name that the `aria-label` provides. But it's very wordy you might think that this
is helping but many screen reader users would disagree. You're putting up more hurdles it takes
longer to listen to the links if you're tabbing through and if the screen reader user is bringing
up a list of links on the page as they often do that list is going to be unnecessarily verbose too.
One option is to decouple that supposedly helpful text in the example I'm showing on screen now I
have used the `title` attribute to provide additional context this would appear over the element if you
were to hover over it but it will also provide an accessible description. The accessible name which
is what a screen reader user will perceive when tabbing through or bringing up a list of links
remains brief and to the point. If we check that in dev tools we can see that the accessible name is
profile and the description is update your email picture address and more. In the next video though
note the slight gap between the announcements of the links accessible name and the additional help
text. List two items one of two visited link 'log out' 'log out' immediately you are currently on a
link to click to link profile update your email picture address and more. One thing to point out
I have used the `title` attribute here but you should know that title is pretty shite generally it's not
available to a whole range of users for example a keyboard only user tabbing through that control
won't see that text as a tooltip so why did I provide an example using it mainly to be a bit
of a dick about this because frankly I personally just go back to the original version and not
bother with that help. If you really want users to get additional help do so in a way that all
users can perceive. Here's a more robust way we put the extra help text on the page which gets
shown as a tooltip when the link element is hovered or receives focus. The `aria-describedby`
attribute in the link references the text node thus providing an accessible description for the link.
Ah click here links deep joy let's go back to our two link examples again remind ourselves what
two perfectly simple links look like that's the 'log out' and 'profile' links now what do you do with links?
[Music: A Tribe called Quest]
So I think we've established that we can click it. That's just what you do with links. Better tell
the users that this is what you have to do, otherwise they'll be stuck right? No, they won't.
It helps nobody to add that extra 'help'. Please don't add 'click here to do whatever' in `aria-label`
attributes. It's another example of unnecessary verbosity that will be felt most by screen reader users.
Once again, the advice here is just not do the thing where you add extra 'help'. It's a link. People
click them. Well, maybe they don't: bear in mind that not everyone will be clicking that link
using a mouse. Screen reader users will actually be activating it with the ENTER key and some users
may be using physical switches. Don't repeat yourself is a programming concept as old as the
hills and in this section I'm going to cover how this affects accessibility. Let's reset again and
look at our two links. Ironically, in a slide titled 'don't repeat yourself' I'm showing the same links
as the previous slide, but now let's see what some people like doing: adding pointless `aria-label`
attributes that have the same info in. Technically there is nothing wrong with this. It is not
inaccessible. It does not fail any WCAG SCs. There's definitely an optimization issue here, though. I
mean why have the link text and then override it with an `aria-label` with the exact same text?
That won't help with your web performance if all your links and buttons are handled like this.
But there is a bigger problem that may lie ahead.
wenn ich die website in Deutsch übersetzen würde hätten wir möglicherweise ein problem
depending on how that came out there is probably a mixture of reactions along the lines of 'what the
fuck was that?' That was German, or my attempt at it. Oliver is probably crying at the back of the
room right now. What I said, hopefully, was if I were to translate the web page into German we may have
a problem. What is the problem? Should you choose to translate a web page you might find that the
text on screen is correctly translated but the text in the `aria-label` attributes is not and now
we find ourselves in a situation where we're failing success criterion 2.5.3 Label in Name again.
Here is a demonstration of this using Voice Control on macOS.
Note that I cannot tap the 'ausloggen' link and I am only able to identify the link's actual
name by saying the command 'show names'. Click 'ausloggen'
click 'ausloggen'
show names
click logout
Note this is something that you that could occur if you translate on the fly, but it can also occur
if your site has localization through some kind of token, that visible text is easy to maintain
because it's visible it's visible text text is inside an `aria-label` can easily be overlooked
and I have seen this while auditing a Thai and Chinese version of a major tech brand's flagship
products. All visible text was translated, but there would be occasional button or link names
that were still set in English as they had overlooked the tokenization of these phrases.
If this sort of thing happens due to the not tokenizing these `aria-label`s correctly you've
accidentally failed success criteria in 3.1.2 Language of Parts, so it's just good housekeeping.
Don't repeat yourself with `aria-label` attributes. There's Janet, shrugging. She doesn't want to hear it.
For the second of our three sections, we'll be covering images. If you drop an image into a page
you should describe it for the benefit of non-sighted users. Right, so this seems fine does it?
The `alt` text for this is just 'dog'. Not really telling us much is it?
How about this instead?
A cairn terrier lying down on a beach looking up and expectantly waiting for another stone to
be thrown into the sea for her to retrieve. That's the alternative text provided now.
Well, that's more like it. Not too verbose, it conveys just enough enough information to provide an
equivalent experience for blind users. The problem is that sometimes people take the
same approach with *all* images. Let's take an example of a button that has an arrow in it
as some kind of indicator that it will take you somewhere. The markup for it is very simple.
Even the arrow itself is just an emoji character. This button has been styled with CSS
and you should note that the emoji character renders differently in the browser from how it looks
in a plain text editor. But how does it sound? Apply now right pointing arrow button.
I mean it's not terrible but it's a little clumsy and verbose for screen reader users.
As I noted before, the accessible name is in most cases simply the inner text content.
In this example, the symbol comes with its own descriptive text, as all emojis do and that is
exposed on the button name. Now you could, for example, not use an emoji character which does
have some unpredictability about how it may be rendered across platforms and instead use an image
element and provide your own accessible name using the `alt` attribute. But please, for the love of dog,
do not do this. The image has an `alt` value of green arrow pointing to the right which then means that
the button's accessible name will be 'apply now green arrow pointing to the right'. Yuck. This is a
classic case where, having learned that images need to be described, a developer might apply that rule
across the board. But is that the right approach here? no no no no no no no no no no no no no no no no
No. For an image used in this way you really want it to be ignored by assistive technology.
So just give it an empty `alt` attribute. This suppresses any rogue announcement, so a screen
reader user will just hear 'apply now, button'. Is this better? Yes! Yes! Yes! Here's another example
of where we should avoid repetition. Because it's been drummed into developers that images need
alternative text sometimes people can get a little too carried away. In this section, I'm going to
highlight a few examples of this. Let's start with what I'm going to call the Jimmy Two-Times problem.
You remember Jimmy from Grange Hill, yeah? No, he wasn't a Grange Hill character you, have to fast
forward a few years to Goodfellas in 1990 for this reference. "... and Jimmy Two-Times who got that nickname
because he said everything twice like i'm going to go get the papers get the papers". This situation
crops up a lot when a link is wrapped around both an image and some real text like this.
And here's the markup for that example. Having had it drummed in so much that images must be
described, we end up here. An image with an `alt` attribute that exactly matches adjacent text.
You can imagine how annoying this is on pages where you have a series of thumbnails like this.
and if you can't imagine i'll try to help you here the papers get the papers
get the papers get the papers ... get the papers get the papers". Alright, so in reality it sounds more like this
to a screen reader user. "link Tesla Cybertruck spotted in Anaheim California Tesla Cybertruck
spotted in Anaheim California".So while people might think this is the correct thing to do here is a
clear example where you just want the assistive technology to ignore the image. Doing so as simple:
just add an empty `alt` attribute. This is all you need to stop it being exposed in the accessibility
tree thus hiding it from screen reader users and other assistive tech. If it's an SVG or canvas
element you cannot use `alt`; that's only for image elements. Instead you use `aria-hidden="true"`.
Don't be like Jimmy Two-Times. Don't be like Jimmy Two-Times.
When thinking about how images should be named, the key question is what are they being used for?
Another example where "you must provide a descriptive `alt` text for all images"
can have a negative effect. Sometimes people can get a little too keen with the description and in
some cases it's wholly inappropriate. Take the example of a logo. Here's one that comes to mind.
And don't panic, Oliver, I'm not about to embarrass you! Now, if we were trying to explain how the logo
looks you might reasonably describe it like this: "A light teal and red compass logo with the text
'Pixel Pioneers' laid over it. The 'o' in 'pioneers' forms the central pivot of the compass hands.
Seems fair, at least if this were in the context of, say, an article where you're discussing logo
design. In the markup showing, we can see that it's applied to the element inside an
If it were an element, that would be applied to the `alt` attribute. But what if it's an image
that is used in a link? Very typical usage. Now, does this alternative text still seem right?
The problem now is that the alternative text is now providing the accessible name for that link.
What does that link do? It takes you to the Pixel Pioneers homepage. What would a screen reader user
hear? This: "visited link, image, a light teal and red compass logo with the text Pixel Pioneers laid over
it. The 'o' in pioneers forms the central pivot of the compass hands". Well, that's not going to help is it?
In this case the exact the image description is not really what we want. Aand just to reiterate, this
is not what is happening on Pixel Pioneers website, this is an example of how not to do it. Given that
the link phrase is really not saying what it will do I'd fail this under Success Criterion 2.4.4
Link Purpose in Context. But, depending on which day of the week it, or which auditor you ask,
some might also fail it for 1.1.1 Non-text Content and 2.4.6 Headings and Labels.
The alternative text should instead indicate the purpose of the link that it is inside. This is how
it's implemented on the Pixel Pioneers website. Although iI would suggest a tiny refinement:
I've just added the word 'home' to the end to make it absolutely clear.
You could, however, achieve both aims by providing the short accessible name
that indicates where the link goes, and also provide a description. As with examples shown earlier,
we can use `aria-describedby` for that. Note that in this markup the descriptive text is only available
to assistive technology users. The it's contained in is set as `hidden` and it will not
render on screen. However, hidden elements may be referenced using `aria-describedby`. So it's a
safe approach. Now a screen reader user can get a quick link phrase, but depending on which screen
readers they are using they will either hear the description after a short pause or they will be
able to get the description if they choose it. In the following example we can hear VoiceOver
indicating that there is more content which the user then can listen to: "visited link, Pixel Pioneers
home, you are currently on a link. To click this link press control option space press control
option command slash to bring up the more content menu more content menu one item description a light
teal and red compass logo with the text Pixel Pioneers laid over it. The 'o' in 'Pioneers' forms
the central pivot of the compass hands". So that's the best of both worlds. The description can be
provided but it's no longer haranguing the user. "I'm worried about you, Roland" "Will you leave me alone?". We can't do that for
you. Roly. This is the last part of the images section where I explain why you don't need to tell
people that an image is an image. If you're dropping an image into a page, please please don't prefix it
with 'this is an image of whatever', because the thing is when you put an image into the document it
automatically exposes itself in the accessibility tree as an element with the role of image. So the
image element is equivalent to manually adding a `role="image"` 'i m a g e'. Or is it? At this point
one or two of you might be wanting to yell out because there's an error in the example shown here.
Feel free, can anyone spot it? Fun fact, the `role` that you would need to set to have a generic
element exposed as an image is actually 'i m g' not 'i m a g e' Anyway, the point is when you drop
in an image, it is automatically exposed as an image to assistive technology users, as the next
video demonstrates: "image of a startled raccoon image, image of a budgie fuggler in leopard print
image, image of a farty sketchy squirrel image, image of, image of, image of a red sketchy squirrel
image". So you don't need to say "this is an image" in the alternative text, you're just adding to the
verbosity. The only time I might suggest that you should add phrases like like this is is where it
is truly relevant. For example, if a blind person were looking to buy a gift card for someone
they might want to know if the image was a watercolour or line drawing or a photo, so you could
describe the *kind* of image that it is, but you absolutely do not need to label it as an image.
There's Janet, desperate to help again, being shut out. Her help is just not needed here.
For the third and final section I'm going to cover issues related to keyboard focus.
The image showing is a still from 'Everything Everywhere All At Once' but is now labeled
'everything focusable all at once' because that's another misconception that I come across more
often than I'd like. It's the belief that for content to be accessible for screen reader users
everything needs to be focusable. Because how else will a keyboard only user navigate around the page?
Let's find out how wrong this is with the classic example: a table. Here we have a typical table of
employee details. And here we have the first row of that table with `tabindex` applied to every cell.
Every damn cell in every damn row. Let's see and hear just how bad an idea this is.
"entering table employee at table six column first name last name you are currently on a
cell in department in 1001 software engineer jane you sales representative emily dot william 1006
robert davis you support you ashley dot taylor at company dot com you are currently on a". Note
that to get from a focusable element before the table to the next focusable element after the
table took 61 TAB key presses for keyboard only users which the great majority of screen
reader users are. This is the opposite of being helpful. If i saw this I'd be failing it under
WCAG success criteria 2.4.3 Focus Order, although some might argue it's not a failure as the order
is correct. The view here is that there are multiple, ridiculously high in number, non-interactive elements
that are receiving focus and causing problems for keyboard only users.
All we really need to do is this remove the `tabindex` attributes. Simple. In the video I'm about
to show I'm navigating up and down through rows, and left and right cross columns, just using the
arrow keys. No `tabindex` required. "table six columns 11 rows in table no sir first name last name job
title column four of six row two of 11 software engineer row three of 11 marketing manager row
four of 11 row five of 11 human last person employee first name emily last name williams
job title human resource". The same applies for headings, paragraphs, really any block of content
that is non-interactive should not be focusable and `tabindex` should not be applied.
Some of you may be thinking at this point 'but there are situations where you genuinely
need to add a `tabindex` to a generic element'. For example, you may be creating a custom select element
because it's not possible to style the default HTML option. While it is always more preferable to use
a native HTML element than to create your own custom one there will be cases where the custom
option is your only choice. If you're using native interactive elements such as , or
the element `role` is automatically conveyed to assistive technology users. Remember the example
of the image where we don't include 'image of' in the `alt` text? But if we're creating something from
a humble or element, just remember that you need to specify the element's `role`.
Because while you can visually style something that suggests a certain interaction, a blind screen
reader user won't get that cue. All they will know is that they have TABbed to a thing on the page so
presumably it does something? Providing a `role` will manage some users expectations about what they can
do with that thing. Another word of caution regarding focus issues: there are times where it is valid
and expected that the user's focus should be moved on their behalf. For example, opening a dialogue:
focus moves from the trigger to the dialogue or interactive elements inside, and form errors:
moving the user back to fields that were entered incorrectly upon submission. All valid examples
of moving focus. Sometimes, though, we see instances where focus is moved and it seems like it might
be useful but actually ends up causing more pain. Let's take a look at our company employee
database again. This time, the table is simplified and only shows the employee's names and job titles.
All the other information is shown in a panel to the side when needed, like this:
Note that in the example here it's just me using the mouse. I click a thing, it shows the details
immediately on the right side of the screen. What's not obvious here is that the focus is moving to
the heading on the right panel, but you can't see it because this was done using a mouse click
not using a keyboard. Now let's see the keyboard user's experience, and with the screen reader running.
"look up employee 1001 jondo button you are heading level two 1001 jondo details panel region"
That seems okay, right? The focus has moved to the heading for this newly revealed content,
the screen reader has read out the text that's been shown. But what if i wanted to check
other employees details? Let's say that I now need to check the second person's details. Well ...
"jondo details panel region you are currently on a heading level two
entering employee details look up employee 1009 look up employee 1001 look up employee
1001 look up employee 1003 michael johnson button heading level two 1002 james smith"
That was a lot of backtracking for a keyboard user. That was nine SHIFT + TABs to get back
to the next person on the table, and this is a very short, very fictional table.
Another 2.4.3 failure. Or is it? Actually no it's not. The focus order is correct once you've moved
to that right panel and only interactive elements are focusable as you move back, but it's still a
shitty user experience for all keyboard users. The point here is that what you thought was helping
might not be entirely welcomed. "Browning!" Roland is getting *really* cheesed off with all this and
just pushed Janet through a wall. Alright, it's a prop from a school play made of paper, but clearly
he is done with all her 'help'. So, how might you approach a UI like this instead of moving focus?
Leave the user's focus on the button that they just clicked. For screen reader users the display of
that text can be handled using live regions. When a live region is updated, the change of content
will be announced. Here's a different version of that tool. Note that I am free to navigate through
the buttons and display the text without then having to SHIFT + TAB back through multiple controls to
get where I came from. "1001 john doe job title software engineer department it email john dot
doe at company dot com home address 123 main saint springfield ill 62,007 look up employee 1002
look up employee 1003 look up employee 1004 emily williams button 1004 emily williams job title
human resources special look up employee 1005 david brown button 1005 david brown job title
financial analyst department". Another option would be to treat that content on the right
as a modal dialogue, whereby you can only get back to the main table content by closing that panel.
That way the focus can be properly managed and move you back to the control you previously selected.
There's no video mock-up for this one, you know about dialogues, right? So to summarise everything
that I've just said then. Any time that you are adding an attribute that starts with `aria-` question
whether it's really needed. If it is needed, check that you have not actually caused issues for assistive
tech users. Always favour native HTML over custom elements where you can. Shun the mouse: try to navigate
what you build with keyboard only. Have you helped or have you hindered? If it's complicated to make
it accessible maybe it's too complex for *everyone*. Actually regarding point 2, try to test in a
screen reader as part of your *routine* testing, not just when adding `aria`. In short, don't be like Janet.
Whatever you do to help improve the accessibility of your web content and interfaces, be sure to
test as much as you can to make sure that your 'help' is not as welcome as Janet's constant interventions.
"What? No. Have you been listening to me or what? Go away! Will you just leave me alone! Mind your own business
Sherlock Holmes. Oh shut up! You shut up! No! Go away! Why don't you shut up?!"
So that's all from me. If you have any questions about anything I've shown here,
please feel free to harangue me later. Just remember, I only want to help you, Bristol. "Is that it?","Yes", "Right"