So let's talk about focus states focus is one of the most important features that enables users to use
a computer with just a keyboard, most stylesheets will have this one piece of code that will cause
major accessability failure.
And this is it yet removing the outline.
So let's go back just a bit.
That would remove this outline, which is horrible.
Do I ever do this ever?
You should avoid doing this like the plague.
Keyboard users will know what element they're interacting with because of the help of focus styles.
So Focus highlighting is only used for interactive UI elements like form elements and buttons.
So we need to make sure that we keep that in there.
Another thing we should always be thinking about is focus, contrast, it's a guideline to have the
color of your outline adhere to contract standards as well.
So if you look over here, we have an orange outline and that is definitely going to be accessible.
There is enough contrast with that white background.
But if you were to have a very, very light gray, that's just not going to work.
Next is to think about off screen content in relation to focus.
Keep in mind that sometimes we design content that is hidden off a screen, kind of like this menu over
here in this example.
Some of this content could be like hamburger menus, models, etc. Sometimes when a user is tabbing
through focus points, they can lose track because it could be highlighting something off screen.
Could you imagine how confusing that could be for a user?
If I was tabbing through something like this and I was picking up navigation items, super confusing.
This would cause so much confusion and the user could lose track of what they're doing on screen.
Speak with a developer about solutions around this.
But if you're feeling comfortable enough, you know you can do this easily with access or JavaScript.
Next is morals, morals can be an accessability disaster.
We're not done properly when users tab through a model like this, they should be confined to just the
model they should never be focusing on content behind.
So could you imagine if I was tabbing through moral title?
The exit button, whatever contents within these buttons, and then all of a sudden I tap through launch
demo model, I would be pretty confused and lost.
So make sure you have that conversation as well with developers.
Now, however, states also apply to focus, and however states should be made accessible, users should
be able to tap through hover areas, as they do with focus space areas, because sometimes we actually
hide certain interactions under a hover state.
Think about Facebook and the reactions you need to hover over that like button before you can see all
the other reactions that Facebook does a great job with making it successful.
You can actually tap through this as a focus state, which is amazing.
Let's talk about kallick targets.
Now, big thing is cards, cards are used a bunch and products these days, and it's important to create
accessibility friendly cards since they can get so complex with multiple states based on the type of
interaction being performed.
A really good example of how cards can be made accessible is through Google Inbox.
Now, if you take a look at.
Over here, this is Google inbox, and this interaction is really great, so they assign specific focus
stakes to that.
So they assign specific focus states for the cards that the user has navigated to.
So you'll notice that the person here is navigating to all these different cards.
And then you can see that this is the card that they're currently on.
The hover action is completed on focus.
So the hover action over here for all the different actions you can take on an individual inbox item
will be highlighted while you tab through, which is also great.
Now, another thing that people fail to realize is you don't necessarily need to make every single UI
element on the screen towable.
Or forecastle.
What Google Inbox does really well in this specific interaction is that only the actionable items are
focused and not every other element in the card.
So over here, you'll notice that only these primary actions are actually.
In focus in comparison to like all these other elements.
Next is target areas, we need to make sure that target areas are large enough for users to select on
a page, so.
Some users have motor impairments and it find it hard to select smaller items.
If we take a look over here, we'll notice that the mailbox has a larger topical area, same with what
the edit button would be.
And this is what I was talking about in the beginning around like different that accessibility is greater
for all.
I mean, when you're on mobile, you want a larger topical area and not even if you have a motor impairment.
This just makes my life easier is just going through my mailbox.
So keep this in mind.
Just when you're designing in general.
Now, I just want to say that many of these solutions aren't very style specific, but they do all still
affect us in some way, especially as designers.
We always set out to build products that everyone can enjoy and use easily.
Accessibility should be a part of the design process earlier, and every UI element and every design
pattern should be made accessible.
And most importantly, you should always collaborate with your development team, accessibility is something
that all of us can work towards and do, and it certainly starts with design in terms of style, like
contrast and labels and forms and all that kind of stuff.
But a lot of what happens in terms of specifications will happen on the on the development side.
So it's always important to talk to developers because they're going to have a much deeper understanding
of what's really necessary.
And they can really inform you and help you along the way.
So that's accessability.