Rethinking Accessibility: Role-Based Analysis of WCAG 2.0


>>Bill Tyler: Okay,
thank you very much. For everybody out here, to make
things easy, it may be difficult to see in the back of the room,
or maybe you can’t see it. There it is, a link at
the bottom on Bit.ly so that you can download the
slides, so you don’t have to take pictures, and you
got links that you can follow without having to try
reading and squinting. And the link is Bit.ly,
which is B-I-T.L-Y/2HJea3e. So that’s bitly/2HJea3e. And before I get going,
there’s a few things. One, I’m going to
be wandering around. So apologies to the camera
crew, because I’m going to wander around,
because I don’t like being trapped
at the lectern. Second, for our ASL
interpreters, I talked fast. So it’s going to be
difficult to keep up. So I apologize in advance, but
if you can download the slides, you’ll be able to check it while
I’m presenting and later on. So, as you said, I’ve been
doing UX and UA by design since about 1984,
when I got religion about things need to be usable. I’ve been a double
dot-com survivor. My first half of my career
was in medical devices and implantable drug
pumps, pulmonary and exercise stress equipment. I’m a double dot-com survivor. I have also, for the last 16
years, been working for plans and providers, such as
my current employer, optimum technology, but I worked
for Blue Cross in Minnesota, and I’ve been doing
web for about 22 years. My accessibility experience
started in about 2002, and I’ve been full-time
in accessibility for roughly 4-1/2 years, and
what you’re going to see is some of the stuff that
I ‘ve been doing for analysis about
accessibility. So let’s dive right in. There is a problem with
accessibility, and it’s the way, and you had already
heard in the summary, is it’s all on this slide. The usual approach
to accessibility is that no one thinks about
accessibility except people like myself, and I’m
sure, many of you. You’re the accessibility expert. You know this, but no one
else does, and it’s because, as again, oops, I say the
accessibility comes at the end of development by testing,
by people like myself and you that says, ooo, no one
else knows how this works. We’ve got to call
in the experts. Then it’s all found at the end,
and we send these questions or these fixes to the developer,
and they need our help, because again, it’s magic. It’s some sort of pixie dust
that we sprinkle on your code to make it accessible for all
the people with disabilities. And again, it’s a sort
of an accessible result, because there’s been
compromised. You did at the end. There’s no time to get it right. No one has the budget to
redo it, and it’s like, oh, that’s just going
to be too hard. We’re going to go
to market with this. And if you think about it, if
the people that are involved, or the roles, which is going
to be what we’re talking about, it starts with a business owner, the person who has something
they want to go to market with, some product that they
need, we will talk to an interaction designer. If that term’s not
familiar to you, that would be your user
experience engineer or your usability professional. These are the people that turn
those initial vague requirements into specific requirements,
and we’ll talk about that in more detail. You get the visual designer. That might be your URI designer, or the person who’s
looking at presentation. Then you got the content author,
the person who puts all the text in there, and finally, we
insert accessibility right down in here. We go from the developers
to, you know, it goes from the content author
to the developers, and we cycle. This is the way most
people approach this, because like usability
was 30 years ago, it’s one of those things you’re
supposed to do at the end, because, well, that’s
the way it works, right? You just change at the end
and make it accessible. Obviously, that doesn’t work. So we’ve got to find some
other way of doing it, and when I looked at this,
especially what I was going through WCAG and analyzing it a
few years ago, I started seeing that the fun about it
is the assumptions, and the assumptions are, again, the way I described the process
is that developers do the work by coding accessibility using
accessibility-specific knowledge at the end of the process. So we need to question
those assumptions, and that’s what I started
doing, and that starts with some basic questions. Who? That’s — sorry,
moving a little fast. Who owns and makes the decisions
that affect your WCAG criteria? And I’ll let you take a
moment that when I’m talking about success criteria,
I’m going to be talking about WCAG II, AA,
and A criteria, with are 38 criteria
you need to meet most of the accessibility
standards that we see today. So we’re going to
know who owns it? And the question really
is, is it the developer? That’s what we assume it to
be, but is that appropriate? Then when? We’re trying to wait
until it’s coded. Is that the right time, when
these decisions are being made? And is it really
when the coding hits? Last, what? Is this accessibility magic? Is it something that’s
accessibility specific? Is that the nature of
these sorts of things, or is it something else? Oh, I see what’s going on. So, let’s start with
that first question, who? The thing we’re going
to do first is deal with what are the roles
that are not involved. I’m going to show, you know,
seven roles on that one slide, and the two that don’t make
decisions are those of us who would do testing, and
what we’re talking about is in accessibility engineer
or a tester like myself. You’re the subject
matter expert. You’re the one who knows WCAG. You’re the one who has to
understand assistive technology. You’re the person that
has that key information, and in that role, you
typically teach other people how to pick colors, how to write
text, how to make things work, fix out ARIA and other things
in the world when they try to make them accessible,
and that last part is that you’re the one that
deals with the tough things like I don’t know how
this works with JAWS. Or how do I make
that control work with Dragon NaturallySpeaking? And of thing that I’ve
also found myself in, because no one understands
this work, you get to be the
user-acceptance tester at the end, because no
one else knows whether or not it’s accessible or not. A key team member you can
find is the QA tester. They’re the people
that do all the issues. They’re the ones that test it against the standard
requirements. They write up the defects, and
the Q is for about quality. They they’re the
ones that enforce it, and they’re the last stop
before release, well almost. And they’re not familiar
with accessibility. But, if you get good testers, you can teach them
how to do this. You can also include
your automated testing into their automated testing. So if you work with
them, you can get a lot of the support from
them, as well. But these are not the roles
that are making the decisions. These are the roles that
are making decisions. The other five folks,
and we’ll talk about them in a little detail. We start with the
business owner. If you’re familiar with agile, the business owner
is a familiar role. That’s a standard agile role. That’s the person who
initiates the product process and sets some requirements,
defines those, and when it’s all done, says,
yes, that’s what I wanted. You did it right. The interaction designer
is the person who talks with the business owner
and is the liaison, takes those rough requirements
that say I need something that does this, and turns
it into a set of wireframes or requirements,
that a developer and other roles can handle. That includes, as
said, wireframes, and this person should
be familiar with user-centered design,
user experience, and usability. That’s their expertise. Next is the visual
designer, and when I talk about a visual designer,
that’s the presentation owner. You know, what it looks like
and that’s the style expert. The person who takes the layout,
takes those rough wireframes, makes it look professional
and looks, you know, the way people are expecting
it for that particular company, and that usually is
enforced with a style guide. They write the style guide. This is how the entirety
of the site should look. These are our brand colors. This is the color
palette you use. The fonts are going
to be like this. And because they’re doing
all of that for the site, we need to look at
it for exception. So when I say design comps
here, the artist, that’s the one where we say, okay, we’re
making a custom feature. We need to have this. So there’s a page
that’s different than what we currently styled,
because everybody’s innovating. There’s a new feature I
need, and I need to present that in a different way. So I don’t have that
covered in my style guide. I will do that as a design comp. And when they do all this work,
they produce the image files. So they’re the persons
or role that those that. Next is content author, and
that’s the person who is in charge of all the
content, large and small. Large is the big legalese
that you might see. Privacy statement,
terms and conditions, the long-winded text, you know, something like the American
novel that’s all online. It also is the tiny text. It’s deciding is the standard in
your company sign in or login, so that you’re consistent? And it can be also
things, do I say play? And/or do I start? Do I say pause or stop? Somebody who’s enforcing
the writing standards. They also do content
proofreading, because they’re usually the
ones who pay attention to this like whoop, that’s
a misspelling. That’s a typo. A key thing that we’ll
talk about in this role is that includes the
time-based media. Because if the video or your
audio has been prepared, if it’s not extemporaneous,
it’s not something that is done on the spur of the moment, it’s
not just pointing the camera out and see what goes
past the window. Somebody wrote a
script for that. Somebody wrote the
press release. Somebody did something that was
scripted, and that’s still part of the content author role. And so, there’s a
scriptwriter and, just like with the
visual designer who produces the image
files, that role is in charge of the files for
the audio and video. So things like closed captioning
for the supplementary script, that would be part
of what they do. And last, when I talk
about a developer, I’m talking about the
front-end programmer. The person who is doing the
last work, taking all the input that came from the
left and turns it into the deliverable product. That’s the last stop of
our testing and, as I said, they are the ones who
deal with all the defects, because it’s always
a coding issue. Now this isn’t original work. A lot of people have done it. Here are some examples. The first one is Accessibility,
Responsibility Breakdown by Denis Boudreau,
and as I said, we’ve been working with him. You’ll see his name
show up towards the end, but he did it against 12 roles. There’s also some other
groups like Interactive WCAG from Jeremy Fields had five
roles, and there is an article about two years ago
in Simply Accessible by Mark Palmer that
had six roles. And if you download the
deck, you can see the links that should still work
to get to the sites. The difference in
the way I did this is that we had decision ownership. It’s not just that these
roles are involved, but some of these roles
actually own these decisions. It’s not just that
they’re impacting it or that they’re involved, but that they actually own
these sorts of decisions. They should be constantly
involved, and to do that, we’ve looked at the levels, and
we’re going to be talking about, in a moment, RACI,
R-A-C-I, modeling, and that’s where we have
levels of ownership, and we also did some
additional analysis. So we looked at just
beyond ownership, some of the other things that
answer the other questions. Last is that we want to make
sure that this is actionable. We’re not dealing with somebody who just said this
is a nice idea, but we want to incorporate
it into the processes, so that we get that a
more accessible result. So I said R-A-C-I for RACI,
or, in this particular version, RASCI, R-A-S-C-I modeling,
and that the traditional way of doing is R for responsible. The person who owns the issue. A is for accountable. They’re responsible
to the owner. Supportive is the next level
down, which is not accountable but it’s still helping
do the work. Consultants are somebody
that’s there to consult about the issue, but probably
have even less involved than supportive role,
and then informed. Somebody just says,
Yep, they got this done. That might be more like
your program manager or a scrum master, who’s
just making sure things are happening. The model that I’m using in
this discussion is three-part. You have a primary
owner, the person who has, or the role that has,
the final approval. The person who has to sign off and say I’m responsible
for this. This is correct. It goes out. Secondary are people that
help that primary owner. You may have none. You may have everybody,
depending on their actual level of activity, and
last is contributor. People who, you know, may
be there at the start, may give you some
input, but don’t follow through to the end the process. An example of this
being applied, and we’ll see more
examples later, are that for success
criterion 141, use of color, a primary owner is going
to be the visual designer. They’re the expert in colors. We’re not going to have
anybody choose the colors, you know, down the stream. No, it’s going to
be that person, because that’s the
things that they do. That’s their profession. That’s their specialty,
and they’re going to write that up in, typically,
in the style guide. Then you’ve got the secondary
owner, and interaction designer. That role will be saying,
I have a wireframe. We want to use color in ways of
trying to identify what’s going on here, and we’ll leave it
to you, the visual designer, to pick the particular shade. You know, it’s like, yes,
we’re going to have errors. We should be red, but the visual
designer is going to say exactly which shade of red
fits in that design, and the interaction designer
should also be saying, yeah, and color is not enough. The last example in this one is that the contributing person
would be a business owner, and that’s the case where in
the selection of the colors, the business owner probably
has a set of brand guidelines that are supposed to supersede
anything or any other products. So if I’m working for 3M,
I have brand guidelines. I hand it off to the
visual designers who use it as a starting point
for the style guide for the web property. So with the definition of the
five roles that make decisions and the levels, we want
to ask the question, is it really the developer? And you can guess
that the answer is no. And the breakdown if it
is really interesting. When I did [inaudible] it was
really exciting, because I found that instead of being
the, you know, that the developer didn’t
even come in first or second. Came in third. That your interaction
designer owns 37% of your success criteria. That’s 14 out of 38, and
then the content author comes in second at 24% with nine. Now that nine is large, because
there are five time-based media criteria in that total, but
that does put them second ahead of the developer, and then
you get the developer at 21%, or eight success criteria. So giving all the work
or all the responsibility to the developer doesn’t make
sense, because only one in five of your success criteria are
things that they actually own, and then just to finish it
off, you have the vision, the visual designer, has got
16%, that’s six criteria, and the business owner has one. So that in some case where
there’s a success criteria in which they really
are the primary driver, they have a lot of
the input on it. So it really emphasizes that with all these
decisions being distributed and being owned by these other
people, we need to make sure that they’re involved
in the process. Next question, when? I defined six places
where you would find it across the lifecycle,
as entry points. The first is a user story, or if you’re using a
more traditional model, the standard requirements,
that initial stage when the business owner
says this is what I want. Then you have something
like wireframes or other following requirements
which give you structure of the page, the
interface that’s, you know, in its basic terms, or the interaction is
how they would work. Then we get to the
visual components. We get the style
guides, as I mentioned, the general style presentation,
the branding, the colors and logos that cover
the entire site. If we have individual
cases for different pages, that’s where design comes in. Then we go to the content. That’s again, like I was saying,
the text, the terminology, and your — the scripting for
your video and audio, and last but not least is the code. That front-end development, the
HTML, the CSS, and JavaScript. Again, this is not entirely new. The government of Canada did
this similar kind of analysis. They found seven
production phases in their accessibility
responsibility breakdown, but with others, we went beyond, just trying to make sure
how often is this done, and did further analysis. So we also have the levels. We have primary,
secondary, and impact. Primary, the most significant
place where this entry point is when the decision
gets documented. We have secondary,
which are other places where it often comes in, and
then we have impact, and, you know, minor places where,
yeah, they could do something that affects accessibility,
you know, in some other stage, but it’s not the place you’re
going to see it the most. So we go back to
the question when? Does it really start with code? Say at all with me, no. When you do the analysis
and you look at the primary or success criteria
entry points, the information is
even more interesting. Wireframes account for 50% or 19
of the 38 A and AA 66 criteria. User stories comes in second, and the standard requirements
have gotten nine or 24% of your criteria ownership. Style guides comes in third
with 18%, seven criteria. Code comes in fourth,
5%, two success criteria. The code issues, and we’ll
see some examples, are really, you know, only one in 20 or
95% of everything is not code for the entry point when
the decision’s made. This last two is content. There’s one success criteria. We’ll see it in a moment that
is 2%, and then design comps. That says zero, and the
reason I say it’s a zero is that if you have your designers
following the style guide, your design comp should be
following that, and of course, what often happens and
which would be an exception to this is a case where
some new designer comes in. They don’t like the colors or
things look staid and corporate, and they want to give
it a new jazz a look. They violate the style
guide, and they introduce it, but that’s a different problem. That’s not the primary place
where this would happen. Last question, what? And for that, I’ve
broken into three types. We have user stories or
standard requirements. These are things that, you
know, I defined as the things that the roles would
do normally. They’re so basic. They’re such a great
best practice, if you don’t tell them how to
do it, they’ll still do it right because that’s the
way everybody does it, and if you didn’t change
anything in the process, if you didn’t train them,
they’re likely to do it right, and it will be accessible. Next is best practices,
and when I’m talking about best practices here,
I’m not really talking about accessibility
best practices. I’m talking about the
best practices each of these roles has in
their own domain knowledge, things that UX designers know. Things that visual
designers know, coders and content authors. What you need to do is
make sure that they listen to their better angels and
they make sure that they adhere to these sorts of things. You want to emphasize
that, yeah, this is how you write text. You need to introduce
these topics when they’re new,
and we do that right. Then last, there are going
to things that are all about accessibility,
things the roles don’t know about what they’re doing, and
that we need to help to train, things that an accessibility
expert typically has to do to help supplement their
information, so that you fill in those gaps in
what they don’t know. So you get a more
accessible outcome. So, we go back and just
ask, what is what’s going on with accessibility? Are these decisions
really accessibility magic and pixie dust? And, say it with me, no. It’s not, and the analysis
here is that for the roles, most of the accessibility
decisions for meeting WCAG 2.0
are best practices. Not that everyone knows the
accessibility best practices, but I, as a user experienced
person should know most of this. As a content author, I
know these sorts of things. About 40%, or really,
39, 15 success criteria, are supplementary
information, things we do need to teach other roles about
accessibility, and there are about three, or 8%, of
the success criteria that are requirements. There are a few,
but not that many. The key thing here is that
it’s not rocket surgery. It’s something that
we can build upon. We don’t have to start from
scratch with all of these, folks, to get them to
understand what they need to do for making things accessible. So let’s look at some examples. The first one is criterion
133, sensory characteristics, and the example of
what not to do. It’s like press the green
button on the right. That’s terrible. Maybe I’m colorblind. Maybe I can’t see the screen to
know where things are relative, because I’m using
a screen reader. The person who owns this
is the content author. This sort of text
should not happen. That’s why it’s listed
as a never event. You should be able
to just, you know, prevent that from ever happening
if you, content author, knows not to write that. So, you know, there are no
other people telling the content author what to write. It wasn’t in the specs. It wasn’t in the wireframes. It wasn’t in the style
guide, and hopefully, the developer didn’t
try to write it, because that would be
delegating the responsibility of the content author
to your programmer, and there really are
no other contributors, because the content
author really owns the text and the assumption here. Then, like I said, that’s
just accessibility knowledge. We just need to bring
awareness to the content author that when you’re
writing this text, in addition to all the
good guidelines you use, keep that in mind that your
audience may not be able to pick this out. So write your instructions in
a way that’s accessible to all. And eventually, that could
become a best practice. They just add it to
their writing guidelines, and when does it come in? Content. It comes in there
before the developer gets it, because the developer
is just going to take what you give them. It’s going to come from the
content management system. It’s going to be in an email or however the content
is written out. Next criterion, 221, timing
adjustable, and that’s going to be the case where
I have to log in. I need my information protected. So I’m going to have
something on the screen such as session time is
down to five minutes. Do you want to continue? Yes or no? This is the criterion that
I think of as being owned by the business owner. No one wants to code this. From an accessibility
standpoint, one of the options
is turn this off, but you got the business
owner saying, no, I have business requirements. I have legal requirements. I have the way it’s
done in the industry. I need it done this way,
and they will say I have to do this as a feature. That’s the primary
owner driving it, and then you have the
secondary, you know, owner on here is the interaction
designer who thrashes that out with the business owner and
says, okay, this is what we need to do, and this is
how we’ll do it. We’ll say five minutes and
they can haggle over that, but they decide this is how the
feature is going to be done. Now this is in talking
about the dialogue and making sure that’s
accessible. That’s a separate discussion. It’s a matter of defining the
feature, that you’re going to make sure you can
extend the session and that it’s defined there. And this is, you know, it’s like
you don’t have too many cases where people are going to get
away with trying to do it. It’s almost a standard
requirement. You could still say it’s a
best practice, and that safe, but again, they will
typically try to do this, because the business owner says,
yeah, I hate it when they — you know, it’s like
I was in there. I stepped away, got
myself a cup coffee. Everything looked fine. I press submit, and it says
you’ve been logged out, and I lost all my work. They don’t like it any
more than anyone else does. And when did that come in? The requirements
in the user story. So this is one of the rare cases when it’s a standard
requirement, one of those three, but and it’s also a rare case
where it’s the business owner, but this is where, you
know, the ownership is not in the hands of the developer. Next, 245, multiple ways, and that’s when you’re deciding
how you can navigate the site in different ways. Do you have site search? You have a site map? Bread crumb trails? Top nav? In-page links? Do you have links for all
the pages, because your sites so small that each page has
links to all the other pages? The acceptable techniques
for meeting with this particular criterion. This is usually owned by
your interaction designer, and if you’re in interaction
designer who’s been following the literature, this falls
under the term the scent of information, something
that was written up years ago about some people
like to browse. That’s the way they want to do
things, or, if I go to Amazon, browsing’s going
to be impossible. I’m just going to type in a
few words and see what I get. They talk about it in those
general terms, but accessibility and this criterion say
it’s got to be there. And so, you have these kinds
of discussions saying, well, how are we going to
put that in there? Now I don’t have any other
secondary contributor roles, but you could say that maybe the
business owner is going to have to find the budget to
put in the search engine. That might fit, depending
on your model or, you know, what you have for
your infrastructure, but that’s what comes in. This is one of many criteria which the interaction
designer owns. Next, color contrast, 143,
color contrast minimum. Bad example from my experience
with the sites companies that I had which use
blue, blue on light blue. This, you know, as I said,
when you’re at Blue Cross, everything’s blue, and
it sometimes is difficult to get them to understand this
issue, but this is, again, visual design question. It’s exactly what shade of blue and making sure the visual
designer who has the say, because they are
the brand police, they know how to get it right. No one else is going to have
too much to say about it other than maybe the business
owners, as I mentioned. The visual designer, say
it’s an outside agency, needs the brand book to know
what the starting point is. And so, the business owner
is going to hand that off and then leave them alone, because they’re not
the design experts. They don’t have the BFA
or any of the degrees that say this is the
way to do things. What is it for the type? It’s accessibility. I, as a visual designer,
probably don’t know anything about accessibility, unless I’ve
lived it, and eventually, again, it should become
a best practice, something that’s happening
that I get used to doing, and it becomes a standard
equipment, but I need to get to that point where I know that. Where does it enter? The style guide. But the things we’ll
be talking about isw that the style guide is
where a lot of requirements that can impact accessibility
are logged and need to be addressed, and if
they’re doing design comps, if somebody picks a new shade
of blue that’s not in the palate and needs to be changed, that’s
another place it would happen. But that’s not the primary one. The style guide should rule, and
that’s some of the assumptions. Last, 411 parsing. An example of this is missing
alt attribute in an image tag. Primary owner is the developer. Nobody told him not to put
the attribute in there. It wasn’t in the requirements, the style guide,
or anything else. It isn’t part of content. The alt text might have been,
but the key thing I want to point out is that this
is not talking about, from an accessibility
standpoint. I’m referring to this as
this is the HTML standard. When you run the code through
validator, and it knows nothing about accessibility, it says
every image tag is supposed to have an alt attribute. So if they run it through the
code validator, it should find that and flag it, and
something has to be added. Mainly, you’ve got to
put an alt attribute. What you set it to, different
discussion, but it needs to be there, and
that doesn’t happen until the developer
writes the code, and identifying those
things as a best practice. In an ideal world, the
developer does this. It’s part of your
design process. You make it part of check-in,
or you do it part of the build, that they will do this normally. Unfortunately, we’ve had cases where developers don’t
think that’s the case. In fact, some of my colleagues
did a great presentation with just writing a code
validator can fix a lot. Now I think they want
to say almost 90% of accessibility errors. This is one of the key things
about validating the code. You get developer who say
HTML 5 paved all the cow pass. So any code is valid. No, your tables aren’t
going to work. This will fail, and these
are coding standards. You’re making developers
write to the standards that were written by the W3C. So what does this mean when
you have this analysis, and how do you apply it
to change the status quo? Well, first of all, it
gives us an opportunity to improve efficiency
and quality for new and existing sites. I’ll get into that in a moment. It also is talking about
the shift-left concept. We have the ability to get
involvement happening well early in the parts of the design
process, and it’s a case where we can distribute
the ownership and assignments across
the system. We’re going to hand
it to roles other than developers and testers. And we can, because
we have information, we can tailor the information
about accessibility to them. We know who you are. We know what you know. We know what you need to know,
and so we can try filling in those gaps, because
we have a, you know, definition of what you have
to know, and we can focus it on there and write it in a
way that makes sense for you. Another place that it happens is if you’re doing accessibility
checklists. One of the things you do is
you look at your checkpoints and you identify and say, okay,
if the color contrast fails, I don’t send it to the developer
and they pick the color. I send it to the
visual designer, and that changes the process. And you get that stuff done
earlier in the process. What it means to
accessibility testers is that you’re distributing
the issues and remediations to the other roles, means that the team becomes
more self-sufficient. They don’t need you so often. They’re not sending you emails. They’re not texting you. They’re not chatting with
you saying I don’t know. What do I do about this? The design roles themselves
prevent the issues, because they’re defined
at the start, and ideally, as they get more mature with it,
they’re finding these issues. In fact, it gets
to the point where, depending on how much
cross-pollination, they start finding
things before you do. They will find it. They’ll return it and
they’ll say, yeah. Oh, yeah, I noticed that color
contrast wasn’t quite right. So I went back to the designer,
and they have it picked. Also, if you get that training
to your testers, as I said, they can do love this work,
because it’s not rocket surgery. You just need to have
the requirements, because testers will
follow a script. If you can define things in a
script that they can follow, they’ll follow it, too. What that does for us as testers
is that frees us up to deal with the difficult issues that they’re never
going to understand. Again, I have to make this
work with a screen reader. Or how come ARIA
doesn’t work with Dragon? And things like that. And the net result is
that you reduce the number of accessibility experts that
you need across the enterprise, and that’s important for
companies like the one I work for where you can have
hundreds of sites. If you use a traditional
model where I’m going to embed a consultant in
there, it doesn’t scale. Let’s just say if I have
300 sites, and I’m going to assign one expert or a
half an expert per site, I will need 150 engineers
to deal with all of them. There are just not enough people
in this profession to do that. So we’ve had to look for
ways to make it scalable and distribute the
load to the people that are making decisions,
and ultimately, have to be making the decision
and do it more intelligently. And that’s where we
get to the shift-left. So let’s start with looking at
what happens with new projects. We, instead of having
accessibility injected at the end, we accept and
insert accessibility throughout the process. Everybody gets informed about
what’s going on, and, you know, what happens with new products? We integrate accessibility
early in the design process, and we can make things that
are assigned, the ownership, to the different
decision-makers, and we can do role-based
training that, you know, gives them the refresher on what
they need to know to, again, follow their better angels,
and accessibility training, supplementing it
so that they have that gap fill that they need. And here’s an example
starting with where which you apply a shift
left for requirements? Timing adjustable. We already talked about that. When the business owner comes
in, it’s like, you can say — you identify the need. They work out which
approach is going to work, the different ways, depending
on what the site is structured. What can you afford? What are you going to do? Multiple ways, touched
on that also. You know, it’s the multiple ways
picture which way are you going to do a site search or not? Do you do a site map or not? And making sure that
they’ve got the thing that fits the situation
and work it out, all at the requirements phase. You’re not waiting until
you get to the final phases and you bring it up for
us as testers to find. Okay, wireframes. These two I didn’t discuss
before, 243 focus order. Identifying how the
key word focus is going to move across the screen. You can document that
sequence in a wireframe, and when you describe like
the general look of the page, you can start putting it
so it follows the order. Get your interaction
designer to put that in. They can put it is
a basic overview. If they have a custom
page with a specific way, like you have a custom
component, they can define it
there, as well. Similarly, for 246,
headings and labels, and its near relationship with
131, info and relationships, which is defining that not
only do you have headings, but you’re going to use
an H tag to define them. You can get that documented
in your wireframes, so that you have the heading
levels, and you confirm that there are hierarchy, and
the nesting is done correctly, and you can do that on
the page and on there, or if you find content, like,
you know, for table of contents, again, for long content
pages, privacy statements, terms and conditions, I may need
to have a secondary navigation, and you can define it
there for the developer, so they’re not picking
these things. So you have those definitions. And I can tell you that this
is an approach that I learned, you know, last year, is
being done at Wells Fargo. When the UX designer hands
off the requirements, this is baked into
the wireframes. They come up with
their own process. Unfortunately, I can’t share
that with you, but this is one of the things that they do to
get the decisions made and baked in early in the process. Style guides. Touching on one of them, we have
style guides, contrast minimum. You get the combinations. The style guide will just
naturally say these are the ones they do. They bake in the accessibility
of the contrast in there, and people are supposed
to follow it, just like they picked the
right shade of blue or red, and those will be
an accessible sort that you can test using the
color contrast analyzer while it still a, you know,
Photoshop document, however they communicate it. The next one, 231, three
flashes or below threshold. This is one where you put
the style guide and say, don’t use the link tag. When you create animation,
don’t do flashing. Don’t have strobe effects, or
maybe if you have an animation, you have a loading graphic, the style guide says
it should be dim. It should be this size. You can say what the standard
is in the style guide, so you’re not finding
these things at the end and saying, oh, my God. We’ve got to change that. How do we get that
into production? Writing guide. This is, you know, for
content authorship. Sensory characteristics. Already talked about
that where you have — you inform the authors
that, yeah, in addition to the
guidelines you already know, make sure that you write it
in a way that’s inclusive, that I don’t have to be
able to pick out color or know a position visually. The next one I bring
up because it’s like there are writing standards
that they’re technically AAA, and that’s what 313, unusual
words, 314, abbreviations, and 315 reading level,
these are AAA. But if you go into
content authorship, if you look at things like
the Chicago Book of Style, this is standard stuff. Your content author,
as a professional, should already know
these things. They may already be
doing these things. In fact, and doing my
research internally, we had an initiative. I can map these directly
to our writing guidelines. Now maybe not everybody knows
about them, but they’re aligned. So let’s make sure we can
try to bring that to bear. That we’re doing corporate
standards, which happen to take us beyond just AA. So that was new products,
but most of us are dealing with existing products. How do we change
the process there? Well, as I mentioned,
we kicked the issue back to the role that it belongs. We’re not doing design. We’re not doing content
authoring between testing and developers. If we have a content tissue, we
send it to the content author. If it’s a design issue for
presentation, visual designer. If there’s a question of
how it should function, we go back to the
interaction designer. So what does it do for the
[inaudible] of existing sites? Like with the new projects
we want to make sure that all the roles know
that they have the training. We need to get them informed
so that when we give them that issue, when we
assigned the defect to that role they’ve never
heard of doing, it’s like wow. I need to know about the
bug tracking software? Yeah, you might be involved. You know, that they
know what to do. And, again, we assign
it to the right people. We don’t spend — have the
developers writing text, picking colors, or
trying to figure out what it should be
at the last minute. We want to get into the roles
that do it and, over time, they will start to learn that,
yeah, we’re going to have to know this, and the next
time I’ll do it better. When it comes to shift
left, and that means when you pick the team
to do that remediation, it’s not testers and
developers alone. You need to include
your designers and the content authors, maybe
the business owner, if it’s, you know, got some
problems, but you need to make sure they’re
on the team. I’ve been on projects
where it’s like, yeah, what should we put
in for the text? It’s like, I can suggest, but
I’m not your content author. You don’t want me
picking your colors. I don’t know your
brand guidelines. I don’t know how
your text is done. I’m not sure what
your standards are. You need to give it to
the person who did that, because someone wrote that text. Hopefully, it wasn’t the
developer, but you had a role that knew what they were
doing, and they do that. As I mentioned, if you
are having your checklist, you want to analyze
your checkpoints. You identify the owner
that you will send it to, and you can make sure
that your developers and testers don’t do the design. So you could get a case
where color contrast. I have a color contrast issue. If it was designed right
in the style guide, then the developer had a typo. But if it was wrong
of the style guide, you don’t want the
developer picking the color. That won’t get into
the style guide. It doesn’t get updated. It has to be done
again and again. You need to make sure the
right owner handles it, and it gets updated
where necessary. So that’s what was
going on before, and since I’ve done these
presentations over the years, there is a bit of the future. The starting point,
as I mentioned in EBU drill [assumed spelling], and since I did this
presentation at CSUN a year ago, we have become part of the
team that’s an offshoot of the education outreach
working group of the W3C. It got approved this past
March at CSUN, and I’m part of the team with Denis
Boudreau from DQ, my coworker, Scott Chantelle [assumed
spelling], and Denis’s, you know, coworker, Katlin at
DQ, and what we are working out is the three-year plan
to take this to the world by identifying deliverables,
like a decision tree. If you need to apply these
sorts of things, we are coming up with a process and
we’re going to define a way that you can follow it, and you
can apply to your own needs. You know, when I talk
about these roles, that may not reflect the
way you do your work. You may have different roles. Some of these may
have been combined. Maybe they’re split apart, but
you need a way of doing it, and everybody’s is different. So we’re going to give you —
we’re trying to work out a way of giving you the tree
so that you can apply it to success criteria,
primarily for new work, and to your checklist. So you can apply
it to remediation, and we’re looking for input. My contact information
will be at the end, and we’re looking for input. And if you’re really excited,
maybe you can join the team. Otherwise, you know, you
can follow this information as we start to publish it. Things you can do now. Like I said, working — Denis and Katlin have
already got things for your UX designers. After the testers,
UX designers who know about user-centered
design, who basically, if you have a UX designer who
doesn’t consider that everybody, inclusive design, is user
centered for everybody, then you need to have a
conversation with them, because they should
already be doing or knowing the sorts of things. But it’s daunting. You know, Denis and
Katlin have done work through DQ you can
download right now. One of them is, it’s a
blog post about shift left. It’s a two-part blog
that’s bit.ly/2I0O3rY. Again, if you download on
the deck, I also tweeted it out before, you can get that. Probably, the most
valuable one, though, is they started releasing
heuristics. If you’re a user-experienced
person, you know that heuristics
have been along a long time. In fact, they go
back to the 1980s. What they did, if you download
this six-page document, is that you’re going to
find no mention of WCAG, but you’re going to see 10
heuristics, rules of how to make things accessible
written in a way that UX designers understand. They don’t need to know WCAG. They don’t need to have a
spell normative or things that are part of WCAG speak, but
that’s part of what’s in there, and that’s at bit.lya11y-heuristics,
all lowercase. Again, it’s a little
difficult to do this, and I’m probably
running out of time, but that’s something
you can download now. Also, WCAG 2.1 is coming
out later this summer, and I can tell you, having
done some preliminary analysis, all those percentages are
pretty much unchanged. It changes just a little
bit, but the number of items that the developer
impacts decreases slightly. It doesn’t really change
from one-in-five ownership or other things like that, but it really doesn’t get
may be more significant. Interaction and visual
designers, they get more responsibility. Content authors and
business owners, not really substantively
changed. And so, that’s what it — that
the information I have to share with you, and here’s
my contact information. I’ll be here through
the rest of the night. And so, if you have
questions for me, you can find me online,
[email protected] That’s O-P-T-U-M.com or
@billtyler on Twitter. Thank you. [ Applause ]

Tags:, ,

Add a Comment

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