Tip:
Highlight text to annotate it
X
CHRISTIAN HEILMANN: Here's the panel
that you've been waiting for after we had it hinted
in every other panel so far, and the lots of questions and lots
of quick solutions being thrown around.
Like the last session, for example-- when
will voice recognition be the norm?
Just easy-- take people's eyes out, take their arms off,
and they have to use voice recognition.
A lot of things that we actually think is coming
had to be used in accessibility for years and years already.
I always see accessibility as a hard core usability testing.
It's something that people need and not something
that we just want to have.
But Derek is going to do a better job in that.
My job is right now not to talk but to introduce people.
So to first make fun of the Germans,
let's have a family name like Lewthwaite.
Sarah is here.
She's from King's College.
And she's an academic researcher and writer bridging
the gap between critical disability theory
and accessibility practice, something
that was on our mind for a long, long time,
and we've been discussing a lot between us, hopefully.
Andrew Ronskley over here is from the RNIB.
And he's an accessibility and usability specialist
focused on the web and mobile platforms.
He's also contributed to the Surf Right standards, which
was an interesting thing to look at.
Alice Boxhall is from Google, but she
knows about accessibility.
[LAUGHTER]
OK, that was unfair.
But it was so good, because everybody else
I talked to, she's like, and here's Alice.
She's going to talk to you later about accessibility.
So no pressure-- you have to answer all the questions
right now.
She works on the Accessibility Developer Tools
extension and library.
And that's something like we used in the past.
We had performance tools for developer tools.
But now we have accessibility testers in there
as well, which are great, and absolutely necessary
for things like a Chromebook where
you only have Chrome on it and nothing else.
And Matthew Tylee Atkinson from the Paciello Group over there
is from the Paciello Group, a tester, screen magnifier,
and occasional text to speech user.
And he works on web accessibility,
accessible gaming, which is an interesting topic, especially
when you think about these kinds of Kinect things, level
editing, and supporting older users.
Old users-- is that a political correct term?
I'm not sure.
So speaking of people that have been around for a longer time,
I'm going to introduce you now to Derek Featherstone, who
has been with me in the accessibility world
for a long, long time and worked on the first book
that we both had chapters in, the web accessibility book
that two or four people read and followed up later on.
So without further ado, over to Derek.
[APPLAUSE]
DEREK FEATHERSTONE: So I'm here today
to talk about accessibility.
And most people think of accessibility
in very technical terms.
And the number one point that I want everybody
to walk away from this today with
is that accessibility is all about people.
It has to be about people.
Because if it's not about people,
we end up doing the wrong thing even though we're
meaning to do the right thing.
So all of us that are up here have a background
in doing this stuff for people.
So Christian actually started his first foray
into understanding accessibility when
he was working with people with disabilities
when he worked for the Red Cross.
Sarah is a researcher.
She actually works with real people on accessibility issues.
Alice is putting ARIA support into Chrome.
And that's for people to use, right?
We cannot forget this.
Andrew actually works with people,
taking smartphones to them to show them and demonstrate
all the different accessibility features of smartphones
and how those things can actually
have an impact on their day to day life.
And Matthew started changing the authoring environment
for gaming so that that could be accessible to people
that were blind.
And I do, too.
I work with people with accessibility
with disabilities every day.
We do research and testing and try
to figure out what UX is for people with disabilities,
right?
What does UX mean to them?
And so hearing all the things that everybody's
talking about this morning and this afternoon
has been absolutely fascinating.
Because we're talking about it at very technical levels.
But at the end of the day, people have to use those tools.
And that to me is what accessibility is all about.
We tend to simplify things.
And you probably have heard of all
of these different conditions or things that people have,
that people are blind or they have low vision, they have
hearing difficulties, or that they
have a mobility or a dexterity impairment.
And when you start to think of all of these things,
even those things seem to be very physical.
But what about the cognitive side of things?
And those are traditionally the things
that we're thinking about when we think about accessibility.
But there's a whole other realm that we
need to start to get into and explore.
How many of you have heard of things
like vestibular disorders?
So there's a whole group of people
that have some kind of vestibular disorder--
and I don't even like the word "disorder," but issues
with their balance.
And so when they're looking at a screen with all your fancy CSS
animations and your parallax effects,
that actually makes them nauseous, right?
It actually causes migraines.
So when you're scrolling down the page,
and you have a car that you've animated
with CSS that's going like this across the page, that actually
makes somebody nauseous, right?
These are new things that aren't sort of in the mainstream
accessibility.
And we need to start to take those things into account.
Things like speech-- the very last panel
was talking about, well, what about speech?
And as Christian pointed out, voice recognition software
was originally invented for people with disabilities.
So on the speech side of things-- and this
is I think an absolutely critical thing for us
to keep in mind as we move forward.
Speech is just one modality, right?
What happens if we create interfaces
that use that as the only modality?
And what does that do for somebody
that speaks a different language, that
has a stutter, that maybe has cerebral palsy
and has difficulty speaking, right?
We need to create interfaces that are entirely flexible.
And one of the other panels earlier,
the pointers-- what about custom gestures?
Well, what about the fact that-- and so here's a custom gesture,
move up and to the left.
Well, that custom gesture is already
being used on Android for screen reader users that
are using the talk back screen reader on Android.
So what happens when that custom gesture
that you've created and built into your page conflicts
with the custom gesture that is required for the screen reader?
So we need to think about flexible alternatives.
So when I move up and left in TalkBack in Android,
that means something to me.
And that gives functionality.
So even though you create a custom gesture
like that in your app or in your page,
you need to consider that maybe that's not the only way that we
should be able to instantiate that action.
Maybe we need some other method or a backup mechanism
to do that.
We need to think about all of these different things.
We tend to put people in boxes and say, you're blind
or you're not blind, right?
You have a disability or your don't.
But that is not reality.
We have a scenario-- and this is a very standard Gaussian
binomial bell curve distribution,
whatever you want to call it.
And we have people that live at one
end of the extreme or another.
And this one's talking about people's size.
But think of it in terms of any ability.
So you have people on one end that have maybe completely
normal vision, on the other end people that have no vision.
And then, you have people everywhere in between.
This is not a binary all or nothing scenario.
And we need to think about that all the time.
Today's assistive technology is really advanced.
We've moved from a point where solutions that we used to think
were completely untenable, like ARIA.
So ARIA stands for Accessible Rich Internet Applications.
And it's a tool that we can use to add to our code
to provide programmatic accessibility where it just
didn't exist before.
Screen readers for over the last five years
have really advanced and really done
a great job of getting ARIA support into that technology.
But we have to ask this kind of a question.
What if a brand new version of a certain type
of assistive technology just isn't modern?
And I'll give you an example.
This is a suite of assistive technology tools.
We've got voice recognition up there.
We've got tools built into browsers.
NV Access is a screen reader for the Windows platform that's
free, VoiceOver on the Mac.
ZoomText on Windows is a magnifier and reader
combination.
Now, all of the screen readers on there,
they have done a pretty good job of keeping up
with modern technology.
But some other tools don't necessarily keep up.
And so I'm not going to name any names or single anybody out.
But Dragon NaturallySpeaking is a great tool.
But it doesn't keep up with the standards.
They haven't implemented any support for ARIA.
And that's something that all the screen readers have done.
I'll give you an example of why that's actually important.
This is a very, very new version of a Google map.
And these things on the interface, the search button
and the zoom in and the zoom out,
those things all used to be divs with on-click handlers--
pretty straightforward practice, very typical.
This is something where we could actually improve that by
instead of just having a div with an on-click,
we could actually give that a role of button
so that a screen reader or other piece of assistive technology
in theory could recognize that that's a button so that there's
a more natural affordance there that, hey, I can actually
click on this instead of it just being a div in the page.
The beautiful thing about this is
that-- and I just literally saw this
with this new revision of Google Maps--
there are actually now buttons, like actual buttons.
Holy crap, there are actually buttons.
And that totally gets a gold star.
Because all the semantics of a button
are already in that native element, right?
This button could be used by Dragon NaturallySpeaking.
The div with the role of button can't be, right?
So there's a question about whose responsibility is this.
There's a lot of people that are pointing the finger at Dragon
and saying, you guys are wrong.
And I want you to think about this.
From an ARIA perspective, this is-- the last time
I stayed in London, I had this in my hotel room.
This was a king size bed.
And so I had a sleep apparatus with the role of king size bed.
But it was two twins with a break in the middle.
Now, I complained.
I'm Canadian.
I don't complain.
So this was a big deal to me.
So I complain, and I got a new room.
And I got a new bed.
And so in that bed, I had a sleep apparatus.
And it was a king with a class of posh.
I thought everything was great until I dug a little further.
And I had a sleep apparatus with the role of king size bed, two
twins with a break, but the break
was styled to be display none.
If you remember nothing else about ARIA,
remember that what's under the sheets actually matters, right?
The tools and the code that you use actually
have a huge impact on how assistive technology can
interpret it and work with it, right?
So thinking about those kinds of things,
and thinking about Dragon and how it works,
is it our job to be responsible, even though we
have a tool like ARIA that could really change your app?
Do we have a responsibility to make some better choices
and actually use things like real buttons,
or just better code in general?
My vote is yes.
But you'll find that out in the next little while.
The other thing that people are asking quite a lot
about these days is stuff about detecting assistive technology.
And I want to know-- and as a developer,
you probably want to know.
I've heard it all morning.
I'd really like to know, is this HTTP 1?
Is it HTTP 2?
Is it whatever?
Do we have the capability to know?
And my question to you is, if you could detect a screen
reader, what would you even do with that information?
And there's some real slippery slopes
that we go down when we do that kind of stuff and say--
and I'll give you one example, and then I'll shut up.
If we use a screen reader, if we detect a screen reader,
we might inject a whole bunch of extra hidden headings
that give some extra context to a screen reader
user, which is kind of a neat idea.
I think there's some merit to that.
But we have to remember that the only people that
use screen readers aren't just blind.
There's all kinds of people that use
screen readers for literacy reasons.
And what's the impact on them if they have a learning difficulty
if you're having a screen reader read hidden headings
that they can't see on the page, right?
So we need to think bigger.
We'll address a lot of those kinds of questions
and more during the panel-- thank you.
[APPLAUSE]
CHRISTIAN HEILMANN: Splendid, so we're
back to bed components instead of web components-- not bad.
So we have a lot of experts here.
We have seven questions that we cut down on.
I'm supposed to get these questions on some list here.
But that's not going up at the moment.
What's going on there?
So-- oh, it's a tablet.
Look at that-- wonderful.
Touch interface-- and really small and not resizable.
OK, so the first question that we have
was a post by Andrew Betts.
But he doesn't want to do it, so Melanie Lang.
MELANIE LANG: So it is, what are the main offenders
of modern websites in terms of accessibility?
What are the main offenders of modern websites in terms
of accessibility and what can be done to fix that?
CHRISTIAN HEILMANN: So the question
is, like in many cases, web developers,
we do things that look beautiful.
And it's a barrier for accessibility
without us even knowing it.
So I think we're going to send that off to Matthew.
So Matthew, what have you seen in your day
to day browsing that drives you nuts
although people think it's amazing?
MATTHEW TYLEE ATKINSON: There's a few things.
I'm sure that there's going to be
many examples from the rest of the panel.
But I suppose a personal [INAUDIBLE]
for me is disabling pinch to zoom on mobile sites.
Because it just renders them completely useless to me,
personally.
I'm vision impaired.
I can see well enough to use the device,
but only if I've got control of the size of things on it.
So that's a personal one.
I think something to bear in mind
is that somebody that's using an assistive technology to browse
a website, say, for example, a screen reader,
but it doesn't limit it to just a screen reader,
they can only perceive one element at a time.
So they go through the whole thing one element
by the next element until they get to the end.
And a lot of stuff in accessibility
is providing information such that the assistive technology
can help the user get to the bit of the page they want
to get to as quickly as possible.
So a lot of stuff is about saving the user time
and making sure that the structure of the page
is conveyed, the semantics are conveyed,
so that the user saves time and can get to the bit they need.
So things like lack of skip links, lack of headings--
visually, you can see the layout beautifully.
But there's just no semantic information
or no structural information there.
That's very frustrating.
Because it might actually be-- a trend on modern sites
is towards things like simpler language,
fewer words on the page, more focused.
It could be really good.
But sometimes people forget the basics,
which is, just make sure that you use HTML headings and lists
and stuff like that, ARIA if necessary,
excuse me, and native controls where possible,
so things that save people time.
And there is also an article I read recently
about things that just have to go away,
things like when you're asked to enter a credit card number,
and you're asked, what type of credit card is it,
and please remember to put the dashes in,
or don't put dashes in, or put spaces in,
telling the user to do this stuff.
OK, for all of us, that's really annoying.
It shouldn't be necessary.
It's just a number.
But for accessibility, people facing extra accessibility
barriers, that sort of stuff, having
to go back and correct it because the instructions
weren't necessarily there or correct,
that can really take a lot of time.
And it's very frustrating.
So it's going back to using sensible HTML,
building things the way they used to work.
I remember when browsers were bad,
you had to use the right HTML or otherwise they
wouldn't show up.
Because there was no CSS to a degree.
We don't use tables for different weird things,
but that's a different story.
CHRISTIAN HEILMANN: So Alice, the shockingly innovative way
of using buttons instead of divs with on-click handlers,
do you have to fight for these kinds of things?
Is there a way that developers are actually
assuming that things work in the browser,
because the browser fixes it for them,
and do we have to remind people how to make things accessible?
ALICE BOXHALL: Well, yeah, if you're using standard widgets,
by and large, it should be accessible.
One of the big problems we see is that people just simply
aren't using the standard widgets.
And yeah, I'd very much like to understand why.
My hypothesis is that you can't style them the way you want.
So two problems-- one, you can't style them the way you want,
or they don't behave the way you want.
So one thing I would like to see is
making it easier to style custom elements the way
that we want to.
Because it's quite difficult today.
It's a very simple problem to solve, I think.
Secondly, make it easier for developers to actually apply
that ARIA metadata semantic information.
How can we get that on the golden path
that we've been talking about today, or the pit of success?
How can we make that easier for developers?
I think that web components possibly
has a big role to play here.
And I knew the team is working on that.
Another idea would be to put it into the developer tools
that we're all using.
So how can we expose the accessibility information such
that it's impossible to ignore?
DEREK FEATHERSTONE: Wouldn't it be better
to make it harder to put ARIA on stuff?
ALICE BOXHALL: How do you mean?
DEREK FEATHERSTONE: Well, ARIA is
a great solution for screen readers.
But it's not right now for Dragon.
And I know in good conscience that we don't use ARIA
unless we know that it's going to get really good support,
and that we look for other ways to do things
while we're building things.
I almost would like to make it better
to just use a button than to add role
equals button on something.
ALICE BOXHALL: Yeah, I completely agree.
CHRISTIAN HEILMANN: We're coming back
to ARIA in an extra question later on.
And I agree.
It's a tricky thing to actually turn something into something
that it isn't when there is something
that is already something.
But that's a different story.
So Andrew, what do you see as crimes
that are happening that actually make things
inaccessible on mobile devices when people use HTML?
I found it interesting, for example,
the unsightly Select box that people hated on the desktop
and always wanted to style is awesome on mobile devices.
ANDREW RONKSLEY: Yeah, I think on mobile,
I think Matthew's already covered it.
The biggest one is disabling pinch to zoom.
I've had so many users come to me with that problem.
I'm asking you, why does my pinch
to zoom not work on this website?
And it comes down to the way we use it
in the meta viewport tag.
And we're all using it to get rid
of the 300 millisecond delay, which-- I guess in the past,
my advice would be to developers,
think about how you use that.
But I guess now, going forward, I'm thinking,
should people like myself be getting more involved
with browser vendors to say, OK, developers
are doing this-- Is there a way that we can kind of cater
to both scenarios?
Rather than say to developers, don't do that,
is there a way that we can kind of get
this fixed through bugs for the browsers, basically?
So that's probably the biggest one.
I think on desktop, the best bit of advice
I could give to you guys would be,
try using the things you build with a keyboard only.
So just recently, I was working with someone
who's having a huge problem with their online banking
where they couldn't complete a payment to somebody.
Because it was using an overlay.
And whoever had built that had clearly
thought about the interaction with a mouse.
Things behind the overlay were disabled.
You couldn't click on them.
Well, because this user was using the keyboards,
their interaction was going wildly wrong.
And if the developer had thought, OK, maybe what
if someone's not using a mouse, they probably
would have found that problem quite quickly
and could have done something about it.
CHRISTIAN HEILMANN: I'm very excited that Jake Archebald has
a question, but we have to move onto our next topic.
[LAUGHTER]
CHRISTIAN HEILMANN: So Ross Green has a question for us.
AUDIENCE: I've got it.
CHRISTIAN HEILMANN: You're not Ross Green.
AUDIENCE: I'm not Ross Green.
But Ross Green is not attending.
So he asked me to ask the question.
And I'm also going to answer it, because I've got a microphone.
Accessibility expectations and requirements
are vastly different depending on the user's world region.
What more could be done to align them?
Example-- most EU rules say don't autoplay media.
However, most US media will autoplay.
The answer is don't autoplay the media.
[LAUGHTER]
AUDIENCE: And a slight snark is, well, EU rules
could be more widely promulgated if the EU government
websites actually obeyed their own rules.
But anyway, what could be done to align
the different territories' regulations
about accessibility?
CHRISTIAN HEILMANN: So the good news
is that this was hard to understand.
The question is-- basically there's two folds to that.
There's differences between accessibility guidelines
in Europe and in America.
And you have to-- for example, when
you do government websites, when you do any website that
faces a lot of audience, you have to apply with them.
You have to basically apply the rules.
And they're different from Europe to America.
As this world wide web of ours is worldwide,
it's kind of confusing to which ones to follow.
So are there ways to actually get the legal requirements
more aligned with each other?
So maybe Sara, you could tell us something about that.
SARAH LEWTHWAITE:The thing I find interesting about this
question is it refers to geography,
which I think is really important.
Obviously, we know devices vary.
Our tools vary, and so forth.
But also, it's worth understanding and thinking
about how disability varies globally and internationally.
So we've already heard a little bit about, say,
the nature of disability and how we
might want to conceptualize it.
But it's worth also, I think, recognizing that disability
means different things in different parts of the world.
Levels and types of disabilities vary
depending on where you are by locale, region,
as well as by nation.
So personally, I think there's a bit of attention
in terms of picking a standard to apply in all situations.
I think the great thing about WCAG is that it's a guideline.
And when it's applied as a guideline,
it allows perhaps for more of that indigenous reflection--
the expertise of local developers
to come into play as well.
So they can account, maybe, for indigenous populations
with low literacy levels.
Or perhaps you have less assistive technologies.
At the moment, there's not a great deal
of data globally in terms of the kinds of technologies
that disabled people are using.
But obviously, WCAG in particular
is being picked up because the UN convention
on the rights of persons with disabilities
is being taken up by more and more countries.
And people have this kind of policy vacuum
in terms of information and communication technologies
that are referred to in the UN convention.
And people want to make sure that the policy is picking that
up.
So WCAG is being applied more and more
as the kind of verbatim standard.
But I think there is a bit of attention
in terms of knowing what that means, say, in Nepal or Uganda,
or more regionally.
CHRISTIAN HEILMANN: It is kind of confusing.
Because being an ex-German developer and now living here,
there's different guidelines even in Europe from country
to country.
So maybe in point of the RNIB, I guess
you work with a lot of people that come to say,
I don't want to be sued.
What can I do for people with disabilities--
which is the awful, awful question we keep getting.
What is your answer to that?
How do you get people to understand that just applying
with the law does not necessarily
make an accessible interface?
ANDREW RONKSLEY: So I think for me,
there is a business case behind accessibility,
which we'll often talk to companies about,
around some potential SEO benefits,
potentially opening up to new markets.
And I think when I first got into that sector,
or this sector, sorry, I really did
believe in that business case.
And I still do.
But at the same time, it's a little bit theoretical.
Because you don't have many cases to back it up.
So Derek's point about, what if we could detect a screen
reader-- I think I'm with you, Derek.
I don't think it's a good idea to detect a screen
reader if you're going to do something
with that information in terms of the website.
But I'd really like that feature as part of analytics
so that we can say, OK, we made some changes to the website.
And we can now see, perhaps, screen reader users are not
dropping out midway through the process of checking out,
or something like that.
So I'd really like that kind of stuff.
Because we don't have many good case studies.
So while we can say, yeah, maybe you can get more visitors,
we don't have any figures really to back that up.
CHRISTIAN HEILMANN: Yeah, Derek, you
used to work on that for a long time as well,
like back in [INAUDIBLE] days and things with like-- I mean,
we had guidelines that said, you have
to have a certain kind of access key on the page, for example.
And that was unenforceable or usable, really.
DEREK FEATHERSTONE: Yeah, there's a lot of things
in-- you have to remember that especially when you
talk about guidelines, accessibility guidelines,
and then talk about giving them the force of legislation,
you're taking something that is designed to be necessarily
fuzzy and putting it into something that
becomes absolute black and white.
And I would even respond to Bruce.
We all said-- everybody laughed.
He said, well, the simple answer is do not autoplay.
And I would counter that by saying that autoplay
can actually be useful for certain types of people,
including people that have mobility difficulties.
It may be actually much easier for them
if you do autoplay so that when you go to a new video page,
it actually does play for them.
They don't have to try and work hard to actually get
it to play.
So when we're embedding a YouTube
video or a whatever video on a site of ours,
we always recommend, have it embedded
and don't autoplay that one.
But also, link to the YouTube page outside.
Because then, the user has a preference
to set it up so that my videos on YouTube always autoplay.
So we're kind of catering for both things there.
So the edicts like, do not autoplay,
they sound really good.
But they don't necessarily always make sense.
Autoplay is bad for everyone except for the people
that need it.
CHRISTIAN HEILMANN: OK, we have a question
from Christopher Emery.
CHRISTOPHER EMERY: I just wanted to kind of chime
in just with regards to going about our differences
between EU law and US law-- so yeah,
the difference between the EU and US law.
Just with regards to my experience,
I found that it's actually even more complicated.
Because the requirements suggest we don't just
live in the government legislature.
For example, when you get to a client who
reaches a level where they're now rolling out
in different markets, they will then
have their own accessibility requirements layer
within that which typically will be based on one market,
even though they're rolling out local.
I mean, that's my experience, even
though they're rolling out globally.
So we've actually encounter situations
whereby we're using, in one example, the EU
accessibility guidelines, even though we're rolling out
in the UAE or in China and things like that.
And that becomes a very weird, strange situation.
Because the document a lot of times
that the accessibility was kind of created at the companies in
was, check off a box to say, yes,
we have accessibility guidelines.
But they didn't roll it out to the market level.
So I just wanted to say, on top of the government legislature,
there's the actual corporate layer as well.
CHRISTIAN HEILMANN: It's a super tricky all-in-all problem.
And the issue is a lot of people try to sell accessibility
as something you could be sued if you don't do it right.
But then, we don't have the answer how to do it right.
It's like getting someone's attention
by kicking them in the shins.
Yeah, you have their attention but not their support.
So Shane Hudson has a question for us
on this, not the kicking but general.
He's there, the man in the striped shirt.
SHANE HUDSON: So are the WCAG-- I
have trouble saying that-- guidelines
redundant in a world of smartphones and tablets?
Are accessibility laws trying to fix an outdated world?
It's kind of been touched upon.
CHRISTIAN HEILMANN: Yeah, kind of-- so basically, the question
is, the WCAG guidelines define a lot of stuff,
for example, keyboard accessibility, which
is on a touch device a bit of a weird thing to enforce.
So do they need to be upgraded?
Do we need to think about different form factors?
I think the best would be just-- Sarah, what do you think?
SARAH LEWTHWAITE: I think this is
a problem with the nature of standards.
And there's quite a lot of interesting
writing about what standards do outside
of development communities.
So for example, they offer a fixed perspective,
which is what I think some of us are struggling
with in the sense that disability
is so heterogenic that it needs to sort of be
as inclusive as possible.
And a standard rather than a guideline is difficult.
So I think, yeah, there are these problems about how
it keeps abreast of new developments
which we can't necessarily foresee.
But I think one of the things which I find interesting
is that standards also convey certain values.
And as I say, when they're being picked up internationally,
it's useful to recognize that they also
promote the rights of people with disabilities.
And they promote their access to technology
and raise a kind of whole argument
about human rights, disability rights, which isn't necessarily
reflected in all the communities that these standards touch
upon.
So that's one of the things, I think,
which we need to also keep front and center.
CHRISTIAN HEILMANN: Matthew, in terms of gaming,
the Paciello Group does a great job in explaining on their blog
how to apply WCAG guidelines, how to apply best technologies.
And most people start with a blank canvas
with no keyboard accessibility whatsoever for their game.
So do you think that the WCAG is outdated?
Are we fixing the web from 1997 rather than the web from 2005?
MATTHEW TYLEE ATKINSON: A couple of things-- first of all,
the gaming stuff is separate to my TPG stuff.
But I'm very happy to talk about it, of course.
CHRISTIAN HEILMANN: Yeah, don't get fired over it.
MATTHEW TYLEE ATKINSON: Sarah made a really good point
last night, which I just wanted to make sure came up,
which is that a screen reader could
be a person next to you reading what's
on the screen in a particular place.
You were saying about different countries have
different social views of accessibility and different
access to ATs.
And therefore, screen reader detection
would have to encompass reading glasses
and people sat next to you as well,
and both of these at the same time, perhaps.
Anyway, moving on to answering the actual question--
CHRISTIAN HEILMANN: Thanks.
[LAUGHTER]
MATTHEW TYLEE ATKINSON: A couple of points-- one
of them is that if you look at WCAG--
and there's a lot to read.
But the central point that it's trying
to get across, and the values that Sarah mentioned,
they're actually written down in there.
They are the POUR principles that your content needs
to be Perceivable, Operable, Understandable, and Robust.
And you can look up what those are,
but you get the general idea.
You can apply those kinds of principles to any medium.
Now, some of the WCAG stuff might
be less appropriate on mobile, some
of the very specific technical stuff.
But a lot of the guidelines-- in fact, all of them--
are written with those four principles in mind.
And you can apply those to any medium.
So in terms of game accessibility,
that is about making sure that you know what information
is important to someone to be able to play this game.
What is the best way to present it to the particular audience
that you're thinking about?
In our case, it was blind people.
So it was making a lot of visual cues auditory instead.
Understandable-- well, it's got to be
understandable to be able to be enjoyable in the case
of a game.
And in the case of a banking website,
it's got to be understandable in order to be able to use it.
And robust-- that covers the kind of security
and reliability stuff on the website side of things.
And on the game side of things, you
don't want it to crash just before you're
going to complete the level.
So very briefly, that is a very glib high level
trying to demonstrate you can apply
these things to multiple areas.
CHRISTIAN HEILMANN: So Alice, when
you put that into the Developer Tools Accessibility panel--
those of us who have been in accessibility long enough
remember Bobby Approved and people putting triple A badges
on their website, which ironically
didn't have an alternative text.
[LAUGHTER]
CHRISTIAN HEILMANN: What are the testing tools
that you have in there?
Do you get, this doesn't apply with that guideline?
Or is it more of a transcription of the perceivable
and-- the ideas of it?
Because it's easy for a developer to say,
oh, I'm now accessible, because I tick all the boxes.
But what does it really mean?
What kind of a test would help people there?
ALICE BOXHALL: So one point that I always
try to make with the accessibility developer tool
is that passing a mechanical accessibility audit
does not in any way guarantee that you're
completely accessible.
It's only looking at the things that we
can test programmatically, which is a subset.
That said, what it does look at are things like color contrast.
It tries to look for click targets
and suggests that you should use an ARIA role and a [INAUDIBLE].
It also looks for valid ARIA use.
Yeah, so those are sort of the main things
that it's looking at.
Yeah, but one point I did want to make just to follow on
is that the robust in perceivable, optimal,
understandable, robust actually encapsulates
working in different modalities, which actually implies that it
should work on different devices.
So when we're talking about mobile, tablet, even something
like Google Glass or TV or a Leap,
robust encapsulates all of that.
CHRISTIAN HEILMANN: Good, Matthew, you had a question,
or you're pulling it?
She covered everything you do?
I just want to show that somebody from Google
has something to say about accessibility.
MATTHEW: No, I was going to ask, since you're all there--
[LAUGHTER]
CHRISTIAN HEILMANN: As I have you here.
MATTHEW: So I once made a comment
about changing an outline in CSS and basically changing
the background color for the focus.
I got slated immediately on [INAUDIBLE] for this.
It's not accessible.
And I'm fine with that.
And I'm kind of like, well, what is the right way to do it?
And there's a part of me that's like, well,
can't I apply filters to my site that say, this
is what a screen reader will see?
Or what should I be doing in my workflow that basically helps
me as a developer make my site more accessible, I guess?
Are there tools?
Is there something you'd recommend?
Or is it just a case of, use native components,
use the accessibility thing, and use that?
DEREK FEATHERSTONE: So using-- 75% of all statistics
are made up.
So you can get probably--
CHRISTIAN HEILMANN: 2 out of 7 people know that.
DEREK FEATHERSTONE: Yeah, you can get 80 to 90%
of the way accessible by testing everything with a keyboard.
And you have to manually test that.
Because that's interaction.
There's no way to test it other than that.
But dealing with straight up good, solid semantic markup--
just writing good HTML and not screwing up keyboard access
gets you 80 to 90% of the way there,
straight up, honest truth.
Now, using it with a keyboard is going to show you stuff
about your outline changes, right?
You're going to go through and you're
going to say, ***, I can see the cursor.
I have no idea where I am.
CHRISTIAN HEILMANN: I have to stop this cursing right now,
actually.
And this is a longer topic that we could go on.
So I'm moving on to actually Ed Soden, which
is actually covering this a bit.
So Ed Soden has a question.
ED SODEN: I'm reading this one.
CHRISTIAN HEILMANN: Yeah, Mr. Snowden, ah, Soden--
was I not allowed to say it?
ED SODEN: So as developers, we often try and make our sites
work well for screen readers.
But is there anything else we can do besides screen readers
when we're designing our sites to make them better
for accessibility?
CHRISTIAN HEILMANN: That is an incredibly interesting question
that we haven't quite covered yet, or just did, or tried.
So Andrew, what do you think?
The big screen reader debate, every developer
I talk to like, it works from the screen reader,
because that's something I can test with-- what else should we
be thinking about?
ANDREW RONKSLEY: No, it's a great question.
And I could make up some stats now, but I'm not going to.
CHRISTIAN HEILMANN: Go ahead.
ANDREW RONKSLEY: In the UK, there's
around 2 million people that have
some kind of sight-related issue.
And the vast majority of those have
some residual useful vision.
So the thing you can take away from that
is quite a small percentage of those 2 million people
are using the screen reader.
The rest of them are making some kind of visual adaptations
to the page.
And I think you can extrapolate that to around the world
issues.
So I think around the world it's something
like 280 million people have some sight-related issue.
So things that you can do that are not
related to a screen reader-- and this kind of
applies to all of us.
You think about using a website out and about,
color contrast, the size of your font,
how much white space is between controls.
So when he's using a screen magnifier--
I'll see sites sometimes where there's a form.
And maybe, there's two buttons at the end, Next and Previous.
They're really far apart from each other.
If someone's using a screen magnifier--
I think Matt kind of touched on this before.
It's a little bit different with a screen magnifier.
But you see a portion of the screen at any one time.
Those of you-- everyone pretty much has Macs here.
You'll all have a screen magnifier built-in, Windows
as well.
So you can try this out if you want.
Another way to think about it is if you imagine sliding a credit
card around your screen, just imagine that was your viewport.
So if the buttons are far apart, there's potential to miss them.
So just that kind of stuff is worth thinking about.
And that's nothing to do with screen readers at all.
CHRISTIAN HEILMANN: Yeah, and that's a very good point.
I love the credit card thing.
I didn't think about that yet.
My favorite is always when people-- now everything
comes with screen readers, which is
great for accessibility for people.
But it also is kind of bad.
Because developers think they know how these things work now.
The amount of people I see using a screen reader with their eyes
open is amazing.
And that defeats the purpose.
Because of course you can understand your system.
So James [INAUDIBLE] has a question,
or was that already about the last topic?
AUDIENCE: Yeah, that was about the last topic.
CHRISTIAN HEILMANN: OK, good, so do you have another one?
MELANIE LANG: I was wondering if maybe we
need to be more creative and maybe go back to roots
and test-- I don't know-- [INAUDIBLE], for example,
the test set aside for old people.
I think they put Vaseline on glasses
and put gloves on to simulate arthrosis.
Yeah, so maybe, do we need to go back and just do that,
maybe, and go this extra mile?
CHRISTIAN HEILMANN: Testing this kind of way works.
I gave people broken mice to actually use
the website, for example, with.
DEREK FEATHERSTONE: Yeah, there's tons of things
that you can do like that to simulate
different types of disability.
And I believe that all those things
are great emulating what a user with a particular type
of disability would be.
You want to see what it's like for somebody
that has a tremor in their hand to use a mouse,
turn your mouse sideways and try to manipulate it on the screen,
or use the wrong hand.
There's all kinds of things that you can do.
One thing that I would point out-- and I think those
are great things to do.
The WCAG guidelines are designed specifically because we know--
and I say "we" like I was involved or something.
But we can't all go and test with real people.
And so those guidelines are all in place
because they're based on years and years of people
actually working with people with disabilities.
So those are absolutely valuable and useful.
And everybody should do it.
But if you can't do that, then you
have guidelines as your sort of first point of advice.
And absolutely go back to it.
But if you can't, just feel at least partially confident
that those guidelines are there to replace
the fact that everybody can't do that.
ALICE BOXHALL: Actually-- oh.
SARAH LEWTHWAITE: I completely understand
where you're coming from.
But I also feel that's a bit of a cop-out in terms of-- I
think sometimes standards step in,
and people want to learn the standard because that's
the easy thing to do.
And they want to turn the mouse and do that when sometimes,
they have disabled populations sitting right under their nose.
So for example, in the university sector,
there are hundreds of disabled students
at King's College, London.
How many are involved in testing our systems?
They're right there.
We could easily engage with them.
So I think it's important to be creative and think
about drawing people into this conversation.
So if you're doing usability testing at large,
don't be afraid of contacting, say, disabled people's
organizations or putting a call out
for people to get involved in testing your systems.
Because they will give you much richer
feedback about how your interfaces work.
And they're going to bring up things
that you just would not have imagined possible.
CHRISTIAN HEILMANN: It would be interesting to see
what kind of-- I mean, you can take the glasses away
from your colleagues, for example.
Or you can read out your text on the screen
to somebody on the phone.
If it then makes sense, you know it's an accessible text.
If you need to think to see to understand it, then you don't.
It would be interesting to set up
a wiki or something about these little accessibility hacks
to simulate different things.
But outreach to real people with disabilities--
hard core users that know how to use something is amazing.
I learned most working next to a PHP developer, who
was blind, for like four years.
And that was just incredible.
Because he coded faster than me, which is annoying.
Now, with a sense of dread, Patrick Lauke has a question.
[LAUGHTER]
PATRICK LAUKE: No, I haven't got a question.
I've got a lengthy statement.
No, just a quick note-- I wanted to pick up just
on something that was mentioned at the start there about,
I did something to my outline, and I was immediately
jumped upon by an accessibility lynch mob.
The dirty kind of truth, even within the Paciello Group--
I can say that hopefully openly--
is that you get three accessibility experts,
you get five different opinions.
We disagree even on sometimes very fundamental things,
like very first guideline of WCAG,
having appropriate alt text.
We could have discussions for days about,
what is the most appropriate alt text for this?
And you'll get fierce debates in the accessibility community
about, every image should have this kind of alt,
or no image should have alt.
And so I just wanted to kind of temper the whole--
when you get some people jumping on you
and immediately shouting, oh, that's not accessible,
they may be right.
Or they may not be right.
And as Derek mentioned towards the start,
it is not a binary thing.
It's not always, it's either accessible or inaccessible.
There are certainly things that you
can do that completely screw everybody over that
can't see the screen perfectly and use their mouse.
But beyond that, there's lots of shades of grey on that one.
CHRISTIAN HEILMANN: Yeah, also, stop arguing on Twitter.
140 characters are not good to actually bring
emotions or facts in.
We've got [INAUDIBLE] here, because Christopher
has said too many things already.
AUDIENCE: So basically, I did a bit of a stat check.
And I checked that there are about 2.7 million people
in Britain who have color blindness.
And I haven't seen that mention in this talk yet.
Do we consider people who are color blind to be disabled,
or are there any things that people in general
can do to improve their pages to improve the looks for color
blind?
DEREK FEATHERSTONE: Did you say stable?
CHRISTIAN HEILMANN: I met a few unstable color blind people
in my past.
I think your tools, Alice-- you talked
about the color distance.
But also, color blindness is one of the simulators
in there, isn't it?
ALICE BOXHALL: No, not in my tool, actually.
CHRISTIAN HEILMANN: Well, that can be fixed.
ALICE BOXHALL: Sure, you want to send me a [INAUDIBLE]?
There are extensions certainly for Chrome, probably
for other browsers as well, which
will simulate color blindness.
And contrast ratio has a color blindness implication in that,
say, if you have red on white, if you view that as grey,
it may not be a high enough contrast ratio.
CHRISTIAN HEILMANN: Derek, you were twitching?
DEREK FEATHERSTONE: A little-- there's
a great tool, Color Oracle, which
you can install at the desktop level.
And it will transform everything.
And you can simulate things.
Two challenges with color blindness-- and I'm
saying this as a very blanket statement.
So there's probably more challenges.
But one is a color contrast issue.
The other is the way that you're using color
to convey information, right?
If you're relying on color, then you need to-- we're not saying,
don't rely on color.
Use color as much as you want.
But use other mechanisms to indicate things as well.
So it could be that you're using pattern with color.
Or instead of just using color, think
of a line graph that has a legend at the bottom.
Instead of putting a legend at the bottom,
change your graph so that each one of the individual legend
pieces is actually up beside the line
so that you can then follow the line.
CHRISTIAN HEILMANN: This also ties into internationalization.
My favorite is when people just use red as a warning,
whereas in China, it means good luck.
Good luck, we lost your emails, wonderful.
[LAUGHTER]
CHRISTIAN HEILMANN: Oh god, lots of questions.
So let's have one here, the man in the loud shirt.
AUDIENCE: Sorry about my shirt.
I was just thinking, we've talked
a lot today about web performance
and things like that, and about, how does the whole performance
piece fit into accessibility?
We'll see one kind of coming to mind as things being too
fast where we're constantly working to speed things up.
Is there cases in accessibility where we actually
need to slow it down?
DEREK FEATHERSTONE: So I have a few thoughts
when listening to all the other performance things.
And one of the things that I heard
was, what's in the first 15 kilobytes?
And I started to think, what should be in the first 15
kilobytes for somebody that has a particular type
of disability?
And I don't know the answer to that question.
I think that's a great one.
I'm not sure about slowing things down.
Most technology, most screen reading technology
and other technologies, they work on top of browsers.
They're not their own thing, generally speaking.
AUDIENCE: Where I'm kind of coming from
is about the thought of perception,
if something changes on the screen too quickly,
and it becomes harder for visually impaired people
to actually detect that change.
DEREK FEATHERSTONE: So are you talking about in response
to some event that's happened on the page,
or like an initial load?
CHRISTIAN HEILMANN: Is it more like UX problems, isn't it?
I think like drop-down--
AUDIENCE: Something like a carousel.
CHRISTIAN HEILMANN: Yeah.
AUDIENCE: Yeah, just a case of stuff changing,
either naturally in a carousel, which is kind of automated,
or in response to an action.
DEREK FEATHERSTONE: So on a carousel,
for example, if it autoplays, you
have to be able to turn it off.
And you have to be able to start it up again.
So I'm not sure that that's really slowing it down
from a performance perspective.
But you should definitely allow for somebody
to manually go through the carousel
if you have to have one on your page.
We also do things like if the carousel container-- when
you detect keyboard usage within that container,
we automatically stop it from rotating
so that it immediately becomes a manual thing if you're
moving through it with a keyboard
so that you basically take a screen reader that's
on that content.
If it's suddenly whisked away, quite often what happens,
if the node is just slidden-- "slidden," nice word.
If the node slides out to the side,
that's different than if the node is destroyed.
And in some of these cases, screen reader focus is lost.
And they have to start over at the top of the page.
So that's something where we want to kind of give them
a little bit more control and--
CHRISTIAN HEILMANN: I think we're running the danger here
of getting into implementations and explaining to you how
to do a certain widget.
And we are open to discussion for that.
It would be wonderful to ask, get a few questions sorted.
And then we could answer offline.
Because [INAUDIBLE] would be like, do it like this,
or do it like that.
ALICE BOXHALL: To answer the broader question about timing,
there's language in WCAG about how long things should take,
how much time you should allow for things.
So that maybe gets a bit more at your question.
And also, to me, it raises a bit of a broader question, which
is, I'm curious how many web developers have even
looked look at WCAG here?
Quite a few-- cool.
To me, it seems like it's a great set of guidelines
for creating good user interfaces.
So for example, things like allowing error correction
in forms-- do we not all want that?
Do we not all want the form to lose all of our data
if we make a single mistake?
So yeah, I think the web would be better for everybody
if we all followed WCAG.
And this is an example of something
which is in there which we could learn about just from reading
the guidelines.
And of course, there's more.
There's stuff that's not in there.
Or there's stuff that needs more information.
But it's a really great place to start.
CHRISTIAN HEILMANN: OK, we're running out of time here a bit.
So we're skipping one of the questions that I've ceded,
sadly enough.
We have one from Aralia Moser here.
ARALIA MOSER: OK, you skipped a person.
CHRISTIAN HEILMANN: I skipped Dan Appelquist.
He can deal with it.
ARALIA MOSER: OK, so I'm wondering,
how do you prioritize accessibility in your workflow?
And right now, it seems that reactive
is something you need to do.
So how can we make it just the thing to do?
CHRISTIAN HEILMANN: It's the old question of,
where's the accessibility plug-in
that I can put at the end of my workflow?
How do you get accessibility into the workflow
from the very beginning in a cutthroat environment that
has not much time?
Derek.
DEREK FEATHERSTONE: It's got to be moved earlier
in the process.
If it gets to the end, and you're
finding accessibility issues for the first time in QA
or as you're preparing it for QA, it's too late.
It has to be done at the design level.
And I think if you focus very loosely on design, development,
and QA as kind of three important pieces,
not thinking about the business side-- that's important.
But the focusing on the transition
points I think is critical.
So having designers talk with developers and spec-ing things
out-- not like as in the spec, but here's
what my intent is with this design.
And so a design can specify things like,
here's how the keyboard flow should
work for this particular widget, or for this page.
Even working on it together, here's
the most logical source order.
Looking at this wire frame and the hierarchy of content,
here's the most logical source order for that.
And having that stuff passed all the way down the chain
is, to me, one of the most critical things that
would help address that so that it happens earlier
and we don't get to the end and say, I forgot.
CHRISTIAN HEILMANN: Andrew, what do you think?
ANDREW RONKSLEY: This is someone else's point of view.
I can't remember who exactly it was.
But it was talking about how the first time you do something,
it is difficult, and it takes you longer to do it.
So if you guys can remember the first time you built a website,
it was probably hard.
And it took you a long time.
The first time you built a responsive site,
your mind might have been a bit blown
like, this is taking me a long time.
But then, the next time you do it, it's easier.
The next time you do it, again, it's easier.
And then, it just becomes normal.
And it's kind of like that with accessibility.
It only seems hard because it's not
something you'll do day to day.
But if you do invest a bit of time and effort
into doing it a couple of times, your workflow will change.
And it just will become something you do naturally.
I can't remember whose opinion that was.
But I really liked it when I read it.
MATTHEW TYLEE ATKINSON: I completely agree with that.
And I completely agree with various things
that have been said before, like for example,
just try it out with a keyboard as you're doing it.
The most important thing is, as Derek pointed out,
to do it from the very start, from the design process.
But you're all going to be dealing
with stuff that already exists.
And there are some things-- I think
Alice mentioned accessibility testing.
You can't do it all mechanically.
But some of it you can.
And perhaps this is going to sound odd coming from me.
Because I'm very much reliant on me going to look at a site
and finding accessibility problems with it.
But there are a whole range of things
that you can test mechanically.
For example, does every image have an Alt attribute?
It's a very simple thing.
Now, one of my colleagues is working on
or has developed a tool, an API in fact.
It's going to be in beta soon.
It's called [INAUDIBLE]-- which can perform these tests that
can be automated.
And it will go away and perform them.
And because it's a command line thing,
you can make it part of your build process.
So if there were two biggest things I would say
is perhaps look at that, see what it can do for you.
Because it can be part of your build process.
A human being does not need to waste their time
on some of this stuff.
And the other thing is, make sure
that you can challenge yourself to, like Christian said,
take away the mouse for a while and see
if you can still use your site.
Some stuff like that you can really
reduce the amount of time and effort
it takes by making it part of your process.
And as much as possible, please do
try and consider it from the design stage,
from the absolute get-go.
And then, there's the other sorts of advice
that you've heard just generally sprinkled through about testing
things with a keyboard and stuff like that.
SARAH LEWTHWAITE: I'd like to just interject
a little bit of sociology.
Because I know that part of the issue
is that it has to be a team effort across your entire team.
Some people are going to value accessibility more than others.
And I think it's trying to position accessibility
as part of a norm, which is understanding
that disabled people aren't an out group.
They're part of your in group.
So at the moment, there's a term, aversive disablism.
So most people believe they're quite liberal.
They don't discriminate against disabled people.
But if you're designing for your group,
and that group doesn't include disabled people,
then you might as well be making disablist judgments.
Because you're still excluding.
The outputs are still the same.
So in that sense, it's important to sort of expand
the concept of who a normal user is
to include disabled people of who we know.
CHRISTIAN HEILMANN: OK, we have to wrap up.
So I have to thank the panel.
And I am incredibly excited about all of your interest.
Because having worked in accessibility
and having to shout at people for years
to consider accessibility, it's great
that there's a new way there.
It's kind of disheartening that we
have to remind people about something.
There seems to be a communication
gap between the accessibility evangelists and the developers
out there.
And a lot of things can be repeated
and have been said a few times.
So I'm really happy about this.
So take this idea, take this enthusiasm about it out there,
and pester as many people as possible
who know about accessibility.
And if you get grumpy answers, as Patrick said,
we're just people, too.
So that just happens.
So thanks very much again, and thanks everyone.
[APPLAUSE]