[Dan Tuleta] Okay so I'm showing it that it's two o'clock. So I think we should get started.
Thank you everyone for joining us again for another rendition of Equidox Webinar Wednesdays.
This month we are talking about Going Beyond the Checklists and trying to simplify
WCAG. As always my name is Dan Tuleta and I'm a sales engineer here with the Equidox team. If you
have any questions related to this webinar or if you would like to have an additional consultation
or meeting with us to discuss your documents... your accessibility challenges... please feel free
to reach out to us at EquidoxSales@Onixnet.com. We also have our website www.Equidox.co and we're
very active on all of the social media networks. So please feel free to connect with us there.
Now before we get before we begin, I just want to mention our parent company Onix Networking.
Onix is headquartered in Cleveland, Ohio and we are primarily known as a pro... as
a premier partner of Google. So we are a cloud consultancy that kind of, across the board,
offer a lot of different cloud consulting, cloud consultancy services, and solutions. And Equidox
is a division within Onix. So our mission here at Equidox is to ensure that digital
information reaches everyone via accessibility solutions. We have a PDF remediation software
called Equidox and we also offer a variety of services primarily around PDF documents.
So just a quick slide here to mention some of the organizations that we work with.
We cross over many different verticals and we work with many different sizes of organizations.
So no matter how big or small your company or organization is, we are here to help. So please
feel free again to reach out to us to connect and talk more about your accessibility needs.
Now before... if you've joined us before you know that I like to talk for the duration of these
webinars every month. So we're gonna give you a break from my voice for a few minutes here and I'd
like to introduce our Director of Accessibility Ryan Pugh. Ryan directs our Equidox remediation
team. He's also an accessibility consultant and he can provide a lot of services around
website testing, document remediation expertise, and a number of other areas
within digital accessibility. Previously of the National Federation of the Blind,
Ryan was an Access Technology Analyst for many years. And so Ryan, I'm gonna just hand it over
to you to kind of go through these different topics that we're going to talk about today.
[Ryan Pugh]
Great, thank you, Dan.
When we're talking about WCAG and creating accessibility on your content,
your goal should always be to create an equivalent experience when possible. Whether that's creating
something brand new from scratch, a new document or resource, or remediating one for accessibility.
The WCAG guidelines tell us that all users should have access to the same information. And that that
experience should be the same. That's not always possible. I have here an example of the Mona Lisa.
And as marketing people and content creators can tell us, a lot of time and effort is spent
crafting an image or a document making it eye-catching and intuitive... clear...
easy-to-use... memorable... persuasive. When you're engaged in writing, books
are drafted redrafted, proofread, drafted again, rewritten for clarity, for density.
If you're creating forms or questionnaires, we almost always see at the beginning “this form or
survey will take two minutes or less.” There is clear intent that it be clean, easy, and usable.
When you're deciding on a remediation approach,
you should be considering all of those factors into how you're making your content accessible.
It's not always fully possible to create an equivalent experience. It's difficult to
evoke an emotional response through alt text.
Or to communicate human emotions on a face through the written word alone.
I've seen large studies that have been conducted and in-depth analysis of this particular painting,
which have concluded that Mona Lisa’s smile is 83 percent, happy nine percent disgusted, six percent
fearful, two percent bored. I'm not certain where those numbers have come from exactly. I
don't know how they've made that determination. When I look at this I see a fancy piece of art.
If the intent of your usage of this particular picture is to
communicate the complexities of human emotions, you should be considering
when writing your alt text for the image or the structure surrounding the image,
all of the range of human emotions that can be communicated. If your goal is simply to
present a fancy piece of art, then you can begin and end with just “fancy piece of art.”
(can we move to the next slide, please)
Accessibility is about function and usability, not checklists. This is a
difficult topic to understand for many people. When tasked with making something accessible,
what is usually presented is either a list of guidelines or worse,
a checklist of things you have to do to make your document or your content accessible.
And that can serve as the starting point for a remediation effort or an accessibility effort,
but should not be the total end goal. And we've got a list of examples here. The checklists are
the start for items such as “elements being completely skipped,” “accuracy of heading
structure...” “Whether there's alt text,” “validity of links,’ “logical reading order…”
We'll be going into a little more depth on most of these throughout the course of this presentation,
but just to dig in on that first one a little bit.
A checklist may tell you that all content has to be tagged, or it may tell you that all-important
content may be tagged. But that leaves room for human interpretation as to what might be
important. And it may lead to people creating a cluttered experience where decorative images or
purely visual objects are also tagged or exposed
when they aren't actually providing any meaning or usage to an end-user.
It is often very easy to check off the boxes within the checklist without filling
fulfilling the intent... without creating something usable, intuitive or clear.
Not all big bolded text is a heading. Not all reading orders are fully logical for any user.
And some tooltips are open for interpretation. A date next to a form field is clear intent
but there may be specific syntax or structural requirements there
that aren't communicated by the word “date.”
(Can we have the next slide, please)
The Web Content Accessibility Guidelines. These should be the starting point of your accessibility
journey, not the end goal. And as mentioned, much confusion arises because WCAG can be
presented purely as a checklist. The WAI has a list of each of the criterion in order
and each of them has subsections that contain lists of sufficient techniques.
And what really matters when you're trying to understand WCAG
relative to the sufficient techniques for the checklist mentality... Each and every one of
those pages begin with one or more paragraphs describing the intent of success criteria.
Those paragraphs will tell you what you're supposed to be doing
whilst the sufficient techniques are indicative examples of how to do it.
The intent of success criterion for WCAG 111 tells us that
all non-text content should have a text equivalent.
And this is easily interpreted as placing alt text onto images and tooltips on the form fields.
But that frequently leads to an experience which is not intuitive, and to materials not
usable. A classic example of this would be a complicated infographic. It may contain
hundreds of succinct pieces of information. It may be a singular graphic which contains
10, 12, 100 different sub-images all of which are... all of which communicate
their own unique piece of information. And when analyzing this visually, you can move from
one section of an infographic to another. You can analyze it piece by piece.
If you follow the written word of the checklist that “all images must have alt text,”
you would end up creating a singular alt text and place it on the entire complicated infographic.
And this would not result in an equivalent experience. Because
alt text is read out by screen readers as a singular block of text, without formatting.
It can't be broken into subsections of its own. You can't move directly to
one particular eye-catching piece or another. In those cases, fulfilling the intent of providing
text alternatives for all information would be to split that image up into multiple images,
providing unique and distinct alt text for each of them, so that each individual
piece of that information is communicated uniquely and can be navigated to with ease.
We have one of my favorite quotes here on the slide. “The power of the web is in its
universality. Access by everyone regardless of disability is an essential aspect.”
If you begin with that mentality, trying to ensure that everyone can
access the information in an equivalent way, or as close as possible, you'll have
much higher levels of engagement and much higher levels of understanding from diverse groups.
( move to the next slide, please)
All of the guidelines within WCAG are broken down into one of four pillars. Perceivable, operable,
understandable, and robust. Okay, guidelines success criteria are organized around the
following four principles which lay the foundation necessary for anyone
to access and use web content. Anyone who wants to use the web must have content that is perceivable.
Information and user interface components must be presented in ways that they can perceive.
Operable: user interface components and navigation must be operable.
Understandable: Information and the operation of user interface must be understandable.
Robust: Content must be robust enough it can be interpreted reliably by a wide variety of
user agents including assistive technologies. That probably sounds like a lot of jargon. We'll dig
a little more into these in turn. (switch to next slide)
What is perceivable? Users must be able to perceive the information being presented.
It can't be invisible to all their senses. This one seems very intuitive and obvious.
Obviously, we cannot present information that can’t be perceived, and that leaves us with
a number of potential barriers when we're talking about disabled groups.
For PDFs, this means meaningful information cannot be hidden from assistive technology users.
You have to tag relevant content and, don't tag repetitive elements. Tag images that provide
information, don't tag decorative images. And all form fields must have tooltips.
Now what this really means is that once you've factored in the ways in which people
will attempt to access information, you should have that information be accessible through at
least one sense. A deaf person will be able to understand a sign language translator on a video,
whereas a blind person would be able to understand audio description. We bump into
greater barriers and greater thresholds for accessibility implementation when
we encounter a deaf-blind person who can't use either of these. And we should consider
combinations or confluences of disabilities when determining what is perceivable to who.
At this point, I'm not aware of any way to smell or taste the internet. If anyone
has any information about that please let me know! (move to the next slide, please)
Operable: users must be able to operate the interface. It cannot require an interaction
that users cannot perform. For PDFs, this means that embedded links must function.
Table of content links in larger documents must also function, and larger is normally defined as
20 pages or more. And all interactive objects must be keyboard accessible.
Users must be able to access, for example, form fields, with a keyboard. Now, this can
also create a number of additional barriers when we're discussing
what is or is not keyboard accessible. The intent of the success criterion is that
regardless of the interface being used, all information is accessible. And that
means certain functions are out of the realms of possibility
for users, depending on what system they're on, what resources they're using. At this time
it is not possible to execute a single right-click operation through a touch screen. Drag and drop
operations are still not possible through a GUI using a blow tube. And it is extremely
difficult for an amputee to simultaneously press the left shift and the number pad 5 on a standard
QWERTY keyboard. But we should be considering what people will be using to access the resources when
we are building out into points of interaction. (can we move to the next slide, please)
What is understandable? Users must be able to understand the information
as well as the operation of the user interface. And this one absolutely depends on the audience.
Your starting point here will be to ensure that the languages are correctly set. French text being
read in English or “Fringlish” is completely meaningless to both English and French users.
Some loaned words are going to be... are going to lose their meaning or lost in translation. “C’est
la vie” can easily be pronounced as “Sest la vye” by a straight text-to-speech engine. A piñata
has a similar barrier of bad pronunciation. A slang, jargon, or complicated terminology
or structure like legalese should only be used where it's necessary to communicate…
where that structure is necessary for the intended means of communication. Acronyms
without explanation should always be avoided, and once again tooltips for form fields.
I did a search on a Department of Defense website and found that there are 29 different definitions
for the acronym “ACS.” And whilst that may be easy and intuitive to identify exactly which one
applies to you if you are part of the armed forces in a specific division, somebody outside
reading that document is not going to have the context necessary to make that determination.
Does ACS stand for Airborne Control System? Auxiliary Crane Ship? Assistant
Chief of Staff? Air Commando Squadron? It's very difficult to tell. The real
barrier when it comes to understandability is identifying who the intended audience is.
Whilst legalese makes little to no sense to the average school child, somebody who is
an active practicing lawyer is going to have a relatively easier time navigating it.
And this comes back to that all-important intent mentioned earlier. Who do you intend to use it,
what is the expected knowledge or experience level of your intended user?
(can we have the next slide)
Robust: Users must be able to access the content as technologies advance.
This aspect of work is more for developers than content creators. For PDFs,
you want to make sure the content displays as authors intend. Actional elements function as
the author intends. Buttons, links, tables of contents should all function. And should all
perform their operations regardless of which mechanism you're using to interact with them.
And they should remain compatible with current and future browsers, web-enabled devices,
and assistive technologies. We've all... I'm sure we've all encountered the barrier of a web page
that says “for better usage move to our mobile version” or “to finish this try in our app.”
Asking people to change which system that they are using in order to access the information
or functionality creates additional barriers for everyone, but this is especially acute for
users of assistive technologies who may not have an alternative to their screen reader.
(next slide)
[Dan Tuleta} So Ryan, I think this is where I was gonna jump back in and kind of and talk about how
the four pillars of WCAG can kind of apply in a more practical sense to PDF documents.
And of course, mentioning our PDF remediation tool Equidox. To kind of just describe how
that tool can be used to make sure that all of your documents are
in alignment with the four pillars of WCAG to the greatest possible extent.
So one of the things that was mentioned before are skipped elements. So skipped elements. They
may fail an accessibility checker, but they may not. So this is one thing that I notice
in working with a lot of different PDFs on a day-to-day basis.. is there can be
corners cut in any sort of remediation or tagging process. Where entire chunks of information,
entire pages, can be completely skipped. Maybe they were determined to be too hard to remediate,
or maybe an auto-tagging process did not pick up that content for whatever reason. But it
is important to make sure that while you are remediating a document using a tool like Equidox,
that you aren't skipping over important elements that are conveying meaning to the end-user. So as
I said before these, skipped elements may or may not fail an accessibility checker. So when we talk
about going back to this reliance on accessibility checkers. So something like skipped content...
if that content is artifacted, it may be leaving important information out of the document for that
end user. Another component of PDFs is of course heading structure. So there are hard and fast
rules about heading structure as it relates to PDF accessibility. Now here on this slide... we have a
single-page document (and of course PDF documents can get much longer than one single page). So this
is a pretty low-level example but it does point out the difference in heading structure and the
difference in heading levels as they make up that heading structure. So the typical rule is that you
have one heading level one within a document. That is typically something that is on the
front page. It's usually in big bold font, but not always. That's why we're talking about the need
to go through these documents and look at them with some human interaction, and making sure that
you are actually, in fact, tagging the true heading level one and not simply relying on
“oh this is big bold font so everything that's big and bold font gets marked as a heading.”
The document title is not the same thing as a heading level one. That's another thing to keep
in mind. So there is a difference as it relates to PDF accessibility, and then of course there has to
be a hierarchical structure to the headings. So you have a single heading level one. Within that,
you have sub-categories of heading level twos, and within those heading level twos, you can have even
further levels of subcategories going all the way down to heading level six.
So you're building almost like an outline of the document. And this is used for navigation. So it
makes these documents operable by the end-user because then they can freely move about the
document and get to sections of information that they are really interested in hearing. So just an
example that I use on a regular basis, is if you imagine an entire textbook in a digital format.
Well, if someone needs to get to chapter 16, and a subsection within a subsection of that chapter 16…
The heading structure is what allows them to leapfrog past the first 15 chapters,
and then drill down within chapter 16, once they found chapter 16 in the heading structure,
and get to that particular paragraph or bit of information that they were looking for. We do have
an entire webinar similar to this on heading structure. So there is a link in the slide
deck which will be provided to everyone that is attending today. So if you'd like to talk more
about heading structure or learn a bit more we did do an entire webinar dedicated to it.
Now alt tex. So Ryan talked quite a bit about alt text. So, of course, the alt text must be
applicable to the content, and it should of course capture the intent or the message of the image,
and context of course always matters. So what we're looking at here in this little example
is a very complicated map of the New York subway system. Now depending on the context and the
intent of this image, that can really determine what you are placing in there for in alt text. If
the intent of this image is to provide navigation instructions for someone that is navigating the
very complex New York City subway system, that is quite an alt text that would be required.
You might have to describe different relationships between points, how far away distances are, where
each of these different stations lets out on the street… It's quite a project to try to describe
everything that is happening in this image. However, if this is just a tiny little thumbnail
image in the corner of a brochure that is sort of advertising the use of the subway system,
chances are it's not really intended to be used for navigation purposes. Therefore that can
change up your approach to the alt text, where you would simplify it and you might write just
“an overhead view of the New York City subway system” and keep it very simple, keep it concise
and just describe that there is a “high-level map of the of the subway system” and then you can
move on to other elements in the document knowing that the intent of that image was not to provide
turn-by-turn directions for an end-user. We do have another webinar as well and a blog related
to alt text so we will provide that link as well. It will be in the slide deck when you receive it.
So, links and URLs. Links of course should be interactive. They must have correctly defined
destinations they should indicate where their destination is leading and things like “click
here” or “contact us” are not particularly useful, because what are they clicking here for? And who
are they contacting when they click on the “contact us” link? So links should be unique,
and it should be very clear as to what this link is taking that user to.
Oftentimes there will be links within documents that will say “next page” or “previous page.”
But a link that says “link to page 27” is of course more useful than “next” or “previous
page.” If a user is looking at a list of all of the links within the document, and every single
page has a “next” and a “previous” link on it, that is going to be utterly useless to them,
as each one of those links is not unique and it doesn't actually take them to a particular
location that that is easily understood by them. Because every single link says “next”
or “previous.” So things like “links to page 27,” for example, are definitely more helpful.
Logical reading order is another thing that is critical in terms of PDF accessibility. Not every
page is going to be left-to-right, top-to-bottom. A very simple and easy easily understood flow of
that reading order. For example, newspapers or magazine articles, or you know tri-fold brochures
where oftentimes the cover page is over on the right-hand side when that document is viewed
in a digital format. So when you think about the logical reading order, this is an example here of
a very complicated-looking cover of a newspaper. So without a properly defined reading order,
a screen reader is liable to just read clear across left-to-right. There are four separate
articles here on this page, as well as, obviously, very large headings and titles at the top of the
page. So the order in which all of this content is going to be read cannot really be relied
upon unless you go through and set the proper reading order to read the far left column first,
then moving into the middle column, the middle section with that article, moving over to the
right to that third and fourth column after that. So going through a document and making sure that
you have set the proper reading order is is is truly critical for the usability of that document.
Keeping content together. Now when you're designing documents,
of course, not everything is going to be perfect. You might have to merge text, for example. So
multiple column splits, text running over onto the next page. You might have images embedded
within the document and the text needs to be sort of placed around it. Links can go across different
lines, and of course tables and lists and all different types of elements can be split across
multiple pages. So it's important to make sure that you are trying to keep this content together
with the use of the merge feature. Which is very easy to use within Equidox. So
that's just another thing to keep in mind, that if you have a sentence or a paragraph that runs
out of room in whatever column it may be and picks up in the next column or on the next page,
making sure that you group that content together is very helpful to an end-user. Otherwise,
it will be treated as two totally separate elements, when in fact it should be read as one.
Fillable forms. Of course, fillable forms are in a PDF format, they can be quite complex. But
all items should be interactive and the critical part of PDF forms are tooltips.
And tooltips should be very specific. So if you think of a form that is just asking you for
“name,” well whose name is it? the applicant's name? Is it their guardian's name? Is it…
which name is it? Is it the middle name? The last name? Middle initial?
Buyer name versus seller name? If you're assigning a purchase agreement, for example,
formatting needs to be specified within tooltips. So if you're asking for a date, are you asking for
the day-day, the month-month,year-year? Do you want four digits for the year instead of two?
Do you want the month before the date? So if you have people that are just able to fill out this
form without any specific formatting, then that can cause a lot of confusion for the administrator
who is actually receiving that form. Because someone has filled it out incorrectly because they
did not follow any sort of specific formatting because that document was not remediated and
that tooltip did not provide that context for that user who is filling out that form. And of course,
tooltips should not be repeated. So if you have multiple fields asking for the address... for
example, billing address versus shipping address, you don't want to just say “address” for both of
those tooltips. You want to be very specific and provide explicit instructions as to how that user
should be filling out that particular field versus another one that might be just like it in terms of
how they're interacting with it> But, in fact, it's asking for a completely different address.
Table structure is another critical component. Tables can be quite complex. Luckily,
with Equidox, we make it a lot easier to remediate tables than any other tool on the market,I would
argue. So table structure will have things such as headings. Table headers, as well as table data.
You can have merged cells within tables. Links can be placed inside of tables. Table summaries
are important. They provide necessary and helpful information in reading the table. So if there's
any sort of unique layouts or design elements within that table, that's when the table summary
becomes very helpful. So that could be merged cells, headings, numbers of columns or rows,
it's really up to the individual table. But if you look at the example here on the right,
this has four separate columns of table data. But there are two rows of column headers. So 2017 is
a column header that spans four rows. And you have individual column headers for the quarters within
the 2017 year. And of course, your row headers are on the far left as it breaks down the individual
departments. So it's important to identify those, have those headers so that as a user is navigating
the table data they understand exactly where they are oriented within the table. They understand
which column headers or which column they are within and as well as the row that they are in.
We do have a link here provided to a Smart Table Detector Webinar. So it's a table-specific webinar
if you have more questions or are interested in learning more about our table editing
capabilities. So with that said, in the interest of time here (we are a few minutes past) so I do
apologize. I've been a bit long-winded but I do appreciate everyone for taking the time to join
us today. As always EquidoxSales@Onixnet.com if you have any questions or if you'd like to set
up a personal one-on-one call. We can take a look at your documents, we can talk about
your accessibility needs. We have our website www.Equidox.co, and as I said before, please feel
free to connect with us on LinkedIn and Twitter, and all of the social media networks. We're very
active on there. And you can always stay up to date on what's coming next with the Equidox team.
So with that said, thank you very much. Tammy were there any questions or should we wrap up?
[Tammy Albee] We did not have any questions. There were a few issues with the images,
but for anyone that was hoping to see a little more on a couple of those slides, the remediated
slide deck will be made available to everyone who registered. So if you're wondering what some of
those images were, you should be able to see them there even if they didn't show up on your screen.
[Dan Tuleta] Okay, all right well, great well thank you so much, everyone,
for joining and we will we'll see you next month!