Accessibility – The State of the Web


RICK VISCOMI: Hello,
everyone, and welcome back to “The State of the Web.” The theme for today’s
episode is really important, because you may have a fast
website with the best content, but it’s all for nothing if
people can’t actually use it. My guest is Nektarios Paisios. He’s a software engineer on
the Chrome Accessibility team, and we’re talking about
the state of accessibility. Let’s get started. [MUSIC PLAYING] So how would you describe
your role on the Chrome Accessibility team? NEKTARIOS PAISIOS: I’m
a software engineer. This means that
I’m a programmer. I write code all day, which
is something I enjoy a lot. I implement accessibility
features in Chrome, and I also fix
accessibility bugs. I mostly work on Windows
and Mac accessibility, but my team has
lots of other people who work on many
different platforms and for lots of features that
we release as part of Chrome OS. RICK VISCOMI: So how would
you explain accessibility to someone who may be
new to web development? NEKTARIOS PAISIOS:
Well, accessibility is a very important feature. We should see it as a
feature of our website. And it’s part of usability. The more accessible your
website is, the more usable it would be to everyone. So it doesn’t only affect
people with disabilities. If we want to talk about the
people with disabilities, they are, according to the
World Health Organization, 15% of the population. So even for a
business reason, you could say that you’re getting
more customers if your website is more accessible. But aside from
that, your website will be more usable
if you abide by all the accessibility standards. If you follow all
the best practices, your website will
be both accessible and provide better experience
for the rest of your customers. So it’s a good
business practice. It’s the right thing
to do, but, also, it creates the best
experience for everybody. RICK VISCOMI: And what
are the various ways that people with disabilities
interact with the web? NEKTARIOS PAISIOS:
Depending on the disability that somebody has, they
use different sorts of assistive software. One of this piece of software
is called a screen reader. So if you’re blind,
for example, you might be using the web through
a piece of software that reads to you using synthetic speech. It reads to you the
contents of the screen. That’s why it’s called
a screen reader. If you’re partially
sighted, you might be using a magnifier,
so you might be and large the size of the
font, the size of the text, the size of the whole page,
the size of the images, even the size of video. So there is different
software that helps depending on the
disability that you have. If you’re hearing
impaired, you might be using some captions
or some software that can listen to what
has been said, and transcribe that into text. If you have another disability
like a motor disability, you could use a switch access,
which is a device that allows you to move through the
interface by flipping a switch, or you could use eye tracking
devices that track the movement of your eyes if you
cannot move your hands. You might be able to move your
eyes, so by moving your eyes, you can move a cursor
around the screen. So there are lots of different
accommodations depending on the particular need. RICK VISCOMI: So
what are some things that you wish even the more
experienced web developers would know about accessibility? NEKTARIOS PAISIOS:
Clearly, that web has offered a big opportunity
for companies and organizations to show off their branding. Different websites
have different layouts. They use different font sizes. They use different colors. They have different ways
of interacting with them– different menu systems,
different ways of navigating through the different
workflows as a whole. This is very good for branding. Every organization wants
their website or their web app to differ from
other organizations. We don’t want to
have a monoculture. We want to have a platform
that is full of life and diverse as possible. However, if you’re a person with
some accessibility challenges, it takes much longer
for you to get accustomed to the different
workflows that are presented by different websites. Let me give you an example. Let’s say you’re blind, and
you’re using a screen reader. What do you have
to do, most likely, is you need to read the
web page that you’re interacting with serially
from top to bottom. And if– to get
familiar with it, to familiarize yourself with it. So it takes you time to– if the conventions are
different from side to side, it takes you time to go
through all the content just to be able to do– let’s say you might want to
sign up for a newsletter, or you might want to
order or buy something from that particular
company’s website. If the workflow for purchasing
an item is different for each website, which– for each website,
which most likely it is, then it is going
to take you much longer to learn that
workflow, because you don’t have the visual cues that
a sighted person might have. The placement of
icons, the placement of the different elements
or the different buttons– you don’t have a clue– you
don’t get those hidden clues. You have to go and
discover them by reading the contents of the– of most of the website. The same goes if you have a
motor disability, for example. You might need to use a hardware
device, like switch access, to go through the
contents of the site. And if you have mus– you
have developed muscle memory that you know, for
example, that if you press your switch a specific
number of times, you get to a particular
feature on most websites– let’s say the top
navigation menu. But now you discover
that for each website, the navigation menu on the
top is not the same location. So you cannot really
develop muscle memory with your assistive device. And you can imagine
the similar issues with other groups
of disabilities. So what I would suggest is try
to follow existing conventions. And this brings me up
to my second point. Not everybody uses the computer
using a mouse or a phone using touch. They might be
using some commands that come with their assistive
software or hardware. And those commands require
that your site is accessible using the keyboard. And if your site is not
accessible using the keyboard– it needs a pointing device– then it might be hard for this
assistive software or hardware to work with your website. Another point is there are lots
of accessibility standards, and the Web Content
Accessibility Guidelines is one of the most
prominent standards. And it is better if you
go through those standards and try to follow
as much as possible the guidelines
that are out there. So that’s one of the
ways your website will be consistent with
established patterns. The same goes for the keyboard
navigation I described before. Another thing that you
should bear in mind is if you don’t actually
test with assistive software, you’re not going to
know the bottlenecks. You’re not going
to know what issues your users are running into. So you could try some of the
assistive software very easily. For example, if you
have a Chromebook, you could easily turn on
a screen reader that comes built into every Chromebook. You could turn that on, and
every command that the screen reader exposes is in a
menu, so you can easily get to all of the commands. It doesn’t– it’s not a
very steep learning curve. The same goes for
every other assistive feature on that platform. You can turn on magnification,
color filtering. On Android, you can
turn on a feature whereby you could use the
volume buttons of your phone to simulate a switch
access device. So somebody with
a motor impairment that uses a hardware
switch device– you could simulate that using the
volume buttons of your phone. So these are some
of the tips that you could rely on when developing. RICK VISCOMI: What would
you say to developers who may be
well-intentioned and try to be overly descriptive
with, for example, their ARIA labels on
elements, and they might just say too much about an element? NEKTARIOS PAISIOS:
It’s a bit funny, but there is this notion that
if you have a disability, it means that you don’t have
the intellectual ability to understand what everybody
else can understand. And that’s actually not true. We don’t need to go over the top
when describing a UI element. For example, we don’t need– if there is a button that, let’s
say, minimizes a video player, we don’t need to
say things like, “collapses and reduces to a
small size the video player and places it at the bottom
left side of the screen.” You don’t need to say that. Just say, “minimize.” And people will understand
from the context that it minimizes
a video player. Of course, we have
to bear in mind that we have a group
of disability users that are with
intellectual disabilities or developmental disabilities. So we have to cater
to those users by using language that could
be understood by a ninth grade level. We shouldn’t use complex and
not very well-known words. But other than that, we don’t
need to go over and above and try to overcompensate. The other thing, though,
that you should bear in mind is what I was saying
before with the keyboard. If you want to test your
keyboard navigation, you should not only
use the Tab key, because Tab is not the
only key on the keyboard. So coming back to your
previous question, what I wish web developers
knew is Tab is not the only key
on the keyboard. And if you look
through, for example, the ARIA, the Rich
Internet Applications practices for keyboard users,
there are lots of shortcut keys that are listed in
those practices, in those authoring practices. And Tab is just one of them. RICK VISCOMI: And that
goes to the importance of using semantic
elements on the web so that the screen reader can
understand what type of content is on the page. NEKTARIOS PAISIOS: Instead
of using a div or span element that doesn’t convey
any semantic information, it’s better to rely on the
existing HTML5 rich controls, if possible. So let’s say you want the
user to enter an email field. Use the email input box. There is such a text field,
because an assistive software might provide auto-complete
suggestions to a user, for example, if they
detect that they are trying to enter an email. But if you don’t use
the correct control, the assistive software
might not know that and offer no suggestions. The other problem is let’s
say you want an enter a date, there is a date control. You when to use a list. There is a list box
control in HTML. Try and use those controls,
unless you really have specific reasons why not to. Most people have issues
with the styling. I do understand that. But if you are comfortable
using the built-in controls, use them, and take
your time to read through the new controls that
came out in the last few years. There is an array of
rich form controls. There’s a number control. There’s a telephone input. Do not ignore those controls. They might look the
same as a text field, but under their hood, they’re
very useful to somebody who is using an assistive software. RICK VISCOMI: Right. So as the web capabilities
have evolved over the years, people have started using
the web in different ways. So what effects have
trends like these had on the ways that users
actually use the web? NEKTARIOS PAISIOS: The
development of the web has given people with
disabilities a workaround. For many of us,
including myself– I’m blind myself–
including myself, we have been
liberated, in a way, by the proliferation of web
applications, because if, let’s say, you want to go and visit a
bank and make some transaction, you usually go to a
bank, and you have to complete some paperwork. And that paperwork– if
you’re blind, for example, you will need some assistance
to help you do that. If you’re deaf, the person
who is at the bank most likely doesn’t know any sign language. You might have
difficulty explaining to them what needs to be done. If you have a motor disability,
there might be no ramp. It’s hard to get into the bank,
and then you can’t go in there. So there are all sorts of issues
when it comes to physical work that they completely disappear
when you use the website. A website also–
and that’s also– that’s another great point to
remember– doesn’t have a bias. If you visit a place, and
you have a disability, and people there, they don’t
want to accommodate you, you might have a hard
time convincing them that you have the right
to be offered services. But a website doesn’t know
that you have a disability. And this has also opened up
the employment market to people with disabilities who can– through their computers,
they could perform the tasks that, before, they
needed, for example, a secretary or an assistant to
help them perform their work duties. Another thing is reading books. Let’s say you have a learning
disability, for example, or blindness. It would have been hard
for you to read a book. Now there is software
that can read the book to you over
the web, and also, for people with
dyslexia, for example, there are tools that help them
break up syllables or read the book using text to speech
or have a dictionary that is on demand and easily
accessible on the computer or on your phone. So it’s really easy to get
accommodated through the web, and you can also feel very
independent in that way, because you are using
the same websites and the same web apps
as everybody else. So this is a very nice feeling. You feel that you
are treated the same as every other customer of
that particular business. However, on the negative
side, the more complicated the web has become,
the more important it is for web
developers to take care of accessibility challenges,
because, on the flip side, if you do visit, let’s say,
a supermarket, and you’re in a wheelchair, and
you have trouble going through the aisle
of the supermarket, an employee might
help you by fetching an item from the shelf. However, if the website
is inaccessible, and you’re a person with a
motor disability that is relying on eye-tracking device
to use the website, and the website doesn’t
have very good, let’s say, keyboard navigation or some
kind of navigation that– the functionality that would
allow that assistive software to interact with it, then
this person is stuck. They can’t really
negotiate with a machine, because the machine
is inflexible. So yes, the web
has removed a lot of the accessibility challenges. However, if we don’t pay
attention to the accessibility of our websites, we’re going to
erect much higher barriers that are inflexible and cannot be
removed by talking to a human being. RICK VISCOMI: Right. And one of the solutions
to that is standardization, and the W3C’s web
accessibility initiative is to define strategies,
standards, and resources to make the web accessible
to people with disabilities. So what kinds of
things have been done from the standardization
side of things to make the web more
accessible to people? NEKTARIOS PAISIOS: There
have been a lot of efforts, and actually, I
have been involved in the Chrome Accessibility
team for a few years now. And we have an
esteemed colleague on the team that is part of– has been part of the
standards for many years now. And what they have been telling
me is that at the beginning, there was nothing,
and then they worked really hard for a few important
standards to be put in place. The Accessible Rich Internet
Application standard– ARIA for short–
it’s very extensive, and it defines
specific attributes that you can add to your HTML
that enable HTML elements that do not have any semantic
information attached to them. It’s what I was
describing before– the use of divs and
spans with visually– with visual information
that conveys to the user what they do. For example, it might be a
div that represents a button. RICK VISCOMI: Or a checkbox. NEKTARIOS PAISIOS:
Or a checkbox. But it doesn’t convey that
to the assistive software. It’s only conveyed visually. However, if you use
the ARIA standard, there are some attributes. For example, [? rule– ?]
and you can say, [? rule ?] equals checkbox. And suddenly, all the
assistive software knows that this is a checkbox. And then there is another
attribute called ARIA-checked, and you can say,
OK, that’s true, and that means that the
checkbox is now checked. So what is visually
represented with a checkmark is now also conveyed
in the HTML, and the assistive software
can get to that information. Another standard that
has been evolving is the HTML standard itself. So as I said before, in HTML5,
there are new form controls, rich form controls
that you can use. And those controls are
accessible by default, because they’re
implemented by the browser. So there’s sliders. There’s a time range. There is email input,
telephone input, et cetera. There are lots of controls. Another standard is the
web component standard, and that’s an evolving standard. And that one enables you to
create components and widgets that could be packaged as a
unit and used in other web apps. This is very helpful,
because once somebody creates an accessible widget– let’s say we want to create an
accessible calendar widget– we can create that,
publish it on the web, and then people can easily be
include it in their web apps. Before this web component
standard, it’s hard– it has been hard to include
components from other sites, because when you
paste in HTML and CSS, there might be conflicts
with your own CSS, with your own HTML, with
your own JavaScript. But this web component
standard enables those widgets to isolate themselves from
the rest of your web app. So I think that would
help accessibility by enabling people
to create accessible components once and distribute
them to be used everywhere. RICK VISCOMI: And what is the
Accessibility Object Model? NEKTARIOS PAISIOS:
It’s just a standard that would enable
web applications to expose some of the
accessibility information and perform some of the
accessibility actions that were only available to desktop
applications in the past. Not only desktop, but
also, I should say, they were only available
to native applications in the past. I’m talking about things
like if a user performs a gesture, a specific gesture,
or uses a specific command with their assistive
software, this command could be communicated
to the web app itself. And the web app
could take action based on that command that came
from the assistive software. Native apps could
do that before. Web apps couldn’t. We’re trying to create a
standard to solve that. Another thing that this
standard is trying to solve is the ability for
the web app itself to create accessibility
information that would only be visible to users
of assistive software. In the past, you
couldn’t easily do that. Now you can. If you have a
complicated app that presents things using,
let’s say, Canvas or some other kind of
graphical technology, but you want to create some
equivalent, semantically rich representation of what
is visually conveyed to users of assistive software, with
this new standard, Accessibility Object Model standard, you can
create your own accessibility objects, put the information
you want in them, and expose them directly
to assistive software. So in effect, you can tell
the assistive software what exactly– exactly what you want to see. RICK VISCOMI: So
what types of tools are available for
developers to understand how accessible their website is? NEKTARIOS PAISIOS:
Chrome actually has a lot of building tools. We have the Chrome
Developer Tools, and inside the Chrome
Developer Tools, if you go to the main panel, the
panel where you can see the DOM tree, there is
also a tab in there that allows you to see
the accessibility tree. The accessibility tree is
not the same as the DOM tree. The accessibility
tree is the tree that is presented to
assistive software. And it is created based on the
DOM tree and the layout tree, so your HTML, your CSS,
your JavaScript, all of that is used to create the
accessibility tree, which conveys the information about
the page to assistive software. And that’s the tree you can
manipulate with using the– directly using the Accessibility
Object Model standard that I have mentioned before. And also, that’s the
tree where in which all the ARIA
attributes you might have added to your website– that’s where those
attributes would appear. So as you can see,
this tree is created from many different sources. But ultimately, that
is the information that assistive software sees. And you can see it as well. If you go to the
Developer Tools, there is a tab there that
shows that accessibility tree, and you can use that to see– let’s say if you have
a screen reader user– what are they
going to experience if you visit your website. How are they going– what information are
they going to see when they try to read the
site using a screen reader? There is also another panel
in the Chrome Developer Tools. It’s the Audits panel,
and as part of the audits, we have Lighthouse. Lighthouse can perform
audits on your website and give you a list of
errors or recommendations for you to improve. So it’s very easy. You could go and click and run
an audit, accessibility audit on your website. I have to point out that it
doesn’t catch all the errors. You ultimately do need to test
with some assistive software or rely on user feedback. But it does help. RICK VISCOMI: Right. A score of 100% doesn’t
mean your website is fully accessible. NEKTARIOS PAISIOS: Yeah. RICK VISCOMI: So
the HTTP Archive tracks Lighthouse
accessibility scores on over a million websites. The median Lighthouse
accessibility score is 62%, and another
interesting stat– 42% of pages correctly use
alt attributes on images, and only 12% of pages
correctly label form elements. So the state of
accessibility right now shows a lot of
room for improvement. NEKTARIOS PAISIOS:
Unfortunately, we do need to redouble our efforts. And perhaps, we need to provide
more automated solutions for making web apps accessible. We do need to pay attention to
the Web Content Accessibility Guidelines, and there are
three axes in those guidelines that I think everybody
can understand. The app should be– the
website should be perceivable, so you should be able, as
a person with a disability, you should be able
to perceive content that your disability
prevents you from perceiving. And also, let’s say
you have an image that doesn’t have a
description, or you have a video that has only audio. It doesn’t have captions
for people who are deaf. If you’re a person with some
developmental disability, and there is language
there that is not– that’s too advanced
and too complicated, or you have very long
and long-winded text, and you’re unable to
read long pieces of text, then you’re going to
have difficulties there. So– or you’re the
person who doesn’t tolerate rapid animations. So it’s not hard for somebody
who is developing a website to understand if they
try and put themselves in the shoes of a person with
disabilities for a few minutes, it’s not hard for them
to understand what it means when we say
that your website needs to be perceivable. It just takes some
time to put yourself in the shoes of
this other person, and then realize,
oh, wait a moment. This might create some
trouble for people. Another thing in the Web
Content Accessibility Guidelines is your app needs to be– your
website needs to be robust. So the HTML needs to validate. You need to be using
the correct attributes, and form labels is
actually part of that. You need your forms
to have labels, your form fields to have
labels to indicate errors in a clear manner and to suggest
corrections, if possible. So I don’t think it’s
hard for somebody to follow those standards,
if they try and get in the shoes of the user that
is trying to use the website. I do realize that
some of the standards are vague and too technical. They use complicated
language, but I think if you’re a
developer that wants to learn how different people
with accessibility needs use your websites,
you could try and find videos on how different
people use assistive software, and then try and
imagine yourself being in the shoes
of those users. RICK VISCOMI: So
as web capabilities continue to evolve, we have
technologies like AR and VR around the corner. How do we make sure that
we’re not leaving people with disabilities behind? NEKTARIOS PAISIOS: A lot of
the changes happen organically. They grow from past experience,
and slowly, slowly solutions get developed. For example,
assistive software has been developing
for 25 or 30 years, and it has been a
gradual process. However, there is a
technology shift like the move to touchscreen mobile
phones, for example, or the use of VR,
virtual reality. It would be very
difficult for somebody to wait for this progress
to happen gradually, because then you would expect
a big gap in the number of– in the amount of time
that you have to wait, if you’re a person
with disabilities, to get your hands on
the new technology. So here is where we need the
new research and the innovation. That’s why I do
encourage people who are interested in the field
of accessibility to pursue a career in this
field and to also get a degree on accessibility. There is a notion that
accessibility is easy, that you just add some
labels and some alt text and some keyboard navigation. However, your question
about virtual reality points the finger
to the big changes that could happen in
the lives of people with disabilities, if an
innovation takes place. And we’re not going to get an
innovation if people are not going to work hard
and try to be creative with the accessibility,
with providing solutions to those accessibility
challenges. RICK VISCOMI: Finally,
what resources would you recommend
for web developers who want to make the
web more accessible? NEKTARIOS PAISIOS: My
program manager, Laura, has produced a few videos
that you can watch. We have a Udacity course
that some of my co-workers have created that you can
watch, and it explains to you how you could add
accessibility to your website. Also, the Web
Content Accessibility Guidelines from the W3C and the
ARIA standard, Accessible Rich Internet Application
standard, the authoring guide for the ARIA standard, and
the examples that are provided. RICK VISCOMI: So Nektarios,
thank you, again, for being here. NEKTARIOS PAISIOS: My pleasure. RICK VISCOMI: You can find links
to everything we talked about in the description, and
also share your perspective on the state of accessibility
in the comments below. Thanks for watching, and
we’ll see you next time. [MUSIC PLAYING]

