- [Denny] Hi, everyone,
so this is Denny Boudreau. I'm going to quickly get us started, by introducing my colleague here. Aparna will introduce herself. - [Aparna] Hello, everyone,
thank you, very much, for joining us on this session. I'm Aparna Pasi, Accessibility
Team Lead with Deque Systems for the last two years, and
with 12 years experience in accessibility and usability. On to you, Denny. - [Denny] And I'm Denny, as I said, Principal Consultant and
Training Lead for Deque Systems. Involved in a lot of
different things at Deque, most of them being,
having to do with training and consulting, in general. We have something in chat, a partner about you need to speak a little--
- Yes. - [Denny] Okay, cool. So, yes, so involving training in general, and also with a lot of
things related to design, and accessibility here at Deque. I thought that a way for us to get started with this today, and also, connect with what we've been doing
already in this series, because we've had two webinars
already, in the UX series. One on personas, one on
the heuristics themselves. We've already introduced those heuristics, in the prior webinar, which
you can have access to, if you haven't seen it yet. And what we wanted to do
as a follow-up to that, was to look into how we
can use those heuristics to help designers get more involved in the process for
accessibility, and help them get a very clear understanding
of what they can do, and how they can contribute
to the success of the project. And ultimately, help make
the experience for users that much more accessible, in general. And the first thing that
I wanted to bring in for that particular
aspect of what we're going to be talking about today, is
the fact that accessibility is really something that needs to be owned by pretty much everyone on your team. And this is a concept that
has been floating around for a couple of years now. It used to be, that people would think that accessibility was
just one of those things that QA people would do. We've learned through the years, that the earlier you would start
thinking about accessibility, the more likely you were to succeed in meeting that goal in your project. Everyone has a role to play. The reason why that is, is
because accessibility really is a hard topic to master. I know that we like to
pretend that accessibility has such a pretty
straightforward and easy, if you know what you're doing, but, getting to know what
you're supposed to be doing is the hard part, because there's so much that you need to think
about, and very quickly you can feel overwhelmed, as a designer. I mean, as any stakeholder in the project, you might feel that way. But as a designer, that's
one of those things that you often hear about, is
that people want to do this, they want the help, they want
to make the experience better for their users, but, it's hard for them to wrap their head around what it is that they're supposed to be doing. One of the ways in which
we've learned to master this, or to approach it in
a more successful way, is decide, yeah, integrating
accessibility much earlier on in the process, that we
normally were doing before. This is something we called
shifting left at Deque. Basically, the idea of
moving further left on the, on the project, in the project lifecycle, to start integrating
ideas for accessibility as early as the very early design phases. Looking into usability principles, understanding the users
that we're working with, what their realities might be, particularities that they may have, challenges that they have,
and so on, and so forth. And then, working with the entire team, to make sure that people understand what the expectations are
throughout the project, but also, from the very
early phases, like I said. And when it comes to, to a process, this is the
representation of what we may, what we may mean. So what you have on this
screen, basically, is a bit of a diagram about a lifecycle, where we see key phases,
like the wireframe phase, the product backlog, the sprint
backlog, the sprint itself, the point where you get
to a shippable product, and then, the system being deployed. And the whole thing is, really,
is sort of linked together through dashed lines,
to sort of illustrate how the process works. And what we tried to
do as much as possible with our clients, is to
integrate accessibility at key aspects of each of those areas. So today, we're obviously focused on everything related to design in UX. So what that means, in
terms of a lifecycle, in terms of a representation
of the lifecycle, is that, whether we're at the design phase, we're at the wireframe specific phase, we're looking at mock-ups,
we're looking at research, whatever it is that we're
doing at that particular phase, we want to make sure that accessibility is baked in at that moment. And for a lot of people, this idea of what you're supposed
to do as a designer, is often a little blurry, people
don't really understand what it is they're supposed to do, beyond paying attention to color contrast. And I like to think that as
designers, our role really is much bigger than choosing nice colors, and making things look pretty. A lot of designers will
agree, that the main thing that they do is solve problems, which is something that
I definitely agree with. But when it comes to accessibility, I think the designer's role
is very capital, in the sense, that it lays the foundations for, to help avoid a bunch of other issues that could otherwise happen
further down the road. So preventing those issues from
happening in the first place is what a designer, is what
a Designer's power is really. When he or she knows what to look for, when trying to get a
project started, and define the requirements, or the ground principles that are going to, upon
which we're going to, to build the entire project. And so, one of the reasons
why that is, of course, is because when you think about, about issues, in terms of accessibility, we know, we've learned over the years that the earlier you
find about those issues, the less costly, and the less complicated they will be to fix. So what we have on the screen
right now is a diagram, like on, with an X and Y axis, on the, I can never remember, on
the Y axis I think it is, you have a, like a ratio
going from one to 10 times, to 100 times, to 1000
times, and to 10,000 times. And on the X axis, you
have the conception phase, the design phase, the development phase, the testing phase, and the release phase, so, your process, so to speak. And there's a representation
of a bug, or an issue, and it gets bigger and
bigger as you, as you, the further you get in that process. So, an issue that you may
introduce at the conception phase, say something about a
color contrast issue, in your brand colors, for instance. That would be very easy to
fix at the conception phase, because you're already
doing that at that moment, and nothing has been defined
yet, based on that choice. So that might be a ratio of one times the cost of the actual fix. But if you find something,
if you find that issue at the very end, while
you're about to release, maybe that particular issue
with that color contrast on your brand colors, might be 10 times, 10,000 times as expensive to
fix, or complicated to fix. Because at that point, there's such much that has been built on that
particular color choice, that it may be very difficult
for you to get that, again, get that addressed. And accessibility issues, in general, are very much like that. Whichever issue you find,
we're going to find that the scale may vary, but
it's always very similar to that ratio, where it gets
harder and more complicated the later, the more time it takes for you, before you find it. And examples of that, would be things like thinking
about alt text for images, or having meaningful
error messages on forms, or maybe even providing a
visible focus indicator, when you're navigating with the keyboard. These questions are usually questions
that we would address. I mean, depending on your, your team, and your process, of course. But those would generally be addressed somewhere further down the process. It may be that your, your content creator
will look into alt text after you've chosen images. But you're not really
involved in the process of defining that alt text. Or it may be that you're, you develop a form, as
a designer, but then the developer will figure
out all the error messages that needs to come up. And they'll do that, again,
with the content creator, because, that's the person
who creates the copy. And then, maybe the focus indicators are not being handled initially, and then, someone in the develop,
this development phase will try to patch that up by assigning a bit of an
outline, or something, on the keyboard interactions. And all of those things get
more complicated at that point, because, we don't really know
what was intended initially, and these things may
not have been addressed with a designer first. And if they had been
addressed with a designer, or if the designer had been informed of what those things
were, then the process could have been much
smoother, and everybody would have understood or
known what to do exactly further down the line. This idea of both going as early
as possible in the process, is something we think is very valuable. But in order to do that, a designer needs to know what to look for. What we've done so far, with the webinar, the webinar series, is look
into a couple of things. Like I said, we started with the personas, and then we went to the heuristics. Basically, what we've done so far, as part of that four-step process that we like to apply to as we're going, is we covered the create,
explore, and review pieces with the previous webinars,
where we're looked into the personas, we've
created modular layers, or lenses on top of those personas, to integrate the idea of a particularity, like a kind of disability,
or a visual impairment, or something like that. We've looked at how
those layers can affect, or the meaning they can
have on the experience of that persona, using the product. And then, we've reviewed how we can use the heuristics,
to try and address issues, or potential issues in the, in the work that we're doing. So now, as of this webinar today, we're
looking into that fourth part of the process, which
is really checking the work against the heuristics themselves, to be able to do an
accessibility review of the work that has been done. And the first three parts, like I said, are really about the review phase, and then, the next part is really about the heuristics evaluation phase, per se. On the last dial, the
last session that we had, we talked about how we were using the wireframes that were created when we started working
our redesign of deque.com. That's what we're going
to be showing you today, like going further into that direction, showing you some of those heuristics. We're going to cover three today. And basically, using like
the before and after versions of what that meant, in
terms of our process. So basically, like showing you what
happened behind the scenes with everything about that. And the reason why it matters, is because, we really feel that as designers, you're actually a big deal,
when it comes to accessibility. And it's time to recognize the impact, and the value that
designers bring to this, to this goal, of making content
more accessible to people. So whether it's about how
accessible content can be for people, or it's about how efficient the process can be
internally, because designers can plan ahead, and avoid
issues from even happening, or prevent issues from
happening in the first place. There is a lot that designers
can do to help with that. So having said all that,
we're gonna jump into, into those heuristics. Like I said, we have a total of 10 that we'll be covering
over the, these three, this session, and the next two sessions. We're going to cover three of them today, so navigation and wayfinding,
structure and semantics, and then contrast and legibility. And we're going to look into that part as, and I mean, I mean, Aparna is going to, we'll listen to that,
that part in a second. Before we do that, I just
wanted to contextualize again, something that we've said
on the previous session, just so you have an understanding
of what we're doing, if you haven't been part
of the previous sessions. So basically, the heuristics
evaluation process itself is this idea that you're
testing, or you're evaluating a mock-up or a wireframe
of the work you're doing. Usually, for usability,
this, because it comes, that's where it comes from, from work, from a previous work by
Nielsen in 1990, up to 1995. And that, to us, has evolved into a different set of
heuristics for accessibility. But, basically, the idea is
that you have a certain number of designers, who are doing the conduct a evaluation of a particular product, according to a set of
general rules of thumb, the heuristics themselves. So basically, defining
who will be testing, how they will be testing,
is the first part, that's what we're going
to be looking into. Understanding your users, so to assess, using those personas with
different lenses on them, to see what the issues
might be, when it comes to a different type of disability. And then, running through the, or walking through the
heuristics evaluation itself, and then, collecting and
analyzing the results, in order to be able to
go back to your work, and improve, based on
the findings that you've, you've uncovered through that process. So with that said, we
can move everything over to Aparna, so she can talk
to us about navigation and wayfinding, as our first heuristic. - [Aparna] Thank you, Denny, thank you, for setting the context. Before moving on, am I
audible to everyone now? I, as you meant to be, yes, okay. Every user experience
consultant these days tend to perform heuristic evaluation of their product, or screen,
to gain great user experience. When we at Deque receive a wireframe for heuristic evaluation,
we do it specifically for accessibility, as we specialize in it. But, to help ourselves perform
this heuristic evaluation, we came up with 10 heuristic
principles for accessibility. And as Denny mentioned earlier,
we shall take you through the first three principles,
and the way we analyze them against a wireframe, to understand if the accessibility
principles are met, and if so, then how well have we achieved that. So the first heuristic
that we will go through is navigation and wayfinding. With checks, if users can easily navigate and find content along
with data mining where the user is located in the website. Since we will not be able to demonstrate every heuristic on the wireframe,
we will take you through each statement at a high level, and then demonstrate two
heuristic evaluations on the wireframe. So if you see the screen, we have certain statements
that we're up against, which we have a measure,
whether it is applicable. If it is, then it is yes. If it is not, then no. And sometimes, we don't find scenarios where these heuristic statements apply, and they would become not applicable. We also have a column stating rating, which would give the evaluator how well we have achieved
that particular statement. For example, when we see a wireframe with interactive elements, our
initial question should be, on how the interactive
elements focus state would be displayed to users. And that is nothing but the
visual focus indicators. Targeted audience would
be keyboard only users, low vision users, and any other user who will need to understand and follow the focus all throughout the elements. Without visible focus indicator, it would be nearly impossible
for users to understand where the focus is present. In a couple of minutes, we
shall see the difference between having a focus
indicator, and not having one. So the next heuristic
statement talks about the title of the page, which
is the very first element that a screen reader
user would interact with. And as a designer, we may need to work with the content team, to
provide a meaningful title, that would describe the
purpose of the page. For example, about us,
followed by Deque Systems, would let the screen reader users know that the current page is
about us, or Deque Systems. And having only Deque
Systems, wouldn't provide the context of the page, which is various and shield from the
screen reader perspective. The following statement would be about the first level heading
present on the page, which should be ideally
similar to the title, so that it is ensuring, or assuring the, and the screen reader user, that they are still on the same page. The following heuristic statement, is about the heading sections. So having heading sections
would provide a lot of context to the screen reader user, as well as any user, to
be able to judge the need to go through the
content, or script through to the next section. We should again look at
the examples for the scene, in a couple of minutes. Many times, screen reader
users tend to navigate through the web page using
links, or buttons, or headings, that is the way they navigate. At the same time, there are many instances where we see, read more,
and learn more links. So the fifth statement, or
the fifth heuristic statement, is talking about that. As sighted users, we
tend to get the context off learn more or read more links. But, from a screen reader
perspective, when they hear a group of hear more, or learn more links, it doesn't really make sense to them. So again, as a designer,
we need to work with the content team, to ensure
that we are given the link text, which can list the purpose,
or the context of the link from the text itself. The last two would be about avoiding repetitive tabbing,
for screen reader users, as well as the keyboard only users. So when we provide a skip
link at the beginning of the navigational section, and
when you're making it visible, you're enabling the user to skip through the repetitive blocks. And also, the organization of the
navigational elements, helps the users to find their way, of where, or within the website. Now, we shall look at the
examples, the two examples that we have for this
particular heuristic. And that would be, the
visible focus indicator. So if you see onto the
screen, the left side is our wireframe image, where there are interactive elements, but the focus state is not clearly shown. When we were going
through these wireframes, we made sure that we have
that particular state. As a result, this is the, the
result is on the right side of the slide, with the
image, where training has a two pixel underline, showing that that is the particular element in focus. So the statement that we
need to ask ourself here is, is there a clear, visible indicator set on all actionable elements,
as they receive focus? And how well have we achieved it? Even having a browser
default to dotted lines will achieve it, but are we giving that great user experience to the user, should be the question. And the next slide
would about the heading, the meaningful section headings itself. So again, if you look at
the image onto the left, we have about us, which
is defining the section. And then, we have four sectional elements, but I, as a user, am not sure if these are the
services that are being offered by the company, or are they saying that these are what we do? I'm not sure, because there's
no section heading for it, so the context of those links,
or elements, is unclear. Whereas, if you see
onto the right, we have, we know that the page is
about the WorldSpace Attest, and then, we also know that
there are a few of our, of the trafficked
website, that are trusted by WorldSpace Attest. And then we also know
that there are problems, that the WorldSpace Attest save from. So we know that there's
a, that each section has a sub-heading, which
is giving the context of each section itself. Now, we would move on
to the second heuristic. Denny, onto you. - [Denny] Thank you. Okay, so, there are a
couple of questions in chat, that I could see, and
I answered some of them as we were going. So for the benefit of everyone,
I will sort of weave that in what I'm about to say. So first of all, yes,
the slides will be shared after the session. I think it's just a
regular follow-up to the, to the webinar, with access
to the slides themselves. So you will get access to those, so don't, don't exert at like, don't try to write down everything, you will have that, is
what I'm trying to say. And the other question was
about the table that we showed, that we showed initially,
so I'm about to get to that, and I will answer those questions, too. So the second heuristic, basically, is about structure and semantics. So it's really about the idea
that users can make sense of the structure of the
content on each of the pages, and also understand how to
operate within the system, within the site, the
application, the product itself. So how to, basically, make,
like leverage that structure, that the semantics
underneath the structure, to understand what is going
on, and how to use the content. We have a list again, of
seven different statements that are basically in
the granular breakdown of that heuristic, so, a
bunch of different ways through which we can wrap our head around what that heuristic actually means. Because that's the whole point. The whole point here is
to say, as a designer, you should be looking into
those seven heuristics as, the tools that you're working with. But when you start working
with one of those tools, and you want to be very precise about what it is that you're looking for, then that breakdown gives
you that information. And as we go through these other sections, looking at adding other tables
for each of those heuristics, so often, you will get
yourself a nice full list of all the things that we
think are most relevant, when it comes to design. There was a question about
the measure versus rating, and the star, and the
check mark versus the yes, I'm gonna get through that really quickly. The measure part, actually, is something that we were adding for accessibility, that you usually would not
find in a heuristic evaluation. In a heuristic evaluation,
you would have questions such as those, and you
would have the rating part, which they, and then,
it would basically be have I addressed that
particular situation? And the answer would be either check mark, or X, or yes, or no. But, you also have that
star, for situations where you really go
beyond, and you provide a, like a fantastic user experience, when it comes to that time. So depending on how you
want to work through this, in terms of the heuristics
themselves, it's really about getting at least check marks everywhere, and whenever you can,
getting stars instead. Because the more stars you have, theoretically, the more satisfactory the experience would be, ultimately. The measure part, is
something that we're adding just because of
accessibility, and because, one of the concerns that people
have when they come to us, is that they want to make
sure that they comply with any US guidelines. In most cases, we checked it, that No, or we checked it off Y. So we use both systems in parallel. There is a user experience
piece that comes in the rating, and then there's a measure
that basically tells you, that particular element,
is that something... Because everyone of those
things refers you, ultimately, to assess this criteria in WCAG. So for each of those things,
if the measure is yes, as if it complies, or no, as if it fails, or is it just not applicable,
because of the context? We either don't have
that thing, or it's just not relevant to what we're doing. Those are two different indications of, of measures that we have,
to see whether or not the design itself meets our
goals for accessibility. Some of the heuristic
statements that we have in here, are whether or not the content,
that looks like heading is defined as such in the wireframe. So it's one thing to have
content that is big and bold, but if the designers don't convey that this is supposed to be a heading, maybe it doesn't get, it
doesn't end up being marked up as a heading further down the process. Same thing for skipping a
level, hierarchic levels in the headings themselves. If the designers don't mention that a particular heading
structure is in place, the heading levels might differ, when it comes to the development. So defining those things
ahead of time, again, saves some pain and problems for
further down the process. Paying attention to whether
or not the information is conveyed only through
sensory characteristics. So for instance, referring
to something by its color, or its location on the
screen, or its shape. Instead of doing that,
making sure that we're also supporting that information
by a piece of text. Maybe there's a red
button, but that red button probably has text in it, so
defining the red button with some such label, will help
someone who can't see the color, or can't perceive the
visual perspective of it, at least find it through its text asset. So supporting everything with text, is basically, what it comes down to. When it comes to navigation mechanisms, like menus, navigation menus, menu bars, groups like a mini narration of links in the content. Structuring everything,
and one of those things with actual lists, and
defining that, again, through our adaptations in the wireframe, would help the developers
know exactly what is expected, in terms of that context. Data tables, same thing,
making sure that we have table headers or table, column headers, or
table header rows, that, columns it doesn't accept. Column header rows, and you know what I mean, TH
on the column headers, is what I'm trying to say. So we have those defined, both visually, in the design itself, which would be expected,
but also have adaptations that define that those things are not just regular data cells, but
they're actually header cells. If we have groupings of form elements, making sure that there is a common label that works for the entire grouping, whether it's for a phone number, or for some sort of gender, for instance. Having that label on
top of everything else, will sort of group, or create a grouping for the whole thing. We want to have that visually, but we also want to have that
conveyed programmatically, to screen reader users. So defining that through the, through the adaptations,
would be also be something that the designer could, could provide, as part
of the documentation. And then finally, when it comes for form controls, X fields, check boxes, and
all these different things, that they do have a visible,
meaningful text label. And I insist on visible,
because you want to make sure that that label stays
visible all the time, that it's persistent. Which means, that using
placeholder text around these, for instance, might be an issue, because if you're using those,
and I start typing in, then the label disappears, and all I have is the actual data. So figuring out a way where the labels either remain visible, or that they're, that they just stay there,
or that they at least, they get replaced by
something, if they disappear through assorted of text. The first example that I
wanted to cover with that, was this idea that form controls have a visible, meaningful text label, and also, the groupings. As an example, on the left-hand side of the screen right now, we have a, a very early version of our wireframes, when we're looking into a form for a section called, get accessibility help. So we have in there, a
couple of regular text for the form, text
fields, like first name, last name, you know, and so on. But we have this section
called help needed, which is one label, and underneath that, we have six different check boxes, which all have their
own individual labels. So each of the check boxes, whether they say training and education, accessibility strategy,
accessibility fixes, I can define accessibility issues, selection of accessibility
tools, or other. All those things have
their own little label, for each of the check boxes, so these could
programatically be associated, and everything would be great. But they all refer to
something much bigger than just them, and that's the idea, that this is a section called help needed. So for something like
this, we could define help needed as a common
label for the entire thing. But if the designer doesn't define that through the requirements, or the document that usually provides,
then that may become a heading, right, it may
become just like regular text, that the developer puts in a dev, and it's completely disconnected from the rest of the content. So defining these things,
and thinking about conveying that information through the adaptations, will
again, inform the design, and inform the process, going further. And then when it comes to the
visual labels, for instance, if you look on the right-hand side, it's a very crude mock-up of a form wireframe, where we can see that. And we don't see text or anything, it's just like gray
areas, that are supposed to represent labels, and
then just white boxes for the forms themselves. But we can see in the first few boxes, first data text fields, have a, have their own little label next to them, and then there's a big
text area at the bottom, that doesn't have one essential label. In other words, if something
like that was to developed by a developer, then that
text area would not have it's own visible label. So it may become an issue, in
that sense, for some users, if it doesn't have its
own label assigned to it. So again, it allows the developer, the designer could think
about those things, and to announce what is
expected, so that the developers don't create issues on their own, based on a lack of
information, from the design. Another example, with the
content, that looks like heading, not being defined as such. Or the heading structures skipping hierarchic levels. So again, on the right-hand
side, now we have the wireframe here, so
wireframe of what the footer of the deque.com page should be. So basic gray text, with gray backgrounds, and zones defined. Often, if we ended up being very similar on the actual implementation
and production of the site. But when we, when we initially
received the wireframes from our agency, they had defined some of these pieces of text
as looking like headings. But, there wasn't any
information about what, if they were headings, if they were meant to be headings, or not. Like for instance, we have
a section, or a column for about, one for
tools, one for services, one for training, one for
learning accessibility, and one's for result in the wireframe. And they all have a series
of links underneath. If you don't define anything like that, it would not be surprising, if
the developer ended up saying so we have a bunch of lists? And the first time I mentioned that list, would be about, and the
other ones would be linked, as opposed to saying, I
mentioned we are going to create a list for the links themselves, and I'm going to have
a heading on top of it. The first part you want
to convey as a designer, is that, those are actually
meant to be headings, and they're not part of that list. And the second part that
you need to think about, is also, what's the hierarchic way, the hierarchic level of
that, of those headings? If I have a section, a general
section that is called, say, need accessibility
help, for instance, and across the entire design,
we identified that as being a H2, because that's, it sits on that level hierarchically. Then, the content for about
tools, services, training, learning accessibility, and results here, can't be H3s, because visually, it's in, it implies that there
are different things. And if we had about as a
H3, it would then become a child hierarchically,
like essentially speaking, would become a child of
the accessibility help, which was our H2. Defining something like this, would mean, that we have to think about, just revealing our heading
structure in a way, that the footer section, the
part that's at the bottom, the lighter gray part, as it's own H2, that may or may not be
visible on the screen, but that would need to be
integrated, so that we, we create that hierarchy
between the different sections that are basically sitting
at the same level on the, on the document. Which is what we ended up doing, in the, the often version again,
often at the end, I mean, in the design, where we've
integrated different levels. Also that, levels of our headings, so that it would represent
the structure that, in the most reliable way possible. So those are examples, again,
of how these heuristics, and the statements, can
lead design into making the right decisions for accessibility, and how that can inform
the process going further. So I'm gonna move it over to Aparna, for the last heuristic
that we'll cover today, about contrast and legibility. - [Aparna] Thank you, Denny. So we told and defined the
heuristic for this session, as contrast and legibility. As the names of the heuristic suggest, this is more about color
contrast of the font, non-text graphic, and readability or legibility of the font itself. The important aspect that we really need to keep in mind, while
designing interactions, is if we are using color
alone to convey information. Denny, can you move to
the next slide, please. Yes, thank you. So the common example
of using color alone, is showing error state,
with only red color border around the form fields. Now, another scenario
that comes to my mind, is of showing green color as success, and red color as failure. In both these scenarios,
a color blind user will not be able to make
sense, or understand what is going on the screen, because, they would not be able to differentiate, or distinguish between
red and green color. Designers tend to use colors
for very different reasons, and it is really important,
that we keep in mind, to not use color alone, to convey a state or information, and always have an
additional visual cue, to associate with the color, so
that the color blind user, or low vision user, or even cognitive user will be able to understand the intent. The next important aspect that
this part of this heuristic, is with regards to the color contrast between the foreground, and
the background of the text. So without proper color contrast, a color blind person, and
again, a low vision user, would not be able to
differentiate the text, and the visibility of the
scene would be very poor. It is very important to have 4.5 is to one contrast ratio for text size of 12 point, and three is to one, for
a text size of 18 point. Now, you might be wondering
how to get this contrast ratio. There are tools out
there, that you can use where you input the hexadecimal
value of the background and the foreground
colors, and you would get the color contrast ratio, and
it would also let you know whether it is a WCAG level, a
double A, or triple A failure. That is one tool that is,
would come to your help when your designing,
or choosing the colors, or color palette, for the
website that you're designing. Additionally, having 1.5 M or N spacing between two lines of text, is needed to let
cognitive and low vision users be able to read the content,
without any trouble. In fact, all these factors
provide a great user experience for normal sighted users, as well. So the other important
aspect that we really need to keep in mind, is the
usage of images of text. Now, designers tend to
have the specific reasons of using images of text,
where they would like to style the text in using a
particular font, or a color, or you know, the kind of the
shadow effect, or all the other, you know, aesthetic feeling
that their text should have. But, for a low vision
user, or a cognitive user, they tend to change the
style, or font, or color, or zoom the text, or they
tend to many more things, which they will not be able
to do with the image of text. So whenever possible, it is very important to keep in mind, that
we use the real text, and not the images of text. When we use the image of
text, the user experience for low vision user and cognitive users would be really poor, and it literally, it is really troublesome,
when you actually see the users do that. So this is more about these statements covering the contrast
and legibility heuristic. Now, we will see through two examples that we have for this heuristic. So the first one, is about, if
you see the left-side image, the try the bigness guide,
that is the blue color font on white background. So that is not very clear
for a low vision user, or a color blind user. But when you take the
example on the right, the black on white is very clear. It would pass the color
contrast ratio 4.5 is to one, like way, way more,
and it is more legible, it is more readable to any user. So when you choose colors, ensure that it is just not 4.5, but your
actually meeting more than that and you're enhancing the background, or the foreground colors, in a way that they, they compliment each other, and give a greater user experience. Again, for the smaller text,
it should be 4.5 is to one, and for large text, which is 18 point, it should be three is to one. And also, having that 1.5m
spacing in between the paragraphs would give more readability to the users. And the other point, that would come under this heuristic, is to have non-textual graphic color contrast. So when we talk about icons, we tend to use colors that go with the theme, or we, we really kind of not focus more on the colors. But having the color contrast ratio for the non-text graphics,
is also important. If you see from the
standards point, WCAG 2.1 they definitely ask you to have three is to one color contrast ratio. So ensure that even
the contrast, the icons meet the color contrast of
three is to one, so that, it is clear for users who would know, the low vision users, or
the color blind users, to understand the intent of the icon. Again, the, the important state here,
statement that we need to ask ourselves is, if the foreground and background contrast ratio
for the meaningful graphics, not the decorator, but meaningful graphics is at least three is to one. So this concludes our demonstration
on the heuristic part, now for closing, I will
pass it on to Denny. - [Denny] Thank you, Aparna. Let's talk about questions, that's what we're gonna get to those in a minute. Before we do so, I just wanted to, well, first of all, thank
everyone, on behalf of Laura, Aparna, and myself,
for showing up today, and being a part of this. I wanted to make sure
that you all get a sense of what is coming up. So if you've enjoyed what
we've been showing today, there is more of that coming
up, on the 20th of November. And then, also on the 6th of December, would be where we will finish, all other stuff in
heuristics, for the content. We already have everything
setup for the next one, if you want to register for that. You have the URL over
there, and of course, as we share the document,
you'll be able to see that. But also, if you just go to deque.com, under News and Resources, a menu item of our navigation, you'll find webinars, and
you'll find it there, also. So with that said, I'm gonna
take over for questions. So I think, do I, should I hand it over to you, Laura, to handle the questions? - [Laura] Yeah, sure,
I have one in our Q&A chat, that I'll go ahead and start with. Jessica asks: When you have a section with learn more links, how do you differentiate that for screen readers? Do you use an aria-label,
or aria describe by, related to the text prior to the button, or are there other ways? - [Denny] There are a couple
of ways to do that, for sure. I mean, of course, we don't
want to stop using content like learn more, or
more info, or read more, when it comes to particular types of link, because they serve a very
precise purpose in our design. But, as you're implying, those links, out of context, they won't mean much to a screen reader user,
especially if they're extracting the entire list of links, into, into say a video, or JAWS,
to get the full list of links in a model, for instance. So ways to do that. The way that we recommend
the most these days, I would say, is the use of the aria-label. So you'd, basically, if you want to have a more contextualized
link, then just read more, you could use aria-label to have a value, this is something like read more about this webinar series, for instance. So visually, you would have read more, but the screen reader would
pick up as read more for, read more about this webinar
series, or something like that. When you use aria-label, of
course, you have to keep in mind that it's going to completely
replace the actual text. So you don't want to use
aria-label to create that, or provide complimentary information. You need to, be aware that it
replaces everything entirely. That's one way to do that. You could also use
aria-describe by, I guess, if you wanted to refer to
something else on the page, that could be added on top of
what you have in your link, to sort of combine them into a bigger, more meaningful link
text, that would work too. I mean, it always depends on just how much are you supporting in the, these are agent secured,
using these technologies. Another way, would be,
which is more old school, and which I personally tend
to prefer a little bit, is to have the entire link
as part of the anchor, so it's part of the button. So for instance, read more
about the webinar series, but then you use CSS to hide
part of that off screen, or just turn that into a one-by-one clip, so that nobody sees it,
but it's still there, as far as the link. So when you disable CSS for instance, the entire link is there. When you extract, it's automatically
part of the link, also. But that requires a
little bit more CSS, than, than just using some aria with it. If there's one thing you really
should not consider doing, is using a title attribute,
because it's just not supported in a very reliable way. So while it will work for some,
it will not work for others, and if you're trying to go beyond the idea of just being compliant to
standard, but really provide the most accessible experience possible to the broadest range of users, title is really not really the best way. That would be my answer to that one. - [Laura] Great, thanks, Denny. Mark says: Fantastic job developing the accessibility heuristics
model, and evaluation process. Do you have any insight
on how to coach designers, for evaluating heuristic statements that are subjective in nature? For example, easy to
read, clearly defined, and facilitate wayfinding. - [Denny] Well, we, when we train, I've sort of made it a purpose of mine, to never really talk
about WCAG to designers. In the first place, it's already, it's already an
uncomfortable conversation, with developers and QA
people, to begin with, because of all the
different sets of criteria, and all the different
numbers, that they feel they have to remember, to do those things. So that's how we came up with the idea of the heuristics, initially. The heuristics all pretty much map to the guidelines of
WCAG, to a certain degree. So it's a different way to
present the same information, but in a way that
hopefully makes more sense, because, it speaks their
language a little more. So the language of designers. To us, really, the way to coach designers on those heuristic
statements, is really to get them to think about the end goal, which is to provide, for instance, a clear way to navigate, and
find your way around content. So understand what that intent is, and have that in their heads,
as they're designing content. And hoping that over time, it
triggers a couple of flags, or red flags here and there,
when they're seeing that, oh, maybe they should have had it, ate bread crumbs that day, or maybe, maybe the search box wouldn't
be such a bad idea after all. But like, so it's really getting down to, I mean, by raising awareness, basically, about the differences, because
this works hand-in-hand with using personas, and
different lenses for disabilities, on top of those personas,
and thinking about the whole designing for the extremes, that we've mentioned before, also. And how designing for people that are on the trailing ends of that bell curve, makes it so that your average
users are going to be handled, or their needs are going
to be handled implicitly. So for teaching those concepts, you've got the designers, so that, when they start looking at their design, they naturally start to think about users that are usually outside
of their, of their scope. And that's how it gets built, really. So I'm not sure if I'm answering
you question specifically, but it's about the
mindset, for the most part. And those 10 heuristics are
there to help the designer get on that journey of thinking in a more inclusive
manner, when they design. - [Laura] Yup, thanks, Denny. Maureen asks: How can we
watch the past webinars? Maureen, if you go to the News
and Resource, and Webinars navigation items on our website, you'll see at the bottom of that, there are on-demand webinars,
that you can watch for free. Next question for you Denny. Can you please relate,
again, on how to design error messages, they're
usually marked in red, with some instructions. What is the best practice for those? Thanks - [Denny] Well, the
convention definitely is to have errors written in
red, as opposed to black. So, the first thing that
comes to mind, obviously, is you want to make sure
that you're not going to use a red that would not meet
sufficient contrast ratios. From both against the surrounding text, if it's part of the same object. And also, against the background. Oftentimes, people don't
really think about it too much, or they want red text, so they're going to use
just like the regular F-F-0-0-0-0, or F-0-0 hexical value, which gives that type of really great red. It just, it so happens that
that red against white, this is a good contrast
ratio, so we see that often. Where it used to be a little darker, so it means that these are 4.5 ratios, and that's the first time really. But in terms of, of designing error messages,
there are a couple of things, I think, that are important. The first one, is that
you should never just have that error message in text,
it should always be supported by some visual, that will also
help draw attention to it. Because it's one thing
to have an error message that is conveyed properly
to a screen reader user. But for a sighted user, who may not have a full view of the entire screen, because they're using
magnification, or because, they may just not be focused
on the right area right now. They may still miss that, that error message, if it doesn't, if it's not supported by something else. So we see, we see little
icons, like a exclamation mark, or something like that.
- Warning icons, yeah. - [Denny] Warning icons,
something like that, exactly. Or it may be that the error
message itself is boxed, so it stands out. So adding those elements,
that frankly helps. I would say, and again, a lot
of what I'm talking about, is not so much what WCAG
requires, but really, what works best for people, in general. Thinking about different types
of disabilities together, like using inline error messaging, as opposed to just having the errors at the very top of your form,
is also, could be useful, because, yes, you could have
all those errors at the top, and it's like kind of a bucket list. But, again, if I mean,
if I can add low vision and zoomed in on only a
portion of the page at once, I may get to the error, the
field that has an error, but I no longer see the errors at the top. So if they're both at the top,
and repeated inline with the, with the field, that's always better. So that's another thing to consider. And then maybe also...
(person mumbling). Yeah, go ahead. - [Aparna] Yeah, I think it is important to have those inline error
messages visible all the time, because we tend to see
that, when you tab out of the field, the error
message disappears, and we are not sure if, you know, that that field and the, the
error state is fixed, or not. So, until the error is
fixed, if we can have the error message displayed at all times, I think it really helps the low vision, and the cognitive users. - [Denny] Yup, yeah, absolutely. And the last thing I wanted
to say about that, also, is that, if you're going to
use error messaging like that, you want those error messages to also be conveyed through
assistive technologies, and that's where you would
use aria-describe by, for instance, to connect
the actual form field with the error message,
so that when you set focus to the form field, it not only
conveys the actual text label of that form element, but
also, the error message, so both get sort of
concatenated into one string that gets conveyed to the
assistive technology user. - [Laura] Thanks. Here's a question from Ann. She said the, they're on
their WordPress website, there's a drop-down menu
that's not accessible, and this seems to be a common issue, as readers cannot get by sub-menu items under the main menu headers. This may be a developer question, I'm not sure if this relates to design. But, do you have any
ideas for how to redesign the drop-down menu, so that
it could be accessible? - [Denny] Can you explain it, would it, what it's like, again,
because I'm not sure that I understood, I can
envision it in my head. - [Laura] So, the issue
is, that the drop-down menu on WordPress themes are
commonly inaccessible, in that the readers cannot
identify sub-menu items under the main menu headers. - [Aparna] Well, this is the
common issue that we see, that the sub, you know, the
main menu having sub-menu is not being exposed. - [Denny] That's because their drop-downs are using optgroup elements, or because it's just visually presented
with an indentation, that doesn't convey the semantics. - [Aparna] It could be the
second one, I guess, because... - [Denny] Yeah. I'm gonna try something,
but, if the description of the issue here, is that, visually, there is limited indentations,
so there's more white space before the actual words, so that creates an indentation in the drop-down. Then, semantically,
there's nothing conveyed about the structure, it's only visual, in terms of the structure,
so that obviously, this is not gonna help anyone, who can't see the actual drop-down. So, optgroup is meant for exactly that, to create sections
inside a drop-down menu. I just don't know how
reliably optgroup is being, is being supported in assistive
technologies, in general. But, that would be the
first thing to look at. Other than that, it's probably working. If it's the only thing
that you have as an option, is to work with the visual presentation, it would need to provide indications, that allow the user to understand, that through that visual presentation, we just shifted to a different
level hierarchically. And you could hide that
stuff, or with CSS, also, which is same way that you
could hide extra content from a link, but in through CSS. So it's not something that every site user actually gets to see, but
you would need something like that, to convey the structure, if this is really what
we're talking about. - [Laura] Alright, great, thanks. And it looks like we have
time for only one more. The question is: What about, for color contrast, what about fonts that are in disclosures or footer areas, which are less than 12? Should the contrast be higher
for those smaller font sizes? - [Denny] Do you want to
take that one, Aparna, and start with the same?
- Yeah. They should be at least
minimum 4.5 is to one, but higher the contrast, it's the better, because the font size is much smaller. So we definitely suggest to
have more than 4.5 is to one. - [Denny] Yeah, yeah, what I
would, after that, basically, is that, color contrast
applies to, because I have, I've also seen a question
about disabled content, so I'm gonna loop that
in at the same time. The Success Criterion for color contrast, 1.4.3, has a couple of
exceptions at the beginning. One of those exceptions
is about content that is, I forget what they're calling it, but it basically means disabled content. So color contrast does not
apply to that, in particular. But, for actual text, and especially text that conveys information,
which would be that (mumbling and garbling words), that absolutely needs to
meet the contrast ratios. So 4.5 would be the minimum,
which means that light gray on a white background doesn't work. It needs to be a certain
level of gray, for it to pass. But if part of it is gray,
if the smaller the text, the more difficult it is to perceive it, so ideally, you would have more than 4.5, but what is required, is 4.5.
- Okay. - [Denny] What you also
want to make sure, is that if you have text that is
smaller than, say, 12 points, or 12 pixel, or the equivalent, that we will be able to at
least bump up that font size, so you don't have anything
in there, in your code, that may prevent us from zooming in on that font face.
- Yes. - [Denny] Which isn't actually
in a browser these days, but you, oftentimes we see on mobile, that pinch to zoom is
disabled, so you can't zoom in, and the text is really too small. And now, it's also pretty light, in terms of color, then of course, people are going to
struggle with reading it. - [Laura] Great! Well, we have run out of time. I just want to thank everyone, for attending today's webinar, especially to Aparna and Denny, for doing such a great job presenting. Keep an eye out for the
email with the recording and the slides, and please,
join us for Part Two of this Accessibility Heuristics series, that we're doing on November 20th, we'll be covering the
next four heuristics. And thanks, again, everybody. - [Aparna] Thank you. - [Denny] Yeah, thanks, everyone.
