Well, thank you for coming today. It's a little bit
early where I am. I've been in Australia
due to the COVID crisis.
We're here today to celebrate AccessibilityOz's
10th birthday. I wanted to start the
presentation by showing you
a mug that I got created for the launch party.
I'm not sure if you can see it, hold on.
[Laughs] A little AccessibilityOz logo. The logo
hasn't really changed in 10 years, but
we have changed a few things. So today,
we're going to talk about the history of
web accessibility.
I myself have been in the industry
for a long time. 23 years.
And of course running AccessibilityOz
for 10 years.
And so that's going to take up the
first half an hour.
And then we've got some questions
that were submitted.
If we have time, we can also answer
some more questions as well. Not necessarily
on the history of web
accessibility but, you know, any questions
that you might have about accessibility.
Excellent.
So starting with the history of
web accessibility. As I said, I've been in
the industry for a while, but it started
before I got involved, so there might be
a few things that I don't know
a whole lot about, and I do apologize for
any errors. They are mine and mine alone.
The first thing that really happened
was in 1995 the Unified
Website Accessibility Guidelines were
released. Now, these were compiled by
Gregg Vanderheiden,
and he was actually the chair of the W3C
Web Content Accessibility Guidelines
Working Group
for many years when I was on the working
group in the 2000s.
Basically, they were created as a
response to the second
World Wide Web Conference.
Tim Berners-Lee, who of course
founded the World Wide Web, he went to a
pre-conference workshop on accessibility
by Mike Paciello, who runs The Paciello Group,
or used to run The Paciello Group,
also known as TPG.
And he mentioned disability access at
his keynote.
So basically these Unified Website
Accessibility Guidelines
were created by people who worked in the
industry, and version 8 was released in 1998,
so they had quite a lot of versions
in those three years, and that was the
starting point for WCAG 1.
In 1998, a number of things happened.
Firstly 1997, the Web Accessibility
Initiative from the W3C
was formed, and they started working on
the Web Content Accessibility Guidelines.
The other thing that
is really interesting is in 1998, Bill Clinton
signed into law the Workforce Investment Act,
which is basically the Section 508 amendment
which requires that accessibility
requirements are met for all electronic and IT
requirements purchased by federal
government in the US.
And this is a really big thing; this
really put accessibility on the map
and made people really look at
accessibility requirements.
So this is really important. Now in 1998,
they started working on WCAG 1, and a year later—
for those who've worked with the W3C, things
seem to work a lot slower now—
WCAG 1, Web Content Accessibility
Guidelines Version One,
was released. Now, it was released in 1999.
It consisted of 14 guidelines with 65 checkpoints,
and it was deemed to be too complex, but
of course WCAG 2 was a little bit
more complex than that. And it was not
technology independent, so it mentioned
things like server maps
and not having "click here" links and
things like that.
So it was much more specific than WCAG 2,
and it was something that we used for
many many years.
The important thing that really happened
to put accessibility on the map
was the first accessibility litigation,
which actually happened
in Australia, and that happened 1999
to 2000. Basically, Bruce Maguire,
who is a vision-impaired user,
wanted to buy tickets to the Sydney
Olympic Games which was
in Australia in 2000, and in
1999 he attempted to buy the tickets and
he was using a screen reader and he couldn't
purchase the tickets for a
number of reasons. Firstly,
they use JavaScript for navigation. They
use screenshots of tables of results
instead of coded tables.
And even though Bruce made a complaint,
the Sydney Operating Commission did
ignore Bruce Maguire, so he went to the
Human Rights Commission
in Australia and made a complaint and
SOCOG, which is the
Sydney Operating Commission of
the Olympic Games,
ignored Human Rights, and so it ended
up in court.
So that was a really big deal. And the
argument for the developers of the Sydney
Olympics Games
was that it would cost $16 million
to make the site accessible, and the judge
thought that was ridiculous, decided
that it would only cost $10 thousand
to make the site accessible, and so he
doubled that amount when assigning a fine. So he
fined SOCOG $20 thousand,
but he also awarded attorneys fees to
Maguire and HREOC, and
those attorney fees for Maguire were over
half a million dollars.
And SOCOG did bring people in from the
US to argue their case, so their attorney
fees would have been
quite high. And I was in accessibility at
the time. I'd started a couple of years before,
and I remember thinking "Oh, $16.5 million
to make something accessible!
Wow! I'm going to make lots of money!"
But I'm not in it for the money just
in case you don't get my sarcasm.
But it was an interesting time. It hit
the front page of every newspaper in Australia,
and it really put accessibility on the map,
especially in Australia. Around that time I joined
the W3C Web Content Accessibility Guidelines
Working Group, and I was with them from
2000 to 2006, I believe.
That was a lot of work and I
worked with some great people over those
years. So in 2006,
we had the first public draft of WCAG 2 released.
For those who weren't in the industry back then,
it was quite controversial. So,
there was this criteria called "testability,"
which required that everything that
is in WCAG 2 needed to be what we call
quote unquote "testable," and that meant
that 8 out of 10 human testers would agree on
the outcome, or that you could get an automated
testing tool to test the requirement, and I
actually wrote an article for A List Apart
arguing that testability— I think I
called it "Testability Cost Too Much"—
and I argued that it was basically
impossible to get
accessibility specialists to agree on
anything. My example was, say, an ALT attribute. We
could definitely all agree that perhaps
an ALT attribute was incorrect but not
necessarily that an ALT attribute
was correct.
So I had some examples there.
That was also around the time that Lisa Seeman,
who is an expert in
cognitive disability requirements,
lodged a formal objection which was
signed by about a hundred people, and I
was one of those people.
And that was basically a formal
objection that said that WCAG
didn't address the needs of people with
cognitive disabilities enough.
And so as a result of that, WCAG 2
was kind of pulled from public
release and worked on for
a couple more years. Now that was the
time that I actually
left the WCAG Working Group, and I
started working with Joe Clark who was very big
in the accessibility community at the time, and
we worked on something called
the WCAG Samurai Errata,
and what we argued was that instead of
having WCAG 2, that we needed to have basically a
revised WCAG 1, which is what the
WCAG Samurai Errata
were. So that was basically a bit of an
argument in the industry at the time,
whether you used WCAG 1. WCAG 2 was
published in 2008 and I published a blog post
that said "this is why I'm still
using WCAG 1." And after a couple of years I
came around to believing in WCAG 2
and sort of seeing that there was enough
support and techniques and explanations
there to support the use of WCAG 2.
But WCAG 2 was very complex
compared to WCAG 1, and it did cause a lot of
ruction within the accessibility industry.
So the next big thing that happened was 2008.
Target in the US was sued by the
National Federation of the Blind.
Now, they argued that a lack of ALT text meant that
people with vision impairments
couldn't purchase online,
that online purchases required a mouse,
that they had inaccessible image maps—
remember image maps?— and they had
actually been making complaints
about the Target websites
since 2005 so for three years, and they
eventually went to court.
The judge found that even though
the site was not connected to a single
physical place, they were connected enough to be
included under the accommodations
requirements. So that was a really interesting
decision and it meant that there became
a lot more lawsuits in the area.
The other thing that was really
interesting about this is that they settled
out of court, so they didn't actually
wait for a judge to award settlements.
They settled for damages of $6 million,
which is a huge amount of money if you
think about it, and
NFB were awarded attorney costs, which were
about $3.5 million. So we're talking
about a lot of money.
And at that point there was a flurry of
work in the accessibility industry, as
there was around 2000 as well
because people didn't want to have to
pay that much in terms of damages. So the next big
lawsuit was in 2012 against Netflix.
They were sued by the National
Association of the Deaf
for not having captioning. Now this was
the first time a company in the US was
sued that didn't have an actual public location,
and Netflix argued a number of reasons
why they didn't need to meet
accessibility requirements. One, they
didn't have a public location so the act
wasn't applicable to them.
They also argued that if they provided
captions to video,
even video that had captions previously,
they would actually be in copyright violation
of all the TV shows and movies that they
had access to.
The judge did not agree with them and
awarded $795,000 in damages.
They also required that Netflix have captions
for all their content within two years, so by 2014.
And they did meet that requirement, which
was great. The other thing that was
interesting about Netflix
is in 2015, they released a TV show
that they had created themselves called
"Daredevil," which was about a blind superhero
that went around
fighting crime in New York. Now, just like
captions are needed
for people who are deaf and hard of hearing,
audio descriptions are needed
for people who are vision impaired
or low vision, and a blind superhero
might be of interest
to people who are vision impaired, but
when they released the TV show all at once in 2015,
it did not have audio descriptions and
that there was a bit of a furor
in the accessibility industry at the
time about 'how dare they
do this?' Now, Netflix did release
audio descriptions within three days so
it may just have been a scheduling issue,
and they are really really good audio
descriptions, so definitely worth
looking up if you can find them.
For the Australians in the audience—
I saw that we had some Australians;
you're up rather early—
in 2014, Coles, which is for the Americans
a bit like a Trader Joe's. Coles was sued for
having an inaccessible website. Now the
interesting part about that
is that they'd actually worked with a
vision impaired person
for several years to make their site accessible,
and it was, and someone who is vision
impaired could purchase things online and
things like that. But then mid-2014,
they released a new system and that
system was not accessible,
and this coincided with the retrenchment of
the Disability Discrimination Commissioner
in the Australian Human Rights Commission
by the Liberal— Liberal large "L," so our conservative
government— in 2014. And so the woman that had been
complaining found that
she basically had no recourse. Coles
were no longer taking her calls. She didn't have an
advocate, and so she went to the next avenue which
was to actually sue Coles. Now, it was settled
out of court. We don't know for how much;
laws are a little bit different in
Australia than they are in the US.
But it's generally assumed it was in
the half-million/quarter-of-a-million dollars
mark, so that also created sort of interest in
accessibility in Australia.
And then the next thing that happened was
EN 301 549, which was around 2013 and 14,
which is basically where the European Union
required that public procurement of all
EU ICT products and services
needed to be accessible so basically
the equivalent of Section 508, which made
accessibility a bigger thing in Europe.
Then we had in 2014... 2014
I actually spoke at The Design of the
Web, I think, Future Design of the Web,
something like that, in New York about mobile
accessibility, and it was starting to be a big
thing. We really knew that WCAG 2
wasn't enough in terms of mobile accessibility,
and so in 2014, the BBC released their
Mobile Accessibility Guidelines, and they
were basically seen as the de facto standard
for mobile accessibility requirements
for several years.
There are a couple of problems with them
though. One, they merged mobile app and mobile
site requirements, and so often when
you're working on an app
the code is completely different, etc.
This is long before React, where you could output
a site and app at the same time.
And the other thing is a few years down
the track, the BBC came out
after a lot of, I suppose, complaints
about how they didn't address certain
requirements and said
"Hey look we never expected that these guidelines
would be seen as the de facto standards.
We wrote them for ourselves.
We're a public broadcaster; we have very
different requirements to say an Amazon
or an eBay, and we really don't think that our
guidelines should be used by everyone."
But it was definitely something that a
whole lot of people used for several years.
2018, WCAG 2.1 was released which had been
worked on for several years.
There had been a decision in the working
group that WCAG 3 was going to
take a lot longer
to write and that they really needed to
address the requirements that had been
missed or the things that had changed.
The big things that were addressed were issues
around people with cognitive disabilities
and people with low vision and, of course,
mobile requirements.
So coming back to WCAG 2. WCAG 2 success criteria
are definitely applicable to mobile,
however not all aspects of mobile
accessibility are specifically covered
by WCAG 2. So, for example, WCAG 2 requires
that sites be accessible to the keyboard,
however it doesn't require that sites
are accessible to the touch screen.
And so 2.1 included things like touch target size
and things like that. A lot of the
cognitive disability requirements
were relegated to level AAA, which was a pity.
Now, in 2017, so prior to the release of 2.1,
I attended the ICT Accessibility Testing
Symposium, and we had what we called a Town Hall
at the end of this conference.
Now this is a very unique conference in that it's
aimed at accessibility testing specialists,
not at people like developers or things like that,
and at the end of each conference we
have this town hall where we talk about what the
community needs, what is missing,
and at the end of 2017, the overwhelming
argument was that there were no specific
mobile guidelines. All the big accessibility
companies had their own mobile
accessibility guidelines and they
weren't consistent with each other,
and that was a real problem. So a group of the
testing specialists got together from all
the big companies: Level Access, TPG, from us, etc.
And we basically amalgamated all of our
mobile testing methodologies
into what we call the first ICT
Mobile Testing Methodology, and so we
worked on that for a year
to put them all together into a format
that would make sense
and it was released in October 2018,
a few months after
2.1 was released. Now we really hoped
that 2.1 would be released
and that that would fully address the
requirements of mobile, and that we wouldn't
need to do any further work; however
even though WCAG 2.1 does address more
requirements regarding, say, touch screens, etc.
and small screen devices,
it was a decision in the next ICT
Accessibility Testing Symposium
that it didn't go far enough, and the one thing that
we can indicate with that is the touch target
size requirements. So basically the
requirement that an
actionable item on a mobile device is a specific
size, so it's not so small that you can't tap on it,
is a AAA requirement and in general,
us accessibility specialists know that
guidelines go to AAA to die,
if that makes sense. A lot of AAA
requirements don't get
met, and so we decided to reform the
committee and we basically started again. We
started with the amalgamation of the
requirements but then we built on them, and what
we did is we added
WCAG 2.1 requirements and we added some
AAA things that we thought were really
important for accessibility,
and we basically developed them and
we released them in 2019.
So once again we worked with—
that was something that
the entire accessibility industry was
involved in and it's something that we
are reforming the committee
this year, so if it's something you're
interested in we'd be really happy to
have you involved. Now I hadn't set this up but
I'm just going to show you where this is.
Okay so this is the AccessibilityOz website.
Under "Resources," there is a section
called "Mobile Testing,"
and here it's got a whole lot of
information and we split up the
requirements into Mobile Site Testing
and Native App Testing, and so you've got
the actual methodology,
so basically the requirements or the
success criteria.
Then you've got the section About Mobile
Site Testing, so how to choose devices or
assistive technologies,
site types, are we talking about
m.dot sites or responsive sites?
What do you do if you've got
variations of the page, say,
different content served to
browsers versus main sites and how you
capture errors? Then you have the Critical
Test Cases, the Test Cases and
Assistive Technology Test Cases, and we
have information about the requirement,
information on how to test and passes and fails.
Now if you want more information about
that, I definitely recommend going to
"Resources" and then "Webinars,"
and then looking at this first webinar
which is How to Test the Accessibility of Your
Mobile Websites and Apps,
and that goes into it in a lot of detail
in terms of how you use it, etc.
So that's basically where accessibility
has been. In terms of us, I just wanted to
spend a couple of minutes talking about us;
it is our 10th birthday after all.
So this is our team
a couple of years ago. We are a small team.
I have staff around the world. We have
clients around the world as well, and when I
started AccessibilityOz 10 years ago,
I wanted to support people with
disabilities by providing them with
employment opportunities as well as
working in accessibility,
and so about 60% of our staff
have some kind of significant disability
that affects their daily life
and you wouldn't necessarily know that
to look at us,
and that's something to remember is that
often people with disabilities are
hidden in plain sight, but we've had people with
dyslexia, moderate vision impairment, epilepsy,
migraines, severe vision impairment,
physical impairments, PTSD,
Crohn's disease, multiple sclerosis and
cerebral palsy, and the one thing that I always
point out in my presentations is it's not just
about vision impairments. Accessibility is
much larger than that. And a lot of people who
are new to accessibility talk about
screen reader accessibility,
and that is of course very important, but
there's a lot more to it than that.
And just a little bit about me: I started
in the industry in 1998.
I worked on the very first accessible
website in Australia
called Disability Information Victoria,
and then I worked on
the Vision Australia website, so for
those who are aware of Vision Australia, I did
work on their website very early on. In 2000,
I created Australia's first automated,
accessibility testing tool called PurpleCop.
For those who remember back then,
the very first automated
accessibility testing tool out there
was called Bobby. It was based on an English
copper. That was my little riff on Bobby, and
my company was called PurpleTop, so that's why
I called it that. I had a company, PurpleTop,
from 1998 to 2004. In 2000, I was an invited expert
to the W3C WCAG 2 Working Group, and in 2006
I worked on the Melbourne 2006 Commonwealth
Games, and they worked very hard to make sure
that the thing with the Sydney
Olympics didn't happen again
and it didn't which was great. Then I spent a few
years managing usability and accessibility
services at Monash University, so I'm very aware
of what it's like to try and get accessibility
in university. What I used to say is
"lots and lots and lots of
websites and teeny tiny budgets,"
so I know that that can be very difficult, and
we just spent five years working with
California Community Colleges Tech Center
working on making their 114 California
community colleges accessible. And then I
founded AccessibilityOz in 2011,
10 years ago today. 2013, we released OzPlayer,
which is our accessible video player, in a
response to— we often did audits, and we would
always find that the video players were
inaccessible, often contained keyboard traps,
and our clients would say "Well, what are
we supposed to do instead? What are we supposed
to use? What's accessible?" And we'd like
"Hm, there isn't much out there." So we built OzPlayer.
2013, we released OzART, which is our
automated accessibility testing tool.
We actually had started building that on day one;
however we didn't release it commercially until
2013. 2015, something that I'm very proud
about: I spoke at the United Nations on the
importance of web accessibility.
I talked about the massive fires that
were in Victoria in Australia
in 2009 and killed over 100 people,
and something like 45, maybe 50%,
of the people who died were people with
disabilities, and I talked about how it's really
important with natural disasters
that you provide accessible content.
2016, I was nominated for Australian of the Year.
2017 and 18 and 19, I was the chair of the ICT
Mobile Site and Native App Testing committee,
working on the methodology, and last year I'm
really proud to say that I won the inaugural
Accessibility Person of the Year. So that's
me. About our products: as I said we have
OzART and OzPlayer. OzWiki is our
database of accessibility errors,
screenshots, code and solutions, and as an
attendee of our presentations, you get six
month's access. We also have Factsheets,
Accessibility Voices, and videos, which I'm
going to show you very briefly.
These Factsheets were commissioned by the
Australian Bureau of Meteorology, and
basically it's on these different
categories: Images, PDF, Video, Interactive Maps,
HTML5, Content, JavaScript, Tables, Coding,
Keyboard, Source Order, Forms and Mobile. And so
they have a section here on
accessibility principles, why you should
make page titles accessible, or text
content accessible,
etc.; the impact on users, what actually happens
if these things are not accessible. We
have what we call a manager checklist,
which is basically a testing checklist
and a developer checklist,
which has correct and incorrect examples.
So you can see here
the requirement "A1: Page title should be coded."
The requirement is all pages must have a
page title. The correct example is
"title Bureau of Meteorology - Home Page end title"
Incorrect example is that no title is present.
We also have these things called the CCC
Developer Videos, and so we did these in
conjunction with California Community
Colleges Tech Center.
We have 16 videos on HTML, Forms and
ARIA, and all of them are under five minutes,
on things like creating HTML headings,
keyboard focus, check boxes and radio buttons,
creating accessible error messages, how
not to use ARIA, etc. Now these and the Factsheets
are all available under Creative Commons,
and so that means that basically you can
use these, put them on your website,
repurpose them. As long as you attribute either
CCC or the Bureau of Meteorology, you can do
what you like.
And so that's basically it for me.
And now we get on to any questions, so
please let me know
if you have any questions starting about
the presentation itself and if I got
anything wrong.
[No audio]
Excellent, well I obviously just stunned you
with all the information in
accessibility, and I do have to apologize,
that that was my cat crying in the
background. I don't have some baby that
I'm just ignoring, just have a cat that I'm just
ignoring. He obviously wants to get fed.
And so what I'm going to do now is start with the
questions that came from the lists
that we got sent. So the first question is
"What's in store for the future—" Oh let
me turn on my video.
Yes, Bobby. If you remember Bobby,
Bobby was pretty good. Bobby was great.
And Melanie Thornton, I mean yeah, we're
all showing our age if we remember Bobby.
But okay so the question is "What's in
store for the future?"
So I really think— and this kind of
builds into the next question is "What
about accessibility in new AI technology?"
Now I think that really things will change a lot
with AI, and when I say AI, I don't mean the
real artificial intelligence where
computers have consciences and things
like that, but more kind of machine learning.
But I do think it will make a big difference,
but I think there's going to be a lot of
trial and error. We all have seen
some of the automated generated ALT text;
it's not great. It will get better, and I think also
there has been a history of things that
have been created for people with disabilities
ending up in the mainstream. So, Siri
is basically a continuation
of a requirement of basically the YouTube
captioning features, auto captioning features,
and so it's the same kind of engine that
worked on creating auto captioning for
YouTube videos that then goes into our
Alexas and Siris and things
like that, and it seems like there's a
lot of things that
were created initially for people with
disabilities that end up in the mainstream. So I
think that that's going to be really
interesting, and it might actually end up
being the other way around now with AI and
people creating games and 3D spaces
and things like that, that will end up being
really interesting and really helpful
for people with disabilities. So I'm excited
for the future. I will say though that
there's always been, in the 20-odd years
that I've been doing this,
there's always been a kind of period where
people go "Oh my gosh, accessibility, it's
going to be like this big thing!"
And so it's sort of seen as the next big thing. And
I think that people are definitely talking that
way about accessibility with COVID, right?
Like "Oh, everyone has to go online, work from
home, etc. etc. So therefore everyone's going to
about accessibility and people are going to put
millions into it and address it the way
that it needs to be addressed."
Unfortunately, these things are often
flashes in the pan. Every time there was a
lawsuit, there'd be venture capital companies
getting in. There'll be a lot of
purchasing of different accessibility
companies, and it just became this big
thing. And then a year, later two years later, it was
back to normal. So it's an interesting industry.
It kind of has its ups and downs, and
I do think that with AI it will be something that
is unusual; we won't have seen it before.
The next question I have is "When using
ARIA label attributes on links that
might say 'Read More,'
is this enough for accessible links?"
Look, there are a lot of people who will disagree
with me. I personally don't think that that's
enough; however, I do think it's better than not
having ARIA label attributes on links,
and sometimes you need to decide
what you're going to argue,
and if it's going to be a lot of work
to change those "Read More" links,
maybe that effort is better spent on
some other area of accessibility.
So the reason why I say ARIA label
attributes aren't enough
is because ARIA label attributes are
absolutely fantastic for screen reader users
and for, say, other assistive technology users,
but they're not visible or accessible to
people with cognitive disabilities.
People with cognitive disabilities
also find those "Read More" links
difficult to understand,
so that's why you will find
that it's more accessible than not
having the ARIA label attributes,
but it's really not perfect. But then
most things usually aren't.
The next question I have is
"My views on assistive technologies."
Look, in all the work that I did with
mobile or that we're still doing with mobile,
I'm absolutely stunned at the assistive
technologies that are available on
mobile devices,
and that keep changing. So we released
the latest version of the testing methodology
about a month or so before iOS 14 was
released, and iOS 14 had some fantastic
additions, like dark mode, that
really are useful to people
with disabilities and I think that
the thing is is that there are a lot of people now
who use assistive technologies without
actually ever identifying themselves as a
person with a disability.
My stepmother, for example,
uses increased text size on her iPhone
but she would never argue that she had
low vision. She'd never think that she
had low vision, and I think that these
assistive technologies are
just sort of part of life now, and they make
the world more accessible to a whole lot of
people who wouldn't necessarily consider
that they would need an assistive technology.
The next question is "How much of digital
accessibility falls in the hands of designers
versus developers?"
Look, I think a lot of it is developers.
I think that there are some design
requirements that you do need to be aware of.
I do have some blog posts
on design accessibility that you
might be interested in,
but a lot of it is developers.
But having said that, there's a lot that
developers won't be able to do
if the designers haven't done it
correctly, so I think it's
a bit of both. Having said that,
we run training for designers and we run
training for developers.
Our training for designers is half a day
our training for developers
is four days, so that's a fairly good
indication of the difference between the two.
Jeremy says, "My iPhone has nearly all of
the core accessibility software
that our entire AT lab had in 1997."
Yeah, that is absolutely mind-blowing and
that's true. So that's another thing to remember is
that often people with disabilities
they won't have a laptop anymore
because their assistive technologies,
they are just built into an iPhone.
If you're a screen reader user,
why would you carry around a laptop? You
can't see the screen, it's heavy and bulky.
Why wouldn't you just use your iPhone?
So be very aware of that.
My next question is "How does WCAG handle
digital math for braille reading students?"
Now I had to do some research here,
and so there is the W3C Math Home. Let me
share my screen. And they've just started another—
basically they've just started a working group.
So I'm going to put this in the chat.
So there's definitely some stuff here that's
worth looking at because they are looking at
MathML in more detail, but if you're looking
at an actual kind of technology
to help students, there's some great things
under Perkins, so I'm going to send that out too.
And there's also some stuff here from
the American Association of Blind Teachers
around general resources for maths and science.
So there's some fantastic things here,
but basically when it comes to WCAG, MathML was
kind of the thing to use,
and then for a couple of years it
kind of fell out of favor,
and then it kind of— the W3C sort of said
MathML is the way to go.
So there's definitely some stuff there
to have a look at and if you can't find
it just let me know.
Now I have another question that's rather
technical which is "What are MSAA hooks?" Oh, I
thought the question was "Can you talk more about
MSAA hooks?" MSAA hooks are Microsoft Active
Accessibility hooks, and they're basically
ways that you hook in accessibility into
desktop applications.
There's a great website here
that describes the hooks, which I'm going
to put into the chat,
and there's also a Hooks Overview under
Microsoft Docs that will be helpful as well.
And the last question that got sent in
was "What are the best practices for
ALT text and captions? When are we
writing too much?" This just got sent in recently
so I haven't been able to actually look up
the reference, but there's a fantastic document
by GSA, I think, about the 28 types of ALT
attributes. So basically, the biggest thing I can
say about ALT attributes and what you should
write is it is more of an art than a science.
You don't want to put more information in
the ALT attribute that is not in the image, but
you don't really need to go overboard.
Now there is a lot of discussion around this. I did
some training for people with disabilities
who were editing websites,
and so I had about five or six people
who were vision impaired
who were in the class and some of them wanted
really detailed ALT attributes:
the color of people's hair,
what they were wearing, that kind of stuff.
And then others were like "No, I don't want anything
at all. Just give me an empty ALT attribute."
So my best recommendation for this is
make sure it's consistent across your
website. So choose a sort of level of verbosity
and stick with it across your website.
Now one thing I will say
is ALT text is very different to captions.
So a caption is something that can be seen by
everyone in addition to the image, whereas ALT
text is a description of the image.
You never want the ALT text and the
caption to be the same.
So the caption might be the name of
people, and the ALT attribute might be a
description of them.
But the best way to really decide
how to write ALT text is to think about
what the function of the image is. So
if the function of the image is a link
to the home page, then it doesn't really matter
what it looks like. You need to just tell the user
that it's a home page. And you don't need
to say that it's a link
because the screen reader will say that.
If the image is a little arrow that the
function is a link to the next page,
then the ALT attribute shouldn't be "arrow,"
it should be "next page." Now the one exception
for this is when you have
ALT attributes for image galleries and,
yes, you must have ALT attributes for
image galleries. If you have an image
gallery of, say, butterflies,
then you don't want to have ALT
attributes of "butterfly," "butterfly," "butterfly."
And the caption is usually the name of
the butterfly, so you don't want to put
the ALT attribute as the name. So in that case,
you will want to describe it in detail.
So, "Red and black butterfly with brown spots,"
that kind of stuff. So yeah,
have a look for that GSA ALT attribute
website and if you can't find it, reach
out and I'll send it out. Okay, so we've got a couple
questions on chat and on Q and A.
So, Anna, great to see you and thanks
for attending the presentation.
"Additional perspectives on the future of
accessibility related to online learning
LMS platforms and e-tools."
I think we're going to see a whole range of
changes to online learning. I think
we'll probably see
a lot of gamification. If anyone remembers
Google Wave, I think it was called Wave,
where Google had kind of a whole bunch of
different things partnered together and when
I was at Monash, we actually looked at it
It was a chat system, it was a
docs system, etc. I think we're going to see—
Oh yes, it was Wave, thank you Laura.
I think we're going to see
a lot more like that, and the problem is, of course,
whenever there's kind of a increase in
technology, the accessibility always takes
a little while to catch up, so I think that there
will be a real increase in technology and
accessibility will kind of fall by the wayside.
And then I think there'll be maybe another big
lawsuit, and things will change.
People go "Oh my gosh, we need to worry about
accessibility!" and then people will say
"Oh, accessibility is the next big thing!" and
everyone will get on the
accessibility bandwagon for a couple of
years, and then we'll just go around in circles.
So yeah, I think that it's
going to be an interesting time but
I think that with COVID, a lot of people
are spending a lot more time thinking
about online. And, Laura, thank you. "Great session, I
could listen to you all day." Aw, thank you.
But yeah, I think that they'll be a kind of increase
and we'll see accessibility eventually catch up.
Rob Harvie: "May be out of scope. Have you seen
anything more recent to add on the CAPTCHA
debate?" Yeah, and the Working Group,
well 20 years ago, released a document that said
CAPTCHAs are not accessible.
but there was a discussion, I was in the
discussion, I didn't agree with it,
about how we had to allow CAPTCHAs in WCAG 2.
I wanted to make them just "If you have a CAPTCHA,
you can't make WCAG 2."
But the argument was that if we
didn't allow CAPTCHAs in WCAG 2,
then clients or people who use CAPTCHAs
would then go "Oh well, we can't be accessible. We're
not going to address anything at all."
Now CAPTCHAs are notoriously inaccessible.
They're still inaccessible.
Every six months or so we test
Google reCAPTCHA because that's the
thing that's closest to accessible,
and it's actually less
accessible than it was about 18 months ago.
The audio version of the reCAPTCHA doesn't work.
it's fantastic if you get that little thing
that you tick and say "Hey, I'm not a
robot," and it goes "Oh hey, you're not a robot,"
that's great but anyone who uses an
assistive technology
like a screen reader is going to trigger
the actual CAPTCHA itself,
and that CAPTCHA is completely inaccessible.
And I have tested a lot of CAPTCHAs and
CAPTCHAs are never accessible.
I have never come across an accessible CAPTCHA.
There are some things that you can do instead.
Human test questions. But really you need
to do server-side validation
to catch spam things. That's what you need to do.
So yeah, definitely CAPTCHAs are problematic.
There is actually another document that the
Working Group wrote on CAPTCHA accessibility
a couple of years back, maybe even a year back.
So we'll put that out as well. I'll find that
and send that out as well.
Okay, Laura: "How is the approach in
WCAG 3 different from 2.0 and 2.1?" It's very, very,
very—did I mention very?—very different. So
there has been a lot of argument around
the whole kind of black and
white perspective of WCAG 2. You
either pass or you fail.
What if you kind of— you know like the ARIA
label attributes. It's not perfect but it's not a
fail, but it kind of is a fail, but it's
not really a pass and it kind of is a pass.
So WCAG 3 has basically a scoring
system which is kind of like "if you meet
this requirement, you get one point.
You meet that requirement, you get two points," etc.
I haven't had anything to do with writing it.
I personally think that it's overly complex,
however, we are on really early stages of WCAG 3.
There's I'd say at least five years before
we end up seeing it as an actual recommendation.
So I think that there'll probably
be a whole lot of changes before we
get to it, but I think at the moment, it's
problematic. I think they might be looking at it
from a kind of automated tool
perspective in that you
kind of automate these kind of things.
But yeah, I think that it will be very different, so
definitely look at 2 and 2.1. 3 is still a while away.
I have a question here from Carol: "I came in late,
so if you talked about it please skip
this question. What motivated you to
start in the field of accessibility?"
I actually didn't answer that
question. I used to say,
probably up until about five years
ago, I used to say— I actually
started in '97 working for
an IT firm that wrote documentation for
windows applications, and then they spun
off a company that built websites,
because this is really really early on, you know.
These were like the first websites ever built
for government departments and
things like that, and we won a contract for
Disability Information Victoria,
and I was kind of the Girl Friday, and
we were like "Well blind people can't use websites,"
and they're like "Well actually they can."
And I was given the task to figure out what that
meant, because this is before WCAG.
There used to be emails that would
go out saying "These are all the new
websites that have been released this
week," so it was a long time ago.
So, that's how I started professionally, but
actually— so, that's the story I always used
to tell, and it was really important to me. It
was always— I just always saw it as
something that, it was really something that
you had to do. I didn't understand why people
didn't do it, and then probably about five years
ago I was watching TV at 2:00 A.M. in the morning,
and this TV show called Press Game came on,
and I remembered it because I absolutely
loved Press Game when I was at school.
It was about a Canadian school, I think,
and about newspaper people in Canadian school,
and one of the minor characters was
quadriplegic and they used a sip/puff machine,
and it all came back to me. That was my first
real time that I'd seen someone with a disability,
a significant disability, in media. And I
went through the things that most people
go through like "what is that person doing?"
"They're going to take longer doing things.
Why should we give them accommodations?" to
just seeing them as a normal person, and
so when i got involved in accessibility a few
yeard later, it was natural to me that someone
with a disability would want to access all
this content and would want to do so easily. So
that's how I got into accessibility.
Anna has asked "Are mobile devices highlighted
and recognized with a body in Australia or in
the world as an assistive technology somewhere?
In education they are blanket banned."
Wow, oh yes of course they are. And I was
thinking "really?", but I'm thinking schools,
yes of course. "And if they hold all accessibility
software since 1997,
it seems a no-brainer for it to be
recognized somewhere for people."
Yeah, look, that is a really good point.
I don't know the answer to that, but you are correct.
Like I think that there will be occasions where
it makes a whole lot of sense for a person with
a disability to have access to a mobile device
to access the content because they can't see the
board or their laptop doesn't have the right
assistive technology or something like that. So
I will have a look into that and let you know.
So I'm not sure what Jeremy means:
"New releases plus Lynx plus JAWS,"
but I'm sure it's good. So, I think that we're going
well on time. Thank you everyone. Thank you for
sticking around and listening to me talk.
I do love accessibility and I'm really happy
that we've made it this far, and I want to say
I know I'm the face of accessibility—
AccessibilityOz, not accessibility—
the face of AccessibilityOz, but I wouldn't have
made it if it wasn't for the fantastic
staff that I've had over the years,
so I want to thank them, and also the
fantastic clients that we've had.
And we do really want to help people,
support people when they're investigating
accessibility and looking into it, and we know
that a lot of you don't have a whole lot of
money to deal with these things, and that's why
we have things like OzWiki and the Factsheets
and stuff like that. So we do really try and
work with you in that way. So please keep
in touch. We'll hopefully be doing
something like this ten years from now
in which we'll be saying "Hey, we don't
need to do anything. We're all sitting on
an island because everything's accessible."
And yes I will share the slides.
We'll send out a link to everyone
who's registered with a recording and
the links that I've mentioned here
in the chat, as well as the additional things
that I said I would send out. So Paul,
if you want to mention anything
in the chat, you're welcome.
So thank you very much. Anyone else have any
further questions before we get going?
And if you really want to you can hear me
talk about this again in... well, it's how
many hours? Six hours. That one will be a little bit
more Australia-focused. And yes, I wish I could
send you all a mug but I think that, with the
Australian postal system, USPS and the
breakability of the mugs, probably not a good
idea. But yes, we'll see what we can do.
Thank you very much, and I will talk to you all soon.