- So we're here today to
talk about web accessibility. You may or may not know
what web accessibility is, and that's perfectly okay, because that's what we're
gonna talk about today. You also may or may not know that we, as public affairs and marketing, and more specifically, the
web communications team, have been spending a lot of time this year focusing on web accessibility, and making sure that our
website is usable and friendly for all persons with all abilities. Specifically, we've been
working on our web templates and our tools within OU Campus, and different parts of the
entire hope.edu website to make sure that they
are fully accessibility. We're actually going to
be rolling out some pretty major changes to the website
globally in the coming weeks, that will change a bit of
even how the website looks to address contrast and color,
and some of those things. Jeremy's gonna talk about what that means and why we're doing that, and in fact, I think give us a little sneak peek too, of the new look of the
Hope website as well. So anyway, I wanted to make you all aware that we are working on those
changes behind the scenes, and some of them are
really big picture changes, but today we're gonna
focus on what things that you all and we all can
do to make sure that when we're making edits
to our web content, that we're making those
changes and adding that content in a way that is accessible so that we future-proof our site
and that we don't have continuing issues going on moving forward. So without further ado,
I want to introduce Jeremy Abrahams from Mighty in
the Midwest in Grand Rapids. Mighty has been our primary web design and development partner
for a number of years, dating back to initial
hope.edu website redesign, which we launched in 2015. We have a couple of other
members from Mighty here today. Cliff is here, and Danny's
here, so thank you to them for participating as well. Jeremy is the senior developer
and UX strategist at Mighty, and he's also a web accessibility expert. My words, not his.
(audience laughing) So he's going to tell us
today, teach us and tell us all about web accessibility, what it is, why it's important, and what
we can do to make sure that we're keeping our
website fully accessible. One last note, Phil Blau is here, and we're video-taping this presentation. So wanted you to know
that that is happening, but also so that, for your own benefit, and for anyone who is
unable to attend today, we'll be making this video
as well as the presentation materials available to
anyone as a future reference, or for those who were unable to attend. Now I'm going to introduce Jeremy. (audience applauding) - Thank you, Jason. Yeah, so like Jason
said, the team at Mighty, and Jason, and Craig, and
the web communications team have been spending a lot
of time over the past several months working on
the accessibility measures that I'm gonna describe
for the hope.edu site. I wouldn't be surprised
if for some of you, or even many of you,
that web accessibility might be kind of a new thing. So by the end of this talk, you'll know what web accessibility is, and how to incorporate it
in your day-to-day basis. Oops. There we go, specifically I'm gonna talk about the physical and
cognitive differences that we enable with accessible design, and types of assistive
technologies and accommodations that many people rely on, right. So I'll cover some terminology
that you'll likely hear, and finally I'm gonna
teach you how to create and maintain accessible content. So we've set aside some time at the end of this talk for questions, so as I'm introducing and
going over these topics, just make note of any
question that you may have, and we'll make sure that we
can get to that at the end. Cool, so what is web accessibility? Very broadly speaking,
accessibility on the web means the degree to which a site's content is available and functional. But accessibility feels
bigger than that, right? You may have heard terms
like WCAG, or screen readers, or alt text, or conformance. So let's figure that
out, and let's figure out how each of us, no matter
what our role is, can and does play a role in making the
hope.edu website accessible. But first, some context. 56 million Americans,
this is roughly 19% of the US population, report having
some type of disability. 38 million of that number report
having a serious disability and according to the National Center for Education Statistics, over 11% of post-secondary students
report having a disability. So what constitutes a disability? There are five types of physical
and cognitive differences that we enable with web accessibility. Web accessibility enables
people who experience vision differences, this
includes people with blindness, low vision, color blindness,
age-related degeneration, and even temporary conditions. Web accessibility enables
users to experience auditory differences,
this includes people with some form of hearing
loss, including deafness. Web accessibility enables users who experience motor impairments. This would include people that may have limitations of muscle strength or control. This can include things like involuntary movements or paralysis. This also includes joint disorders, things like arthritis or pain
that would impede movement. Web accessibility enables users who also experience cognitive differences. This refers to any kind
of problem, understanding, remembering, or concentrating on content. This includes people that
are on the autism spectrum, have lower literacy, that are dyslexic, experience ADD and ADHD. This also includes non-native speakers and situational or temporary things, like people who are extremely
tired or under stress, or even in loud or hectic environments. Finally, web accessibility enables users who experience vestibular
and seizure disorders. The most common vestibular uh, excuse me, the most common seizure
disorder is epilepsy, and someone with a vestibular disorder can experience vertigo, dizziness, nausea, and motion sickness just
from using a website or app. So these are people
that are being excluded when we don't make the
sites, our sites, accessible. We're talking about millions of people, and over 11% of students. People who rely on us to
deliver a site that they can use by accommodating their
needs, and by supporting the assistive technologies
that they rely on. The good news is that this
is doable, and even better, making websites accessible
makes them more usable for everybody, regardless
of their situation. So let's take a look at some
common assistive technologies. But first, an assistive
technology is a thing like an app or a device, or even a plug-in that people use to navigate
the web and consume content. One of the most common
assistive technologies for people with access
needs is a screen reader. As you have probably guessed,
a screen reader reads the content of a page or a
screen, but more importantly, they're able to look at a
website's code and structure, and by doing so, they're not only able to communicate the words on the page, but also the hierarchy and
functionality of that content. I recorded a screen cast of
the existing hope.edu website being announced by a screen reader. I'm gonna play it on the next screen for about a minute and a half, and it's gonna read from
the student body page. Pay attention to how it
moves across the screen, and the types of phrases and
words that it uses to sort of indicate element types,
functionality, and settings. - [Screen Reader] Student
body vertical line admissions, web content, link, skip
to content, visited link. Hope College, The Hope College logo. Heading level two, site navigation. Search term, search
term, edit text, search. Search button, list six items,
visited link, academics. Visited link, admissions,
visited link, research. Link, arts, visited link, campus life. Visited link, athletics. Heading level two, breadcrumb navigation. List three items, visited link home, visited link admissions,
student body slash. Visited link admissions office. Heading level one, student body. Students who attend Hope
College come from a wide array of backgrounds and locations,
as Hope continually aspires to provide real-world global perspective. These students are academically driven and work closely with top
educators in their field. The result, high retention rates and success after graduation. Hope is not just a
place, it's a community, and it's the people of
Hope who'll recognize all the qualities that
make you an individual. Here at Hope, we desire you
to grow as a whole person, academically, spiritually, and socially. Whether it's hanging with
friends at one of the regular. Link, student activities committee. Events, participating in
collaborative research with a professor, worshiping with
1,000 of your peers at the, link gathering, or just hanging
out in downtown Holland. Hope is ready to meet you where you are and help you become the
person you want to be. A Hope student plays the violin during our annual Christmas Vespers service, image. Oh, and if you're looking
for facts and figures, you've come to the right place. Heading level two, our student body. Row one of seven, column one
of two, total enrollment. Column two of two, 3,150. Row two of seven, column one of two. Males, full-time, column two of two, 1,282, row three of seven,
column one of two, females. - So hopefully you could
hear that screen reader announced not only the
content of the page, but also the functional aspects
of the student body page. Things like buttons,
links, the navigation, images, and even the
table at the very end. So screen readers rely on structure that gets added to the page,
and without that structure, it would be unable to clearly
describe the element types and functional aspects of that page. So that was actually
a pretty good example, but we're gonna learn later how each of us can author content and use built-in tools in a way that optimizes
them for screen readers. Okay, individuals that
experience permanent or temporary mobility
differences often rely on methods to navigate websites that
accommodate their differences. This could include joysticks, switches, and even voice commands,
but the most common method for navigating is probably
using the keyboard. So to get a better understanding
of what that looks like, I'm gonna demo the REI.com website. So this site does a really good job of highlighting the
current active element. It also does a really
good job of maintaining a logical sequence as it navigates throughout the page and
throughout the content. So as you can see, it
highlights the current element and it actually navigates in what we sort of perceive as that logical order, from top to bottom, from left to right. So this is a really good
example of what it looks like to have a site optimized
for keyboard navigation. So as we saw, assistive
technologies can aid in navigating websites
and consuming content, but by default, they aren't
able to assist in everything. The majority of accessibility
accommodations required are covered by what we
add to the Hope website. So how do we do this, and how
do we know where to start, and how do we measure success? The Web Content Accessibility Guidelines, also known as WCAG. This is the current legal
precedent for applying the Americans with
Disabilities Act for websites. Created by the World Wide Web Consortium to provide a single shared standard for web content accessibility
that meets the needs of individuals, organizations,
and governments. Now WCAG has three levels,
indicated by A, AA, and AAA. A, being the most general, up to AAA, being the
most specific and strict. The version and level of Web Content Accessibility Guidelines
that we will adhere to is AA, which is the current legal precedent. Since the guidelines are
on their second version, this makes up the term WCAG 2.0 AA. So how do we make our website
conform to these guidelines? WCAG is organized into four principles. Big picture themes, stating
that content needs to be perceivable, operable,
understandable, and robust. So what do those mean? Perceivable means that no matter which senses people have access to, that they are able to consume content. Operable means that no matter which senses people have access to, that they are able to interact with all of
the elements on the site. Understandable is that the
content and interactions on the site are not beyond
the user's understanding. Robust, that means that
the site can be used with a variety of assistive
technologies and devices. Now those 12 principles are
organized into 12 guidelines that address issues particular
to people with access needs. Those guidelines have
specific testing criteria that describe how to
meet those access needs. In total, there are 61 success criteria, and meeting all 61 means that we have a WCAG-conformant website. So I want to take a
moment to briefly preview some of the updates to
the hope.edu website. These are things that the
team at Mighty, and Jason, and Craig, and the web communications team all worked on over the
past couple of months. We used WCAG to sort of guide
the decisions that we made, so I want to just sort of demo this. Here it is, this is a
beta version of the site, so please excuse the placeholder text. Take note of a couple of things
right off the bat, right. We updated the colors
to achieve the necessary level of contrast for users
with vision differences. We also optimized for keyboard navigation. So we made sure to draw
really good attention to what element currently has the focus. We introduced some
scrolling considerations that would be in the sort
of group of three features, just below the banner, it's
gonna get to it in a second. Previously when we would
navigate to those features with a keyboard, it was
kind of a tough experience. So we made sure to pull those
out and really feature those in a way that keyboard navigators would easily be able to
consume that content. Something also you might
notice is that we used, we noticed that color was being used to sort of describe and
inform the information. On these news cards and
on these event cards, the departments were indicated by a color. For people with vision impairments and color blindness specifically,
those colors sort of bleed together and kind of
get lost in the shuffle, and so as part of the updates, we added the department
name to these cards so that we're not relying
on that single source of color being the only way to inform. So a lot of the work that
we did on the new version was to the actual code
of the website, alright. While these changes consisted
of substantial changes, really only a couple of
people can implement them. So you might be asking yourself, what's left, and where do I fit in? So even when all of those
changes are implemented, the hope.edu website is at
risk of losing conformance with any and every change that
we make as content creators. Every time we update a blog post, every time we add an image or
a link, anything gets added, it can put the site at risk
for losing conformance. But don't worry, because
I'm going to show everyone how to create and maintain
accessible content. Alright, here are the six areas in which content creators can affect
accessibility and conformance. Images, most pages, posts, and events will contain images, okay. Images lend context and
aesthetics to the content that we publish, but before
I fully cover images, I want to introduce the concept
of single-sense content. Basically means that content that can only be consumed
via one sense, right. Images can only be seen,
audio can only be heard. Text on the other hand, text
can be seen on the screen. Text can be heard through
a screen reader, and text can even be felt with the
assistance of Braille displays. So it needs to be our
goal to sort of identify and augment this content
that can only be experienced with a single sense, and here's how. So since text can be
experienced via all three of the web-available
senses, now thankfully, taste and smell have not
made their way into HTML yet. So text is the best way to make sure that our content can be consumed by everyone. So for images, the most common way to do this is through alt text. I found that for some
people with some familiarity with accessibility, alt text
tends to be the one thing, or one of the first things
that they think about when we talk about accessibility. Basically it's a way for the single sense, that visual-file format
of images, to not only include information about
the contents of an image, but to tie that description
directly to the image file. For users that rely on screen readers, this alt text is crucial for
understanding the information and the context
communicated through images. Missing or incorrect alt text is one of the most common errors that I encounter when checking a website's
conformance to WGAC. So every time you add an image,
you have to add alt text. Thankfully, OmniUpdate provides a way for us to include alt
text when adding an image. OU calls it a description, and when OU adds that image to a page or post, it formats it so that the
contents of that description field get directly tied and
linked to that image, and then are communicated
via assistive technologies. So, we know that we need
to include alt text, we know how to include alt text, so what makes for good alt text? Alt text should be
concise and descriptive, and more than just describing the image, the alt text should convey the
meaning of the image, right? This meaning could be
practical, emotional, or both. The alt text should describe
the subject of the image, be it a person, place, or thing, and it can describe an action
taking place in the image. So if there's something happens
that's key for alt text. It should also describe any
emotional content in the image. Further, we want to provide
the same information a sighted user would get
from looking at the image. Also, context matters when
writing successful alt text. What type of page is
this image gonna be on? What's the content before
and after this image, and what connection does this
image have to the content? Finally, who's the
audience for this content? Is this for a page intended for students? Is it intended for parents or faculty? The context and the audience guides the alt text that we will author. Some important notes
about authoring alt text. Avoid including the phrase image of. This is redundant, assistive
technologies will communicate that the content or element is an image. As we saw on the student
body screen reader demo, when it encountered that image, it read the alt text first,
and then said image afterwards, so alt text and assistive
technologies already have that built in, so we don't need to
include image of, or photo of. For logos, you can include
the organizations name followed by the word logo. So for example, the Hope College logo. You should avoid images of just text. So if you can't, you're
going to need to transcribe all of the text from that
image into the alt text. Charts and graphs, they
have a bit more complex alt text requirements, right. You may need to transcribe
all of the content, if it's not already on
the page in another form. Now if the chart is just being included to sort of sell or present a single point, something like sales
increased 50% last quarter, you can use that for the alt text. Finally, decorative images are allowed to have empty alt text,
but be wary of this. Our goal is to communicate to all users the same level of information and emotion, and if a specific image isn't
communicating information or emotion, you should ask yourself, should it even be included on the page? Now if it does, if it
needs to be on the page, it's fine to leave that alt text blank. So I'm gonna demonstrate
my thought process for authoring alt text
for a couple of images. Let's consider that this
image is being proposed for a page for prospective students. I wouldn't be surprised to
find that maybe on another website, alt text for an
image like this could be something like soccer game,
or crowd at soccer game. I mean it describes the image, but it doesn't really do
a very good job about it. So here's a version that
I would likely propose. So a large crowd of excited
fans wearing team colors, standing up and cheering at a soccer game. Little bit more of a boast, but it describes sort of
that weight and that emotion, and the energy behind that image. So I chose words like excited
and standing up and cheering to really sort of paint the picture of what the emotion and the
weight behind this image is. Here's another one,
actually, why don't we all sort of just take a moment and think of how we might write alt
text for this image. Alright, so again, I
wouldn't be surprised to find on another website, alt text
for this image that says something like photo of torn
down house from tornado. Yes, it describes the image,
that's what the image is, but it doesn't really
convey any of that meaning. My take would be, a young
woman comforts a man in front of a house and
automobiles destroyed by a tornado. Alright, the focal point
is the couple, the woman comforting the man, and
the destruction behind them sort of sets the stage
and sort of embellishes on what the sort of emotional
meaning of this image is. So it's that kind of thought process that I apply when authoring alt text. Most of the content on our
pages is gonna be text. So let's learn how to optimize this for people with access needs. Here's how we can do that. Write simply and clearly, create
structure with our elements use the built-in features
to decorate and style text, avoid able-assumptive language,
and we need to be concise. So let's dig in to writing
simply and clearly. First, we need to keep writing
at an appropriate level. The recommendation is no higher than an eighth-grade reading
level for general audiences. For something like highly
technical content meant for specific audiences, you'll
need to use your discretion, but for just general
pages, general audience, we want to keep it at
an eighth-grade level. I can't stress enough from a
user-experience perspective and from an accessibility perspective, how important it is to
get the reading level to that appropriate level. This is especially
important for individuals that are non-native
speakers, or have dyslexia, or other cognitive differences. Now one way that I use to check
the reading level of a page is using the Hemingway Editor website. So Hemingway is a free website,
located at hemingwayapp.com. This tool allows you to
paste in a block of text. Here I dropped in a short passage from a Sherlock Holmes
novel, and as you can see, this passage was calculated at
a fifth-grade reading level. That's in the top of the page. So what I love about this tool, is that it highlights the
areas where individuals may struggle with higher reading levels. You're able to make
edits and instantly see how those changes affect
the reading level. Now behind the scenes,
the Hemingway Editor uses the automated readability index to calculate the grade level. Obviously if you have
another preferred tool, or you already have an
existing workflow, use that, but for accessible content, we need to aim for that eighth-grade
reading level or lower. Alright, another way to optimize our text is to create structure with
headings, lists, and media. Long passages of text can become overwhelming to some individuals. People with dyslexia and
those on the autism spectrum, especially experience this. People that rely on screen
readers also prefer to have long pages broken up by
headings and other elements, and this is especially
convenient, because screen readers allow those users to quickly
jump from heading to heading. Here's a representation of what can happen to some people with dyslexia. Sometimes with long passages of text, they experience this warping effect. So even small steps that
we make just by breaking up long passages with headings,
an image, or something like that can make a big difference
to a big group of people. Another way to optimize our
text is to use OmniUpdate's built-in formatting options to sort of define different content
elements, like headlines. As I'm sure you're aware,
OmniUpdate provides a pretty robust editor,
but with that flexibility comes the opportunity to
create non-accessible content. Using only the built-in
features will ensure that the structure of
your content is optimized. As we saw in the demonstration earlier, the screen reader is able to announce when a specific piece of
content was a headline, alright. So just using visual
tools to make text bigger, or bolder, or uppercase,
or something like that, a screen reader's not gonna know that that's actually
intended to be a headline. So for the people that rely
on that extra accommodations and that structure that's sort of baked-in to how a screen reader
announces that content, be sure to use the built-in tool. Also, when choosing a heading
as a formatting option, we need to make sure that
our headings follow an order, and are not chosen based
on visual style, right. So don't choose a specific heading because you like how
the way that it looks. Heading numbers reflect relationships. So a heading number two will belong to a heading one above
it, or a heading three is gonna belong to a heading number two. Lastly, don't skip levels. So for example, don't author content that only has that really
nice, big heading number one, but then use it as a heading number three, because you like the way it looks. So don't skip over that
number two heading. Another way to optimize
our text for accessibility is to avoid able-assumptive language. The green button, the
upper left-hand corner. So when announced through
a screen reader, the button isn't green, and there is
no upper left-hand corner. Also we need to be mindful
of verbs that assume ability. So if somebody is
navigating via other means, other than a mouse, like a keyboard, or voice-controlled
assistive technologies, they won't be clicking. Be concise. Consider that individuals
may rely on additional accommodations to experience the website, and that those accommodations
may make their experience take longer than you may realize. Now it's not uncommon for individual pages to take well over several
minutes for a screen reader to read the entirety of the page. Users relying on that, they
can't skim through the content. They can't just you know, scroll
past something, so lengthy passages of text can be
cumbersome to get through. This was also a great
consideration for users with cognitive differences, too. So be mindful of the amount of text that you are adding to a page as a whole. Another type of content that
we can optimize is links. The infamous read more link, right. I'm sure we've all seen this. Some of us may have even
added this to a page. Aside from links like this not really doing us any search engine favors, changing these will
benefit users with autism, users with cognitive
challenges, but this can be especially important for people
that rely on screen readers. We have to make sure that the destination, the action, or the result of interacting with an element is clear to our users. So here's the reason why. Many screen readers provide a tool that extracts all of the
links out from a single page, and then places them in this menu. This tool allows them to quickly navigate between those links and
interactive elements, but as you can see, when that happens, it doesn't receive the context
surrounding those links, only the actual link text. What's worse, is that some screen readers even alphabetize this list, so we can't even rely on
the natural order of a page. So take a look at the image. Where do any of those
read more links take you? So this is why we need to remove those. Another part of good link text involves eliminating repetition. While these links on the screen are more descriptive than
the previous read more, the user has to listen to
the entire link being read, because the only distinguishing piece of information
is that very last word. So I'm gonna demo fixing
some example links, alright. Hosting an event, learn more
about our catering options. Doesn't seem too out of the ordinary, but I think a better example could be, hosting an event, learn more
about our catering options. It's the same text, it's the same copy. I only switched what piece of text and what phrase was chosen as the link. If we think back to
that screen reader menu, if we were to remove
the surrounding context, catering options is much
more clear than learn more. Here's another one,
supercharge your free time. Join us for the first ever Hobby Fair to find your next great passion. Hands-on workshops, demonstrations, and giveaways, learn more. So take a second and think
about how you may optimize this. Here's what I have. This one didn't require
much editing, either. I removed the learn
more from the very end. Once I selected Hobby Fair
as my link text, right. If we think about those two in comparison, learn more as a link text,
and Hobby Fair as a link text, displayed in that screen reader menu, Hobby Fair is incredibly
clear and very descriptive. I know where I'm gonna land right, if I interact with that link. Alright, we'll do one more. So think about how you'd change this example to make it more clear. Alright, here's what I have. So for me, this one required a minor edit. Even though Facebook is more
descriptive as link text than read more, once it's removed from the surrounding content, it
loses the clarity, right. Facebook for what, Facebook.com, Hope's Facebook page, my Facebook page? We're not gonna be able to know. So I chose to make that small edit and include Facebook with
the fundraiser's name, which did require a small edit. So I came up with the link text of being Books for Tots on Facebook. Books for Tots on Facebook is incredibly more clear
than just Facebook alone. Alright, lists. Lists are incredibly helpful for users with cognitive challenges
and people with autism. They also create structure that
I covered in previous steps, and screen readers really
are able to shine with lists. They're able to announce
the length of a list, and they're able to
identify each bullet point. You may not have caught it, but in that first demonstration, it announced the site's
navigation as a link, and it said link group six items, and so there were six navigation
elements within that list. For creating lists, we need to be sure that we use the built-in
formatting in OmniUpdate. If we try to fake a list
by doing line breaks and hyphens or dashes, or
even like the asterisks, or we find like a little bullet icon, this is gonna confuse screen readers, because they rely on that
sort of baked-in structure from using the built-in formatting tools. A couple more notes. We need to choose the type of list based on the need, not the visuals. So if we think about bulleted
lists with the circle, and numbered lists coming with numbers, bulleted lists are great for
when order is not essential, but numbered lists should be
used when the list describes a specific and ordered sequence. Also, we should start instruction lists, the list items, with action verbs. Things like write, check, test, make. This clarity really helps people
with cognitive differences. Remember how I said optimizing it for accessibility helps
everyone, here's an example. This is a recipe for cooking a steak. I placed action verbs as the first word, so we see things like place
the steak, and whisk together, and pour it over, and preheat the broiler. These instructions are incredibly clear, and I have a pretty good
idea of the entire step just based on that first word. So compare that to the original recipe. Which one would you rather be standing in front of a hot stove or
grill, with ingredients? I would certainly prefer the other one. So this is the power of lists, right? Any time you can break up
long passages of content into manageable items, it's gonna help many of the individuals
that we've discussed. Alright, the next content type that we need to consider is media. So another kind of text
alternative that we can use are captions and transcripts. So for individuals with
hearing differences, this is vital that captions are provided. There are also users that actually prefer to read the transcript or captions, because they can find videos
distracting or disorienting. So for hope.edu, all
videos will need to have text alternatives in the form of captions. This even means videos that
are embedded into Hope pages. Basically, if it is on
your site, it is your responsibility for providing
accessible accommodations. Now from a workflow perspective, here are the caption requirements. All videos that go on
the Hope YouTube channel are now required to be captioned, and all videos that are
embedded into a page must be on the Hope YouTube channel. So if you have any questions
about this workflow or how this may affect you,
reach out to Jason or Elizabeth at public affairs and marketing
with any questions, alright. With a bit of effort, assistive
technologies can be very good at interpreting and
communicating content on web pages. We've covered exactly how to optimize content for them
in the previous steps. Often though, other forms of
embedded media, like PDFs, don't have the same authoring
and accessibility features. So it's our goal to avoid limiting content to only embedded files. Basically, if you can add
the content to a page, do so. Alright, and visual design. OmniUpdate does limit a lot
of the visual design choices to preset options, and this
helps us maintain conformance, however, visual design choices have a big impact on accessibility. So I want to talk about some of the considerations surrounding
accessible design. For this website, this
would apply to any time that you're creating graphics,
charts, illustrations, that are gonna appear
on the hope.edu website, but you can also apply these
same considerations to things of your own, like lecture
slides and presentations, and basically anything else
that you're gonna create to help them become more accessible. So contrast, right, we saw that change in the new version of the Hope site. We did this to achieve the
needed amount of contrast. So this is incredibly important for people with vision differences. Now contrast ratio is how we
numerically define the amount of contrast between an
element and its background. Now WCAG 2.0 requires that
normal, paragraph-sized text have a contrast ratio of
4.5 to one, and larger text only requires a contrast
ratio of about three to one. So here's an example of that
in practice, this first line is the darkest black on
pure white background. That combination gives us
a 21 to one contrast ratio, and the last line is the
lightest gray that we can put on pure white background to
maintain that WCAG conformance. That one has a 4.5 to one ratio. So how do we determine whether or not the designs that we have
created have enough contrast? There's a couple of ways. To test, I like to recommend a website called accessible-colors.com. To use this, what you'll
need is you'll need to know the color of your background
and the color of your text, and there are form fields that
they have you input those, and then it'll output the contrast ratio. It'll even give you suggestions if you don't have quite enough contrast. Maybe it'll suggest
lightening the background, or maybe darkening the text on the page. Now for the designers, there
are plugins that we can add to Photoshop or other tools
that we use that allows us to test as we're building
and as we're designing, the contrast ratio of the
background and that element. So part of the work
that Mighty did recently required that we take a
look at all of the colors that were being used on the website. We needed to make sure that we had achieved and maintained the
sufficient contrast ratio requirements to meet WCAG requirements. Unfortunately, the Hope
orange doesn't have enough contrast ratio when used
in normal paragraph sizes, so there were buttons that
were used in the sidebar, there was the header that was
orange and it had white text. None of that met the sufficient
level of that contrast requirement, so that
precipitated the change. As you saw in the demonstration earlier, there were other color changes that we incorporated into
the new site as well. Those were all based around
maintaining the brand colors, but achieving that contrast ratio. So for the rest of the
colors on the screen, these were sort of used to indicate the individual departments. Some of those didn't have
enough contrast ratio either, so they needed to be updated. Okay, another thing to consider is to avoid using color alone to inform. I talked about this a little bit earlier. People with color blindness are
especially impacted by this. So what do I mean by color alone? Here's a pattern I'm sure
we've all seen before, it's a form, and this form has an error, but the only way that that error
is being communicated to us was by changing the background and the color of that form field. There's no error that
says you didn't fill out the email address right,
or don't forget to do this. It's just changed from white to red, and then the successful
ones are that light green. This is what a person
with color blindness sees. That once red error field, now looks exactly the same as the rest. Without an error message
instructing them of a problem, they may not ever be able to fix the problem, and then submit the form. So while this example is of a form, where you might need to be
mindful of this in your own work, is where you're creating charts,
graphs, and illustrations. So remember, when we are
trying to convey information, we need to make sure
that we're using methods beyond color alone, and that doing so will help users with low
vision and color blindness. Now I chose these colors,
and I ran them through a color blindness simulator. I mean that is a very vibrant red. That's a stop sign, race car red, and it's a very green, green. But applied with a filter
applied over it, sort of simulating a type of color
blindness called protanopia, all three of those colors
looks exactly the same. So keep that in mind when
creating these graphics, illustrations, and charts
that you want to use in your presentations
and on the website, okay. So I applied that same
color blindness filter to the old version of the
news section on the home page. The department colors were being used as a way to identify what department
that news post belonged to or what department that event belonged to. But as we can see, with that
same color blindness filter applied, you really can't
make a distinction very well between the arts and the
athletics, and even the academics and the research starts to kind
of blend and bleed together. So here's what the new
version of this site does. We've added the department name to the very top of that card, so even users with low
vision and color blindness are able to know that
the academic department has a pretty busy schedule, right. So while using color to
sort of convey meaning and relationships is important, just make sure it's not the
only way you're doing so. Okay, so following
these tips will have you creating and maintaining
accessible content. Now the last step is to
make sure the content that we've created or updated
meets WCAG conformance. So how do we test? We test with a combination of automated tools and manual checks. Now thankfully, OU provides
us with the ability to run an automated test, and to check the conformance of a particular page. Even better, we can do this while we are editing and adding
content, and here's how. While editing a page, we're
able to select the Page Check tool, and doing this will
help prevent publishing a page that is not accessible
during the authoring process. Here's a demo. So it looks like we have an error, and it is an image that has no alt text. So like I mentioned earlier,
that's a pretty common error, and we've learned how to fix that. So you're encouraged to
try and fix the problems as you discover them, but
if you're not sure how, be sure to notify the
web communications team about the issue that you are observing. While the OU checker is
incredibly convenient, for 100% conformance, the work doesn't
end at the OU page check. Even though it's
integrated into the system, it's unable to catch all
of the potential errors that we need to prevent to
maintain WCAG conformance. Even the best automated
checker is only ever gonna be able to catch about
40% of possible issues. Here's a quote from the OmniUpdate blog. "While there are many
great tools out there, "they can't catch everything." And here's a quote from
W3C, the creators of WCAG. The full quote reads,
"There are automated tools "that help with evaluation,
however no tool alone "can determine if a site
meets accessibility standards. "Knowledgeable human
evaluation is required "to determine if a site is accessible." This means that there
needs to be manual testing, as well as the automated
testing that I just covered. So what about that 60%? That's where the manual testing comes in. So here's a checklist
of things that require, as W3C put it, knowledgeable
humans to check. Conveniently, these tie in to
the steps that we just learned for creating and maintaining
accessible content. So why automated checkers
are unable to determine if our images have high-quality alt text, we know how to write
good quality alt text. We know to convey both meaning and emotion as we author that. While automated checkers
are unable to determine if our text is clear,
concise, and well structured, we know how to write
clear and concise content, and we know to use the built-in
OmniUpdate tools to add structure that is optimized
for assistive technologies. Automated checkers are unable to determine if our links have high-quality text, but we know how to
write high-quality text. We know to make sure that the destination, or action, or result needs to be clear, even when removed from
the surrounding context. Automated checkers are unable to know whether or not our videos have captions, but we know that all of our videos added to the Hope YouTube
channel must have captions. Lastly, while automated
checkers are unable to determine if we're using color alone to inform, we know how to create images
that use other elements other than just color as a
means of conveying information. So it's important that
before you publish content, to manually double-check
everything on this list, because we run the risk
of publishing content that is not accessible and not conformant. Even though we can't future-proof
every part of our website, we now know how to create and
maintain accessible content. We're able to combine automated
testing and manual checks to validate conformance
of the hope.edu website. Before we wrap things up, I
want to share one final thought. There is no normal, we all
have different abilities and different levels of those abilities. We are the gatekeepers of
access, and our environments will either create or remove
barriers for millions of people. Hope.edu is our environment,
and it's within our power to remove access barriers
for our users, thank you. (audience applauding)
