Smashing TV: Harris Schneiderman on Translating Design Wireframes into Accessible HTML/CSS(Nov 20th)


>>HARRIS: As we just went over, I’m Harris
and I work for Deque. I’m also a member of the W3C ARIA working group. I’m going to stop
my video feed to avoid bandwidth issues. Today we’re going to talk about “Translating Design
Wireframes Into Accessible HTML/CSS.” So what we’re going to cover today is how
we can incorporate accessibility from the start, you know, all the way from ideation
through design phase, through development phase, and specific to design phase we’re
going to go over annotations and the considerations you must make for accessibility. And we’re
going to map those to some mockups and how certain annotations can actually drive the
output markup the developer is going to be implementing. We’re going to go over passing
off your designs to the development team. And if possible, depending on team dynamics,
keeping your eye on while it’s being built. That will go to development phase implementing
accessible components as well as testing for accessibility. So let’s just get started. Accessibility from
the start. We call that “shifting left” at Deque. I’ve heard other terms for it, but
the idea there is accessibility should be incorporated even in the design phase. So that involves usability testing with users
with disabilities. Usability testing is a common thing, but often overlooked, so a good
idea to incorporate them to get that perspective. Like I said we’re going to be covering annotations
and specifically we’re going to map out stuff like accessible names, labels, tab sequence,
reading order, purpose of the element, and all sorts of stuff like that. But part of
the design phase that I think is really important is having a pattern library. Having a bunch
of tools at your fingertips to orchestrate an app out of your small reasonable components
is really important. And if those patterns and components have accessibility baked into
them, then your job is a lot easier to make an accessible app. In addition to that, everyone has color pallets
and designers really like them, but you really need to take into consideration color contrast,
because if you don’t, you’re setting yourself up for defeat, because the available colors
in your pallet aren’t contrasting enough and then you cause problems for certain users. And another often overlooked aspect of design
phase is collaboration with the developers. I’ve heard tons of stories about, you know,
a design team building a wireframe and then tossing it off to a separate team over the
fence, plug in their ears and crossing fingers that everything is implemented properly. You
definitely should incorporate developers in designer view so they can provide feedback.
But it’s never a bad idea to be collaborating. On that team note, I just want to go over
a few things, a few good practices that your team can actually implement when considering
accessibility. So participating in empathy events is a really
good idea. It gives you different perspectives of how different users with different types
of disabilities interact with things. And I think it’s really eye opening, it’s
a good experience for everyone to see. We also  I’m going to probably mention this
six other times, but please include users with disabilities in your UX design. Like
I said, that’s usability testing, just considering them when you’re building something or coming
up with a new idea. When you do have that idea and you’re mapping it out with comps
or wireframes or whatever it may be, make sure you’re communicating the intent. Designs
aren’t just  it shouldn’t just be a presentation layer, just what you see. It’s actually what
you experience. So you should be communicating this so the developers know what the intended
behavior is and actually make it function as such. I went over pattern library. I want
to harp on that. It’s really important having accessible components, it makes your life
really easy. On top of that leveraging an accessibility automation library is great,
because automating some of the lowhanging fruit can actually speed up your development
process and help you catch accessibility issues as early on in that process as possible. That’s
what we mean by “shift left.” You don’t want to find accessibility defects in production
and ideally not even in your web server. You’re making a poll request with your developer
accessibility tests having already taken place. And on that note there’s some automation that
you can do with device and assistive technology testing. You know, render your app in a mobile
simulator or testing different browser and assistive technology pairings that you want
to support. But as much of that you can automate the better. That just speeds everything up.
And manage your accessibility defects systematically. What that means is if you have some QA finding,
accessibility defects or anyone really, and you’re creating tickets and throwing them
in the backlog they shouldn’t just sit there in the backlog. Defects, no different than
other defects you may be encountering, so make sure they get prioritized as such. On
top of that you should measure progress with that kind of thing. So if you can come up with some metrics like,
say, the last three sprints we consistently added only two accessibility defects in the
future we want to shoot for none, so we bring that up in retrospectives and maybe pivot
or tweak our process to stop shifting accessibility issues. So let’s get into annotations and
how we can communicate that intent. It’s kind of the theme I’m really harping on. The first
type I want to go over are widget annotations. And let me just  we’re going to be looking
at the same wireframe with different annotations for the next few slides, so I want to describe
what this set of components are. So we’re looking at a presumably audio player
control, previous track, play, pause and next track component. The widget annotations are
going to go over the purpose, the role of the given component as well as the accessible
name. What we mean by that is what will AT read out when a user interacts with that content?
I’m going to go through each of the three controls and step into the wrapping element. So the previous track is a button, and its
name is previous track. And in the current state that we’re viewing, it’s disabled. And
I’m going to go to the play pause button to describe why mapping that state out is important.
So the play/pause button is currently playing because the pause button is showing. We’re
going to get into the state fullness in a couple slides, but it is also a button and
its name is pause currently and it’s focusable. So the state on previous track button is disabled,
so it’s not focusable and this one is focusable. It’s important the designer is thinking about
these things so the developer can implement as such. Next we have the next track button, and also
it is focusable and also a button. And the wrapping element, actually, an often overlooked
aspect, we’ve decided it should be a toolbar, because that’s what it actually is. And we’re
going to give that toolbar an accessible name of player control. So when an AT user tabs
into it, they actually hear the purpose of this group. Next up we have interaction annotations. And
as that would sound, it is basically describing the various interactions that this component
will have. So for the  for the buttons, we say spacer enter equals a click, disable the
buttons cannot receive focus and sale buttons not respond to a clicker touch. The first
space or enter you get for free with native HTML button. I definitely want to stress that’s
important to do, because you don’t need to write some JavaScript to make it behave like
a button, just use a button. For the purpose of the documents we decided to put that information
here. We have interaction for the entire component. So some of this might seem pretty obvious,
but I really think it’s probably a good idea to map out the obvious just to ensure that
everything is implemented properly. So I’m going to go through all of these. When we’re
on the first track of the audio player, we’ll disable the previous track button. There is
no previous track. Last track, disable the next track button. When playing the audio
file, we will display the pause button and hide the play button. When not playing, display
the play button and hide the pause button. But the last two points are important because
it’s something you really have to be thinking about. It’s a little tricky, but we say after
clicking play we place focus on pause button. After clicking pause we place focus on the
play button. The reason that is really important is presumably we have two controls, right?
A play button and pause button. I know you can probably manipulate background elements,
but pretend we have two elements. Play or pause button. I tab into the audio player,
which is playing, and the accessible name is pause. I click that pause button. The JavaScript
that I wrote is probably going to add display none or maybe remove that pause button from
the dom, and remember that was focus. So what does a browser do if we have a focused element
that we removed from the dom? Well, obviously it does not know what is going on. So you’re
going to get focus brought to the top of the document, basically the body. That means users
with disabilities using just a keyboard would actually tab all the way to your page, hit
the pause button, click the pause button, rather, and get shot up to the top of the
page. So it’s important to think about focus retention in this context. We also have alternative
state annotations and those are pretty common. Like designers love to make hover interactions
really pretty, but it goes beyond hover. It includes stuff like your focus state where
you can map out the background color and the foreground color. Even active state or pressed
depending on what you’re doing, but these are stateful annotations that are required
for someone to implement this properly. Number four here, minimum control size annotations,
I left this as a separate type of annotation because it’s really easy but it’s really easy
to forget. So WCAG has a requirement  I’m sorry if I get the actual number wrong, but
something like 44 X 44 CSS pixels is minimum touch target size for a control. So if you’re
a designer and not considering that, you’re going to hand the developer something that
is set up for defeat if you go below that 44 X 44 threshold. So it’s important that
you document those dimensions. This one is one of my favorite types of annotations,
which is focus order. What we’re looking at is a piece of UI, and overlaying the UI we
have little blue tab stop indicators, and those are actually enumerated. So we’re actually
describing what the focus order should be. So that way the developer knows to implement
it like that and actually it kind of holds their hand to  it actually drives, in my
opinion, dom order, which actually means we’re going to get a good reading order as well
with that. So thinking about this from the start actually
creates better components, better markup, and in turn more usable by all your users.
So reading order. We’re looking at that same exact piece of UI, but instead of the enumerated
tab stops we have arrows that basically draw the user through  draw you through how a
user would be reading this content. So I want to get right into our example app.
It’s a completely fake app called “awesome recipe” and lets you track and rate the recipes
you cook. To get everyone inspired I have a very mouthful goal here with big words,
but to create a set of designs that articulate the esthetic behavioral in design central
accessibility considerations and facilitate rapid iterative development. So now we’re
inspired and we’re going to… we have a top bar, a heading, section of stats. We have
some filters and some repeaters, some cards or tiles or whatever you want to call them
that actually render each of the given recipes. So before we actually show any annotations
I want to go over our key here. We have some B&L teardrop indicators. That’s a quick way
for your designer to say, hey, this is a button, this is a link. We also have a little callout
speech bubble that is kind of followed by an accessible name “box.” That’s how we can
document things like alt text or icon button controls should have as their accessible name.
We saw a bit of that with our audio player controls. We also have tab order. I just displayed the
cool enumerated tab order thing. And we have a little key here for how you use that. And
we also have some generic rolename annotations. You can say, hey, slap rolename on this thing
or whatever it might be. I do want to mention that this  either in the exact state or maybe
tweaked a little by the designer I work with, but I actually originally came across these
cool annotation things on the accessibility Slack channel. I want to stress there’s a
really awesome community out there of accessibility experts of all sorts, designers, managers,
marketing people, but it’s a good resource, and I found this and got excited and told
my designer that you should start using this and he got excited and we use this ever since
then on all our wireframes. It’s great. So let’s get into the first component we’re
going to dive deep into which is the recipe card. We’re going to render one of these for
each recipe. All right. So we’re looking at a chocolate
cake kind of low fidelity  it’s a wire frame but we don’t have any actual images. It’s
grayscale right now. But I want to go over each type of annotation we have here. The
first one is really common and everyone should be used to seeing this if they see any wireframes.
We have measurements. The card should be 277 pixels wide, 379 pixels tall. The image should
be 142 pixels and so on. But we also have cool accessibility focused annotations here,
like the accessible name of this edit icon, this pencil guy. They’ll have the accessible
name of edit followed by the recipe name. In this example it would be edit chocolate
cake. And when you click it invokes the edit modal. Really, really important here is that
we have marked this image for the given card as decorative. It’s a tough one to wrap your
head around. Actually I’ll get into tips on how you decide whether image is decorative
or informative. We decided this will be decorative because it doesn’t add useful information
to the card because we actually have the heading there in the card right below it. It has the
same information. In this case it’s chocolate cake. And we decided that the edit icon thing
is going to be a button and the cook button at the bottom is going to be a button. So more annotations for this one little card.
We have box shadows, foreground and background colors, but more interesting stuff is we decided
on heading levels from the start. So if I if we back up all the way to this view of
the whole app, we decided upfront how our heading structure is going to be. We decided
recipe dashboard at the top, H1, we decided each stat heading is H2s, and therefore the
next in line would be these H3s for the recipe card. Let’s go back to where I was. And so
we’ve actually annotated that as such. Another interesting aspect here is we mapped out what
the focus indication is going to be for each of the two controls. So this is really going
to drive home my point of a pattern library even more so. This designer actually just
said default focus. And that is relayed to the developer, who has context, that’s pattern
default focus. Just let our focus ring render like it does for all our controls. On the
contrary, the designer decided to make a fancy focus indication for the cook button at the
bottom because he felt that it was a special control. And so it has these little array
brackets on each side when you hover or focus it. And we actually mapped out that behavior
here as well that when you click it, it actually invokes the read version of the recipe, so
you can view the instructions and the ingredients. Which actually is what my next slide is about.
So now we’re looking at the view recipe modal. We’re looking at a pretty basic modal dialogue.
It has an ingredients heading and unordered list of ingredients, and then an instructions
heading and then an ordered list of the instructions. We do have two form controls here though.
We have a “rate the yumminess” text field. You can say, that was yummy, I give 50 out
of 50. Or, no, that was terrible, 10 out of 50. And a check box control to tell the app
whether or not you caused a grease fire in making your recipe. So let’s look at the tab order of the modals.
They’re actually really special when it comes to tabbing. Firstly I want to focus on this
focus. No pun intended. I want to focus on the alpha tab stop. It’s annotated with alpha
character, the A, and it’s a special tab stop. I’ll explain why. When I click “cook chocolate
cake” button we render a modal and we want to shift focus because keyboard user needs
to interact with the content, and the user usually doesn’t interact with anything but
the modal. Shift focus to the dialogue or something in the dialogue. We decided to move
to the heading and the heading is an alpha tab stop because we actually will tab from
the heading to the X button in the top bar and go through the two controls and then the
footer controls and back up to the top, because they’re an accessibility requirement of modals
is trap focus, what I call a circular tab order, but the heading will get skipped after
you blur it. When I tab from the last footer control up to the top X button, we’re going
to skip that heading. So we want to call it alphas because it’s only focused in the state
in which you have just opened up the modal. So very similar we have a kind of edit version
of that modal. And what we’re looking at is instead of a list of ingredients, we have
a list of prepopulated text fields with each ingredient, so you can edit them. Next to
each field we actually have a trash can icon, which will delete our ingredient. Here is
where you really edit your recipe. Similarly we have the same controls except in the form
of a text area for the instructions, which gives the user a little bit more room to write
some more verbose instructions. So here is how we would map out the accessible
name. We’re going to say… so each  we made a decision upfront that each ingredient is
going to be enumerated from a one base index. We have ingredient 1, 2, 3, etc. As a result
of that each delete button is actually going to correspond with that index. So for the
ingredient one, as you can guess, the accessible text for the delete button would be delete
ingredient N and we actually annotate as a button and annotated the two footer controls
as buttons. The only other interesting thing here I wanted to point out is add another
ingredient. Add another ingredient actually appears visually as kind of a link. It definitely
doesn’t look like a button, but since it behaves like a button we decided to mark it up as
such so user understands the purpose regardless of what it looks like. Here is where we can
also map out functionality, either here in some annotations or maybe in a ticket or whatever
you use, where it’s something along the lines of click, add another ingredient, and you
text field rendered, focus shifted to that text field. We also want to map out the behavior of focus
retention when you click delete. So this is another example. Remember I’ll tab to the
delete button and what I’m doing when I click it is effectively removing itself from the
dom. So we need to  like I said we need to shift focus otherwise a keyboard user is going
to be brought to the top of the document and have to tab all the way back in. Here is where
you say clicking the delete button will focus the closest adjacent input, or maybe clicking
will focus the ingredient section if you’ve clicked it. Once again, always think about
how focus will be retained when it comes to interactivity. So I wanted to take a look at the app structure
and go over a couple of the structural roles. The landmark rules if you will. It’s good
to think about this from the start so we don’t have to retroactively apply roles after we
realize we have accessibility violations content outside landmarks. So we decide heading the
hero bar is going to be a banner. Below that is where the main content starts. The main
content encapsulates stats as well as the rest. Really simple stuff, but often overlooked. And then same deal here. We have tab sequence
mapped out for each of the modals. We also do that on the base page. The structural.
So the first tab stop in our app is actually something we haven’t seen yet in any of the
wireframes. It’s skip to main content link. The reason we haven’t seen it is that skip
to main content link is only visible in a very specific state. It’s hidden until you
focus it. So when a user tabs into the page, it actually then is kind of slid in visually
and focused. And when you tab off of it or blur it, it will go back to its hidden state.
That’s the first tab stop. Next we go to the menu item at the top called awesome recipes.
Beyond that we go through the filter lists and then through to the cards. And we actually
dictated tab order within the card here in turn, so we have the ninth and tenth tab stops
are pencil edit icon and then the cook chocolate cake. This tells developer ensure within that
card component that you have this specifically. Keyboard interaction, this is a separate section.
I wanted to show what the readonly modal looks like when tabbing around. Pretend I just opened
up this modal. I’m focused on heading. Now I hit tab. Focus shifted to the X close button.
I hit tab again, focus shifted to the rate the yumminess and I hit tab again, focus shifted
to the check box for grease fires. Then we go to “I cooked it,” the control, and close
button and back to the top. So that’s what visually the focus indication
would look like in kind of a high fidelity fashion. Speaking of high fidelity, here is
what our app will look like with fancy pictures. We have yummy chocolate cake and spaghetti
and filet mignon. Images are in title. This part is where  the wireframe I’m looking
at now is where we map out the focus indications of all the controls. We went over the tab
order for them, so this is what they look like when they actually are focus. The only
other noteworthy thing other than measurements and colors and orders is that here we actually
document the fact that the recipe dashboard should be the H1 page. All right. That’s awesome. I want to move
over to dev and through the woods, but before we do that, I want to talk a little bit about
what designers should be paying attention to when they’re handing these things off.
And your team dynamic may not be set up in a way where this is very possible, but maybe
you can request it. But if it is possible, we recommend taking a peek at a few things.
In terms of color and font, as a designer keep your eye out for insuring your colors
are being used properly and font sizes are used, because that can have a huge impact
on usability of an app, as well as weight. Font weights are easy to get wrong. So make
sure those are implemented properly. Focus is  I think this is the most important of
these four points. Because it’s actually a little tricky, even as a developer, which
I am, to implement simple focus indications. And that’s because the dom stacking order
is a little complicated, and depending on how your components are orchestrated, if you
have kind of several buttons mapped out in a row, they can actually start covering each
other’s focus indications up. If you have a simple 2 pixel black outline for your button,
maybe the right side of that focus indication is covered up because you have  you displayed
flexed on your buttons and the sub subsequent the adjacent element is covering up the previous
elements focus so always take a look at that. And obviously tab order, I can’t stress this
enough, it’s an important aspect and it should be tested for whether it’s the design or the
developer or QA, but it’s an important aspect of your app, as well as accessible names. So typos can cause confusing experiences for
people. So make sure that those alt text and accessible names are accurate. All right. So the development phase, my favorite
part. I’ve kind of just jotted down a bunch of random ideas here or random pillars of
the development phase if you will. These are in no particular order, but unit testing is
part of the development phase. End to end tests sometimes is a part of it as well. Depending
on how your organization is set up. And continuous integration is a great thing to have set up.
Especially for my next, which is accessibility automation. I want to talk about how accessibility
automation can be incorporated in all three of those. Unit tests, testing your component
kind of in isolation proving it does what it’s supposed to do, why not use an accessibility
automation library to run that on your component in isolation? That will help you catch easy
low hanging fruit accessibility issues from the start. Same with indent test. Indent test in very
nature get your app into all the various states, and it actually is the best way to test for
accessibility because contrary to unit test, it actually tests the app where the components
actually live in a browser or a headless browsers, and since you’re already getting your page
into various states, you might as well run some accessibility automation in those states.
Spit out a report if you have accessibility issues. But automation can only get you so
far. You inevitably must perform some manual testing. Automation can’t catch everything.
Our human brains are sophisticated and can decide things robots can’t… for now. And another thing I wanted to mention is you
should always be utilizing your resources. The Internet is full of amazing things as
far as learning accessibility. Reading the actual spec, like WCAG or the ARIA spec, there’s
so incredibly much information there. It might be a lot to take in and I wouldn’t recommend
just sitting down and reading it unless that’s your thing, but take it in stride and baby
steps, if you will, and read about maybe what is relevant to whatever you’re working on
right now and slowly you’ll start building up this knowledge bank of awesome accessibility
information. And I definitely don’t want to miss mentioning
the ARIA authoring practices. I can’t stress enough how awesome those are for me. The ARIA
authoring practices are essentially in my mind a set of  it’s basically like a spec
for you implementing a widget. If you have a widget, let’s say a tab panel, you go to
ARIA authoring practices and it will map out all the roles you need to use, all the relationships
you need to have as far as dom or with attributes, all the expected keyboard interaction. It’s
awesome. Next you have working examples of a lot of them too. Definitely utilize that
resource. I already mentioned a11y Slack. A11y Slack I learn  if I haven’t checked in a couple
days learn stuff, because people bring stuff to the table and ex personalities and anyone
else will jump at the opportunity to help out. It’s a great community. And like everything
else that developers look up, stack overflow, they have accessibility stuff there too. There’s
really good content and questions answered on stack overflow, so I recommend checking
out the tag. There’s cool discussions surrounding mobile development there as well. So before I close this presentation and do
some air quote live coding, very, very minimal. I want to talk about the accessibility automation
lab we’ going to be using. It’s AX Core powered by Deque. I’m a little bias. It’s open source
free use accessibility rules that can run on a document or documentlike structure, and
what it does really is run a series of checks and spits out a report with some violations.
It says, oh, this button doesn’t have enough color contrast, ratio is 2:1. We’re going to be taking our testing a step
further with a new thing we’re calling AXE Pro and beta and free to use as well. But I want to end off before closing the presentation
temporarily with no code merges until #AxeClean. The idea is don’t merge any code until there’s
no accessibility issues. And so I did gloss over that a bit, but continuous integration
might be running unit tests. If unit tests fail when there’s accessibility issues, that’s
a great way to check it. Or if you have a cool netlify preview, deploy set up maybe
write a script to test that. You should make that a required check and you shouldn’t merge
any pull requests until your Axe is clean. A good rule to live by. I want to bring us to our local recipe app
server. I’m in the development phase, so we’re not deployed. I haven’t submitted a deploy
request or anything, but I have implemented it. I didn’t want to bore everyone making
you watch me write code. It would be a disaster. That’s really boring. So I have a partially
implemented app here and I just want to let everyone know that the wireframes that went
through for the cards and the whole app are literally what was given to me to implement
this app. And we use this for kind of some training courses. But what we’re looking at
is literally how we do designs and annotations. So no smoke and mirrors there. Nothing but
the truth. I have this as the heading  the heading says
I have the app built but there are accessibility issues here. Look at how we can find those
first. So I’m going to open up my dev tools. I’m going to open up my dev tools and there
is  I forgot to mention Axe Core has a free axe extension, support for Chrome and Firefox.
You click the big analyze button and it runs Axe Core on the page and tells me what went
wrong. A matter of several milliseconds we have 12 violations they found on the recipe
app page. And those 12 issues are encapsulated in two categories. Elements must have sufficient
color contrast as well as images must have alternative text. So let’s actually take a look and see what
we did wrong. Because, I mean, we thought about accessibility from the start. I mean,
come on… why there accessibility issues? So, oh, this beginner text is way too light
green. I can hardly read it. Users with colorblindness might have a hard time reading it or hard
of sight. I went ahead and calculated the ratio. 2.17 when really it needed to be 4.15.
Harris did a terrible job as a developer implementing what was presumably an accessible color palette
that was documented via the annotations. That beginner text does not look like what I implemented.
Clearly I used the wrong color. Let’s take a look and inspect images without alt text.
Interesting… So each recipe card has this violation because
the recipe image that we remember, we said I really want to make a point that we said
this was decorative from the start. So it looks like, Harris did a bad job implementing
this as the decorative image. I’m about to show how we can implement this as a decorative
image. So let me go over to my text editor. Let’s fix our color contrast issue first.
I completely cheated for  to make this go as quickly as possible, and I put a CSS comment
of the actual color that the wireframe had that was 00853e. I’m going to hit save. Let’s
fix the decorative issue as well. Here is the source code. This is a react app. Doesn’t
matter if you don’t know React. Image tag with source attribute of the recipe.image,
but I didn’t do anything else to tell assistive technology or the accessibility tree this
is a decorative image. So how I do that is adding an alt attribute with a value of empty
strain. Alt=”,” or role=”presentation. I still can’t spell. This is perfectly fine
accepted way. I’m going to hit save. Cool dev server autoreloaded the page. That was
fun. I’m going to hit analyze again. Hey, we are #AxeClean, everybody! That is awesome.
Doesn’t mean testing done. To recap what we fixed, we marked these images as decorative.
We can see what that looks like in the rendered dom. We also darkened this green color. So
now we actually have sufficient color contrast that exceeds 4.5:1. I want to take testing
further with a friend I call Axe Prop. Let me log into Axe Pro. And Axe Pro is an app
built on top of Axe and the bread and butter are the guided tests. I want to focus on those.
Guided tests are intelligent tests that will walk a user regardless of their accessibility
expertise  this works even if you’re a novice and really new to it. I highly invite everyone
new to the game to check out the free tool. It’s going to ask a series of simple yesorno
questions and do the heavy lifting of accessibility issues based on that. All right. So I’m going to start with the
page information tool. This is our by far the most simple tool. It’s a total of a maximum
of two questions. And it’s going to… so back story here is I just opened up the app
again and now I’m back in the test page. I forgot to mention when I was saving my results
I’m in the web app, a separate tab. Back in the testing tab I’m going to hit start. Right
away it’s asking me the page title is, in quotes, insert title here. Does it accurately
describe the purpose of the page? Looks like Harris is bad at his job and forgot to replace
the template stream in the title. So insert title here is not an accurate document title
for this app. So I’m going to say “no” to that question. Now it’s asking me, is the
majority of the content on this page in English? What it did under the hood, in case anyone
is curious, looked at the HTML lang attribute and saw it had EN, it’s saying, is this, in
fact, accurate? And, yes, this page is in English. So in less than a minute we were able to find
our title issue. The reason automation can find that is because I actually had a document
title. It had a valid value. It can say, hey, you’re missing a title. Robots have no way
of knowing that’s not the right title. That’s where awesome human brains come into play. All right. So we just finished page information.
I really like the vibe that the Axe Clean got me, so I want to be Axe Pro Clean. I want to fix them on the fly. Before we move
to other testing, let’s fix this issue to validate we fixed it. All right, so here is
my index HTML file. There’s where my terrible title was. Here is where I’m going to write
in “awesome recipes,” the name of our app, a pretty descriptive title. So I’m going to
put that there. And what I’m going to do now is clear my previous run’s results and run
it again. Run another lap. So back in the test tab in
the axe dev tools panel, now it says does it accurately describe… yes, I did it. Still
in English. I spent five seconds testing and validating and I have, in fact, created an
accessible title. Hooray! So a trending hashtag today, I have a good
feeling about that. That’s all fine and good and I think that was really cool, but we really
focused, if you remember, on this recipe card. And I’m a developer and I don’t like reinventing
the wheel. I like componentizing stuff. Since I’m familiar with this code, I know that all
the recipes we’re mapping over an array of recipes and rendering a card for each of them.
They’re rendered the same way. To speed up testing, I want to test one card to make sure
that they’re all accessible. So what I’m going to do is showcase probably
my favorite feature of Axe Pro. We call it scoping, but really what that means is we’re
doing componentized testing. It’s going to allow me to isolate my axe core test, automated
test to just a specific element on the page and also isolated that element for all the
guided tests as well. I’m going to hit change scope, and now it tells me to choose the part
of the page that I would like to test. And similar to a lot of dev tools experiences
when you can do the pointandclick to inspect an element, in Chrome that is called… what
did they name it? Select element in the page to inspect it. So I can use a pointandclick.
This is great, click on an element, but not everyone can use a mouse. We went ahead and
created a mini dom here in the bottom of the actual Axe UI that allows keyboardonly users
and assistive technology users select elements, which we’re proud of. And it notifies the
users of vital information so they can accurately make a selection. I just selected my recipe
card. I’m going to confirm. Now I hit analyzing because I want to run axe and see what happens.
We have axe clean again in just this card. Not a surprise because the whole page was
axe clean. Let’s go ahead and save results. Same thing. You notice actually this time
we prepopulated the field with the accurate document title, just because that’s usually
a good way to name your test, and before I kind of glossed over but it prepopulated with
insert title here. I didn’t want to spoil anything. We’re going to name this recipe
card to tell myself, my future self when jumping in to testing what I tested here. If you don’t
like that convention, you can add notes. It’s like… Harris, find the source code in source/components/recipecard.js. Leave a note for yourself. But now we save the results and we have this
componentization set up. What I want to do is run some other tools. Page element was
good, structural look at our app, but now that we’re looking at the specific recipe
card, I want to run through our images tool. Really cool tool. It’s just going to basically
walk you through all the images in the chosen scope. In this case the recipe card, the chocolate
cake one and it’s taking screenshots right now. Okay, do that and it’s done. It went
ahead and found four images inside this one recipe card. The two that I’m going to ignore
are the  if you remember the focus and hover indication of this cook button has the little
brackets, those are hidden so I don’t really feel like testing them. I’m going to focus
on these two buttons here, the two images here. The chocolate cake image itself. Remember
we said it was decorative. As well as the edit button, a little pencil icon, an image.
So I’m going to hit next. It’s asking to select all the images used solely as decoration.
Rule of thumb is if you remove the image from the page, would important information be lost? If “no,” then it’s decorative. We decided
from the start, like I said, we documented it here, we made the decision early on, so
this is an easy question for me to answer. But given that we said  we annotated the
pencil icon with an accessibility name, that means it’s informative. We needed to convey
something else here. On top of that it’s an active image, is that it’s an image inside
a clickable element, so that always means it must be informative. All right. So now it’s asking me to select
all the images other than logos that contain text. WCAG has specific criteria with images
with text, so we need to ask the question really easily. In this case we do not have
text. So I’m going to go next, and now it’s having me validate the accuracy of the accessible
name. So it’s asking me, does the accessible text tell you what the image is for? Accessible
text should actively describe what the image is and what it is for. So edit… yeah, edit
sounds good, right? Let me just check. Oh, no… right, right, right. Hearing edit over
and over again isn’t useful. I want to know which recipe I’m editing. We decided from
the start, the design phase, shifted left, we have accessible name of edit and chocolate
cake is what I expect to see. Harris is really bad at his job, completely overlooked that
part of the wireframe… shame on him. Let’s answer that question as such. All right, so in that couple minutes we were
able to test all the images in my component, my recipe card and it looks like we have a
bad image  a bad alt text here. I’m going to hit finish. Hooray! We have one issue found for images. I forgot
to mention in this web app, the expert web app, you can view issues just like the extension,
same kind of thing. Shows you the select, recommendation to fix, description of issue.
But in the spirit of #AXEProClean let’s fix this issue. Back in source code I found the
element, the culprit here. Their alt text is edit. If you remember, it’s edit followed
by recipe name. I’m going to do a new template screen. Each recipe is an object and has name
property, which is what I want here. Edit and recipe.name. And save again. And moving
to see if that worked. So let’s go back through the guided tool.
Images. I’m going to blast through this for the sake of time. And select the same two
images, yadda. I’m going to say the chocolate cake is supposed to be decorative and the
pencil is still not. And the pencil is not a logo. Here we are. Here what I’m looking
for. The accessible text it found was edit chocolate cake. Now I can answer yes to this
and presumably, yep, there it is, no issues found in less than a minute. I’m going to
# AXEPro images tool clean. That’s awesome. I want to do the button and links tool. It’s
cool. It will walk you through testing of buttons and links, as it sounds. Let’s do
that real quick. All right, let’s get it started. I hit start
again. And it went ahead and tried to scrape all the buttons and links from this component.
One thing that stands out is it only found one. This tool must not know what it’s talking
about. Because we totally said this thing is supposed to be a button, this pencil icon.
Actually on click it invokes edit mode. So I think this tool is missing something. Yes,
I can see some button link elements that you did not highlight. Once again we use the same
element selector I used to choose the scope to choose the edit button, so I clicked on
that. And I’m going to hit next. I just told the tool, hey, this is supposed to be a button
or a link. And now similar to image tool requirement we need good alt text images. We need good
accessible text on controls like this, interactive controls. You can’t have a button or link
with no text, so it’s important the text is there but also describes the purpose. The
question we look at now is does the accessible name of each button link element accurately
describe its meaning? So for the pencil icon it says edit chocolate
cake. If you remember we just fixed that issue. So that fix actually propagated up to the
accessible name calculation of this button. So I’m going to say, yes, that’s perfectly
what it’s supposed to be. And accessible text of the cook chocolate cake button is cook
chocolate cake. I’m going to say, yes, that’s accurate. Now, beyond accuracy of the accessible name
we want to insure accuracy of the role. So having me review the calculated role of each
buttonlike element and ensure accuracy. It went ahead and tried to figure out what this
should be, since a plain old dev if you can remember, it’s a div with on click. Shame
on me for doing that. Doesn’t know if it should be a button or link. This is where the human
brain comes into play. This should be a button. I’m going to prepopulate the chocolate cake
button as button. It’s marked up as such. So only one problem here. So I hit next. And
we have two issues with this. We have the fact it doesn’t have a role and then actually
it’s not accessible to assistive technology, not a tab stop, not even clickable with a
keyboard. We have two issues surrounding this one major problems. I’m going to save my results
and figure out what I did wrong. All right. So I used a div instead of a button. That
was really silly of me. I want to point something out though. I talked about utilizing accessibility
automation. That doesn’t mean just some JavaScript on the browser. That can be static analysis
of your code. So a common thing in programming is linting your code, which is really just
analyzing it and find obvious problems with it. There’s also some awesome accessibilityspecific
linting that can take place. This isn’t just specific to React. There’s static HTML linter
that will tell you, oh, an image without alt. I will show you what happened if I didn’t
override this in order to do this demo. It disabled the no static element interactions.
Right away if I didn’t have that disabled, which I usually don’t, it would yell at me.
Because it’s like, hey, you’re adding interactivity to this div you need to use the right role.
But I turned it off for the sake of the demo. Change this to a button. That makes more sense.
Recap the button with an on click that opens our modal presumably and the child image with
the right alt text. So hit save and see if that gets me through to #AXEToolsButtonsAndLinks guided. Once again I hit start and this time this
is really promising. We highlighted the two buttons and links we found. And so this time
it actually found my pencil icon as a button. I’m going to say, nope, nothing is missing.
Good job. I’m going to capture screenshots really quickly and the accessible text is
still the same, nothing changed there, so it’s still accurate. But the important part
here is we actually have a slight change here. When reviewing role, its actually prepopulated
the pencil as a button. So there’s nothing for me to change here. So both actually marked
up as a button is what the tool is telling me. And then I hit next and I’m on the results
page and I have zero issues, and I’ve done that in less than a minute. So that’s what I had today, is to demo Axe
Pro, to give you a taste of what the guided tools can do. And let me go back to my slides.
And, yeah, I just wanted to say thank you for joining. I am Harris Schneiderman. I think
we’re going to share the slides, I am @TheHarrisius.>>SCOTT: Hey, Harris, that was pretty intense.
I enjoyed that a lot. And a lot of conversation happening in the chat room right now.>>HARRIS: I had to ignore it to stride through
it, but I see 233 unread messages.>>SCOTT: Yeah, well, there will be a transcript
we can go through at some point. They’ll share that with you guys, if there are any outstanding
questions. So I am just going to in the Q&A box here…
we had some questions come in.>>HARRIS: AT is assistive technology. I just
spilled through and saw I did not explain that. I apologize.>>SCOTT: All right, that knocks two off the
list. What is an accessibility automation library?>>HARRIS: That can be  I mean, we kind of
use that as a blanket term. Axe is an automation accessibility library. I would say the linter
is a form of automation in accessibility, but it’s really anything with code, meaning
no human interaction will analyze a page for accessibility. Or in this case  in the case
of linting, code.>>SCOTT: Yeah, everybody is requesting an
invitation for the a11y Slack channel.>>HARRIS: Oh, yeah. Reach out to someone
you know who is in the channel or myself and we can get you invited.>>SCOTT: Cool. I’ll do that. Ricardo Z asks… why 56 pixels?>>HARRIS: Minimum target side. 56 probably
arbitrary, the designer thought the control should be that large. It’s just as arbitrary
on how wide that tile was. The important thing to note is exceeded 44 X 44 CSS pixels, which
is a requirement given by WCAG.>>SCOTT: Fair enough. Steve would like to know, how do we include
users with disabilities into our projects? Is there a network we could reach out to?>>HARRIS: That is a good question I don’t
have a good answer for. Maybe we can do a followup. We’re really lucky to have at Deque
a ton of resources that uses assistive technologies with various disabilities so we can usually
leverage that. So reach out within your company, if you have a large organization it’s a good
chance you have users with disabilities, even if it’s colorblindness or blindness or motor
impairment, but I’m not aware of a specific network. So maybe we can get back to you on
that one.>>SCOTT: Okay. Steve also asks, what systems
do you recommend for such detailed annotations?>>HARRIS: Ooh…>>SCOTT: Looks like as many layers to detailed
annotations it could get unwieldy quickly.>>HARRIS: It was quite unwieldly when I presented
it because we looked at the same recipe card like six different times.>>SCOTT: And may be very hungry by the way.>>HARRIS: It’s lunchtime on the west coast
and I’m starving.>>SCOTT: It is.>>HARRIS: I found those annotation key things
on the a11y Slack channel and sent them to the designer. I’m not a designer, I was hoping
maybe he would be on the call, but he uses UX10, which we just started two>>SCOTT: US bin?>>HARRIS: It has a simulation mode so the
designer cannot only document interactions but they can actually make actions happen,
which is great, because then a developer can pick it up. I will say that the code that
it generates isn’t necessarily accessible though, which could be a problem. But, yeah,
I think most of the design systems out there support you importing custom annotations in.
So I’m sure Google would help you out there.>>SCOTT: Okay. Could you point us to the
Slack channel that you mentioned. Hot topic of the day.>>HARRIS: Slack, it’s awesome. We’ll send
out a link after this.>>SCOTT: Okay. Oh, so Diana Nichols is asking
how she can send the ondemand… this ondemand to a coworker. Sorry about that Diana, but
we will be posting the video to the Smashing magazine YouTube channel once we’re done. Messages are going pretty quickly here. Does the image testing tool recognize SVG
and further than that files in line basics before?>>HARRIS: Oh, yeah, thank you for touching
on that. I completely jumped over that. Yeah, it detects image tags, which include basic
4 images, SDGs and background images. It makes a hard attempt to detect ligature fonts. We
try to catch anything that can be interpreted as an image.>>SCOTT: Okay. Lisa… I’m horrible with
bad names. For tab annotation how do you annotate it if pressing a button adds content which
is focusable? For example, a popup menu or accordion section with links?>>HARRIS: I would probably separate and do
like a wireframe with the structural page wide tab order and then in your comp or wireframe
for the specific dropdown menu, whatever we’re talking about here, have the tab order within
that mapped out, so the developer can infer, okay, if I don’t activate it with tab order,
but if I do within that component will have 1, 2, 3 and presumably back outside of it
for the rest of the dom. So I tried to separate those two. And maybe in the ticket where you
pass to the developer you describe that.>>SCOTT: An anonymous attendee… could you
talk about some of the elements besides modals that would also require circular tab order?>>HARRIS: Ah… that would require? I’m not
sure how many require it, but tab panels I’ve seen implemented with circular arrow key order,
same with like ARIA menu. If I hit my tab… I have four tabs that say I get to the first
one that is active and hit the right arrow once, twice, third, and back to the fourth
one, on that fourth one I actually will cycle back to the first tab. And the same thing
with like menu items, I’ve seen that. But as far as trapping focus like that, it’s really
just dialogue elements.>>SCOTT: Okay. Is this information applicable
to websites and apps? So we mainly spoke about website here. I’m assuming… but it’s always
wrong to assume. Do the examples you were showing work within apps as well?>>HARRIS: So the Axe Pro won’t but a lot
of principles do for sure. If you’re talking about mobile apps, there a whole different
API how to implement that, so instead of me setting arialabel, we set accessible text
property or something. But a lot of modern like desktop apps are running some kind of
chromium or chromium like thing. So that means you can incorporate accessibility automation
into the building of those apps. So kind of the answer is yes and no. Axe Pro itself won’t
work with a mobile app.>>SCOTT: I kind of assumed because it was
a whole different set of accessibility tools within Android, iOS.>>HARRIS: Right.>>SCOTT: Adam Height is asking who is responsible
for annotations, is it a group effort? Should annotations go on wireframes or actual designs?>>HARRIS: Good question. I don’t think there’s
a right or wrong answer there. It really depends on your team. My designer that I work with
a ton he leans on me for a lot of the accessibility stuff. So I’m kind of the goto expert for
him as he’s still ramping up, so that kind of goes into the collaboration. So if you
have an expert that is not on your team, you incorporate them in that design phase and
says, hey, what is the purpose of the thing, what should I annotate and things to look
out for? But it’s definitely not on the designer to do that. I would definitely incorporate
your whole team in the process. And I think the annotations can be on anything. You don’t
even need to necessarily document them as annotations. If it works better for your team
you could have a separate issue, GitHub issue or a Jira ticket that describes the things.
A side bar documentation where you hover and highlights the associated UI that the documentation
is for. But overall I think just in something like a design review, if you’re a scrum team,
that’s a great time and place to at least refine the annotations or add the accessibility
specific ones with the whole team involved. That will really, like, open the developer’s
eyes up to what they’re going to implement in the future and get them up to speed on
accessibility requirements.>>SCOTT: Just a side note here, Andrea from
the Twin Cities mentioned a company called the… THEWECO accessibility readers, and
they will do  I’m not sure if it’s limited to companies in the area or not, but sounds
like they do free review for people too.>>HARRIS: Nice.>>SCOTT: I’m sure there are people looking
for services that would be more local, that could be helpful with that. Justin is asking
are the graphics and iconography used for annotations available?>>HARRIS: Yeah, let me ask the designer to
send them to me. I don’t have them on hand, but maybe when we send out a followup with
the Slack information we can send those with them.>>SCOTT: Yeah, I’m sure we can…>>HARRIS: I may be able to dig up the original
Slack message where I found them. They by all means are not original ideas.>>SCOTT: There’s still quite a few questions
that we can… if we can’t fully answer now we can probably send a group email to everybody
that registered for the event. Can you share a recording of this session?
Yes, again, this is going to be posted on the YouTube channel once we’re done. What
was the name of the VC code a11y you used?>>HARRIS: Yes, I used>>SCOTT: Is there one you recommend and not
for JS6.>>HARRIS: Oh, I don’t know it… shoot, we’re
working on stuff with winters. I used an HTML one with accessibility. I don’t know it off
the top of my head, though, I apologize. I know there’s a view one, there’s an angular
plugin. So there’s actually… there’s even linters for markdown files to ensure that
your documentation if you’re using markdown is accessible. Cool.>>SCOTT: Yeah. Bruce is asking, when the
Axe Pro evaluation is complete, does it generate a report or PDF that can be exported as evidence
for WCAG ADA compatibility?>>HARRIS: It’s not like a full VPAT, if that’s
what you’re asking, but you can export the issues in a CSV or JSON format, which is usually
importable by any kind of issue tracking, but it’s not like a pretty PDF report at the
moment. All it is is the raw issue data of the violations. But it will tell you which
are automated, headings tool, image tool and so on.>>SCOTT: What is an example of an empathy
event? From Monica.>>HARRIS: There’s  we’ve held some empathy
labs, which will  I’m going to butcher this. I’m not an expert, but what they really are
are a series of stations that simulate various disabilities, simulating tremors how to scoop
up soup and how technology will counteract tremors, and stuff like trying to trace through
a maze in a reflection of a mirror or putting on goggles that might obscure things. So it’s
really a lot of attempts to simulate different types of disabilities.>>SCOTT: Okay. Lisa is asking, is Harris
referring to CX pixels when he talks about the WCAG minimum size, what does that mean?>>HARRIS: Yeah, I think  I have it in notes,
but I was in presentation mode 44X44 CSX pixels is how WCAG describes it. CSX, yes.>>SCOTT: How do you recommend managing the
focus color when using multiple browsers, just using the native one is the best idea?>>HARRIS: Native, I believe, is compliant.
If you… if your designer is excited about it, I recommend taking a look at the various
background colors that you might have and choosing a color that will contrast with all
of them. If you want to get fancy and use a nonstandard one, we do use the nonstandard
one at Deque, it was part of the pattern library, it was actually that pinkish purplish green
we saw in a few of the comps. But my overall recommendation, yeah, if anything, anything
that is Bert than nothing, so a lot of designers like to say… no, put outline zero and port
and done and everything. I don’t want to see ugly outlines, that’s not acceptable. That’s
an issue. So at the very least use a browser default.
Nothing wrong with that. I do know in early IE browsers, the focus indication with really
hard to tell. It was one pixel dashed or something. So if the designers want to get creative,
I totally invite them to because it creates a better experience for everybody.>>SCOTT: Another question here. The annotated
wireframes that were spec for PX with a height images and buttons, are those the minimum
measurements? Okay, this is… yeah, minimum measurements
since we never know what device a user is going to be on.>>HARRIS: Yeah. The designer will usually 
like UX pin he’ll take the design and show it what it looks like in our default view
port size and think it’s 750 pixels, let’s say. We also have a mobile view of that same
component. So in the case of the cards, we might document stuff like, hey, make sure
that flex  the flex wrap wraps around a new rows and maybe shrink some stuff down and
we did kind of do converting of wireframes. We usually annotate with EMs or something,
not pixels for that kind of  so it makes scaling  graphic scaling a lot easier.>>SCOTT: Okay. Miles is asking if Axe Pro
will be available for Firefox when it’s out of beta?>>HARRIS: I’m not 100% sure. The thing that
our team is focused on is seeing how we can make a useful tool, and so right now it’s
in beta. We want all the feedback we can get. If the feedback is great, yeah, definitely
a chance that we’ll ship Axe Pro with Firefox and Edge support in the future, but right
now we’re trying to gather information and see if it’s a viable proximate cause.>>SCOTT: Okay. Your cards visually have edit
button before heading for the card. How do you keep people that jump from heading to
heading from missing the edit button?>>HARRIS: A good point. It’s been brought
up before. One could argue that maybe you could use absolute positioning to actually
in the dom and the reading order make that edit button below it. But since we included
the accessible text of the recipe name in it, we’re not causing any confusion at least,
but maybe one could argue that was a mistake and could be enhanced by having the headings
show up above the edit button and reading order. So a really good point.>>SCOTT: And lastly, from the attendee questions,
does this direction change at all when using a design system with accessibility included
in the web components?>>HARRIS: Does what instruction?>>SCOTT: Does this direction change at all
when using a design system with accessibility included in the web components?>>HARRIS: So which direction, the tab order
or the…>>SCOTT: I’m not quite sure. If you’re still
here, Cameron, maybe you want to expand on that.>>HARRIS: Sorry. But Sophie says we can  oh, the best general
practices.>>HARRIS: Do they apply to design software
that has accessibility in it?>>SCOTT: Yeah, if you’re using a certain
set of components that already have accessibility built into them, do they change at all?>>HARRIS: Ah… kind of like my point about
pattern libraries, right? I actually glossed over  I’m sorry if I’m not answering this
properly, but the  having a toolkit of components in form of pattern library, it’s less annotations
to make for devs when you reuse those, initially for a new component I’m going to be handed 
let’s say I’m going to be handing that  I’m going to write in a modular generic fashion.
So any time we use that in future the designer can say use the recipe card or the card component
for this. Maybe variations that we support, so maybe we kind of  we iterate like that,
we implement a component in the minimal form for whatever we need and if new requirements
pop up, then we’ll try to see if we can pivot that component to support both use cases.
So you kind of are always iterating on them, but it’s definitely a shortcut to have stuff
built already with accessibility, so it’s less manual testing to be able to do that
is less annotating you have to do, so really just speeds up the process.>>SCOTT: Another question that just came
in from Christine Kowalski. I am working on a product and SEO consultant wants us to repeat
the paragraph of text next to an icon image in the alt text of icon image and also repeat
to the related H3 tag. Is this good practice or is this key word stuffing?>>HARRIS: Keyword stuffing for sure. So that
icon, if there’s already adjacent text near it, that is the same, then I would just ARIAhide
that icon if not serving a purpose. If it’s clickable, maybe give it in a summary accessible
name, but don’t put a whole paragraph worth of text as a label for a button. And then
don’t stuff more text in the heading, because AT users, as someone mentioned earlier, can
navigate by heading. So like on VoiceOver it brings up a rotor menu of all the headings
and seeing a giant paragraph of text is not going to tell a user what that section is
all about. They have to dig through that information to find out.>>SCOTT: Yeah, in general, this being honest
about your content is rule number one as soon as you start trying to hide text and stuff
in other places, there’s a chance you might even get penalized by the search engines.>>HARRIS: Good point.>>SCOTT: That’s a whole other thing. Shane
is asking how long do wireframes normally take to make?>>HARRIS: Ahhh…>>SCOTT: It can vary a lot.>>HARRIS: It can vary a lot. A lot of designers
don’t know. By no means can you slap it together in a day. It’s very iterative. So maybe you
come up with an idea, proof of concept, maybe a paper prototype and you’re doing some usability
testing with it, and then move on to the wireframe stage, but I actually don’t know on average
how long it takes designers to do that, because I’m not a designer. I don’t make wireframes.>>SCOTT: Fair enough.>>HARRIS: I consume them.>>SCOTT: Well, that’s it for the user questions.
Vitaly has some questions here, but I have a feeling we probably touched on a lot of
them already. I was going to quickly open them up here. So in regards to your workflow, how do you
maintain accessibility over time? Is there any tips on how you can integrate that into
your daily workflow to kind of make it just second nature?>>HARRIS: Really good question. I’ve tried
to touch a tiny bit on that, but let me explain a bit. My point about treating accessibility
defects like normal defects, don’t separate accessibility defects from normal ones. Don’t
let them sit and rot in the backlog. Prioritize them like real defects. A lot of times accessibility
issues are real blockers. One can argue they should be a higher priority than some other
minor defects. And so you also should be incorporating like
I said CI checks or some kind of automation where you can ensure at least some minimal
accessibility has been implemented before you even push in code. That’s a great way
to easily catch issues and prevent them from even leaking into your dev server, and I think
what we covered today is great example of how you can maintain accessibility over time,
if you’re thinking about accessibility in the design phase, you’re setting yourself
up for success already. So what I would say regarding your ongoing point about like…
you know, it’s a project that already has started, what do we do? We want to start thinking
about accessibility. Maybe perform an audit on it so you gather all the existing issues
and triage them, and prioritize them like we were talking about with defects, and track
progress on them. Maybe you can say we have been able to knock out seven accessibility
issues per sprint while not creating new ones. Let’s create a goal to have zero issues by
next quarter or something. That will help you kind of come up with a nice process for
your next new project to be accessible from the start.>>SCOTT: Okay. If possible, ARIA should be
the last matter of resort. HTML should be good enough to make things accessible. Can
you explain the role of the web content accessibility guidelines as opposed to ARIA.>>HARRIS: Yeah, so the way I think of WCAG
or the Web Content Accessibility Guidelines, those are really just rules, right? So the
44X44 CSX pixels, that’s a rule. AA 4.1:1 contrast ratio, that’s a rule given to us
by WCAG. ARIA is a set of techniques to follow those rules. So ARIA will map out various
attributes that will be consumed by assistive technology in order to create that accessible
experience that those rules are telling us to do. So they definitely play nice together
and a lot of times to the initial point, a lot of times semantics works better than using
ARIA. So that’s like you know, to really draw out a watered down example would be don’t
use div class button or role button, just use a button. You get a lot of stuff for free
and there’s a lot less for you to maintain there.>>SCOTT: Most importantly, because we never
got a chance to ask it at the beginning, but are you a cat person or dog person?>>HARRIS: Well, it’s perfect I chose this
picture on my ending slide. I’m a dog person. We’re looking at my cute boxer named Ophelia.
I don’t have anything against cats. I’m mildly allergic.>>SCOTT: We’re allinclusive over here. Good
to know. Well, yeah, thank you very much, Harris. It
was a pleasure to kind of see this in action for once. I just want to let the attendees
that are still kicking around, if you are a member and you want to review this or look
at it later, it will be available on the Smashing membership panel but we’re also going to put
it out on YouTube once we get the captions married up to the recording. And then we have another webinar coming up
with Paul Boeg on the 28th of November. Encouraging clicks without shady tricks. So Paul has been a long time of part to have
Smashing family and done conferences with us and a pretty fun guy to watch. Hopefully
we’ll see everybody there. On that note, Harris, have a good rest of your day.>>HARRIS: Thank you. I’m scrolling through
the chat, and there are so many cool resources everyone is sharing. This is an example of
what the accessibility community is really like. Thank you.>>SCOTT: And I will try to see if we can
get a followup with just a couple things people are asking for sent out to an email to all
the registrants later.>>HARRIS: Perfect. Appreciate it.>>SCOTT: Thanks, everybody, for joining today.
Thanks again, Harris. Have a good day!>>HARRIS: Cheers, everyone!

Tags:, ,
2 Comments

Add a Comment

Your email address will not be published. Required fields are marked *