13 thoughts on “Accessibility – The State of the Web

  1. all the web apps that i have worked on has zero percentage for Accessibility. i'm looking for a automated software that would turn a web app for Accessibility

  2. In an ideal world, everyone who has a website would have tools in place to accomodate EVERY accessibility issue, from physical challenges (vision, hearing, motor, etc.) to mental challenges (TBD, developmental, etc.). Realistically, however, small businesses are unable to incorporate into their websites EVERY tool or programming implementation available to larger, better funded corporations. Unfortunately, the most recent targets of opportunistic attorneys and individuals have been small businesses, having had more than 20,000 claims filed against them in 2019 alone, in order to extort monies from them. These small businesses were dealt harsh financial penalties and many, ultimately, were forced to close their doors, even after they were able to implement many key accessibility modifications to their websites. Whether this was the intent of the various organizations advocating for accessibility does not matter. Accessibility legislation has become another open door to exploit small businesses for financial gain, more so than any original intent. I have been a graphic designer, web programmer and an advocate for accessibility for more than 20 years. I designed accessibility-infused websites for disabled veterans during this period and, to be honest, with the increased range of what is being labeled as a 'disability' and the lack of concrete guidelines and methods of implementation, I cannot understand how ANY small business owner can afford to implement EVERY accessibility option — known and yet to be invented. There has to be a better way.

Leave a Reply

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