>> Hiya.
What's happening!
I'm really happy to be here, and to talk to
you about a topic that is very close to my
heart.
Today, I want to talk with you about comics,
and more specifically, I want to show you
some of the great things that I found on the
internet, and how to create comics on the
web and the learning I had when I tried to
create my very own web comic and how to make
this comic actually accessible, not only for
a few or some but, actually, for literally
everyone.
This topic is so close to my heart because
as many of you here in the audience, I'm a
great fan of comics myself.
I can remember when I was young, I would go
to the comic book store, or maybe to the corner
shop and grab a magazine, sometimes like even
hard-cover comic books, and try to learn more
about the stories and the adventures of my
favourite protagonists and heroes.
I think most of you can actually relate to
this.
Probably everyone can relate to this, don't
you think?
I was thinking back then, when I was so enthusiastic
about comics, it would be so cool to make
comic art myself.
Things turned out differently - I'm working
as a software engineer, build web applications
and other things, but I like to draw in my
free time.
I thought maybe I could make it a hobby or
activity that I just pursue in my after-hours
after work, and I actually maybe create something?
So I had a look at what my options were.
I remember from back in the time that print
comics like the traditional medium of comics
as we already know it for centuries, in fact,
is something that might be worth pursuing.
And I looked at what the challenges were that
I had to overcome to do this.
I realised that there were a couple of them
that came into my realm as a comic artist.
First of all, I would have to find a way to
publish myself, or maybe find a publisher.
I couldn't get ... to get my work out, which
seemed like a laborious process.
Then I also realised that, when I actually
wanted to make people aware of where my comic
is and what it does, I had to focus on print-based
marketing.
Maybe I go to a fair, or tell me in person
what this comic is about.
Last but not least, also I would have to go
to this month or a year-long thing where I
actually draw everything, hand it into my
publisher, and they edit, and they correct
it, and send it back, I have to reedit it,
until I actually publish my first comic.
And this already seems like a bitch, but then
I looked on the other side, how does it look
for challenge-wise for people who want to
read my comic later on?
How do readers of my comic interact with this
and what do they have to overcome?
I realised that first of all they have to
have physical access to the medium, so they
have to go down to the book store, or at least
they have to go to the door when the mail
order arrives, or pick up the package at the
Post Office.
They also have to carry around the book and
actually bring it with them.
They can't even go out with a whole library
of comics.
They maybe take a book or two, and this is
about it because of portability concerns.
But something that really struck me when I
thought about it a little bit longer was something
much more significant, and, in fact, I kind
of like didn't really consider that there
is this very kind of essential prerequisite
that I have to fulfil when I actually read
a printed comic.
That is it actually requires me to have almost
perfect vision.
I actually am required to be a sighted person
to read a comic book from, I don't know, everything
funny - or my Mickey Mouse magazine.
This is something I found really odd to think
about.
I was, "I didn't even consider this."
Because I looked like a sighted person all
my life.
I never even bothered to think about it.
Then, after this, I was okay, but, actually,
are there options?
Like how do you actually read comics when
you're blind?
Or a visually impaired person?
I looked on the internet and I found a lot
of interesting ideas of people who are already
putting into practice what I couldn't imagine
even until this point.
People who actually tried to expand out of
the visual realm of comics to other fields
of senses.
One project, for example, I found interesting
was some that tried to explore haptic senses
and audio senses, so people who might have
never had the ability to actually read comics
but also those who might have lost their vision
during their life could go back and read their
favourite stories again as they used to.
One of these projects, for example, is called
Live, by Philip Meyer, and he creates a Braille-like
comic book which shows the stories in a haptic
manner.
You can touch the material in front of you
to understand what is going on, and to understand
where locally and spatially protagonists are
currently in.
This is an interesting web comic written by
Christopher Wright who makes an intentional
effort not only to upload every single image
of his strips on to his personal website,
but also includes right next to it a comic
transcript that can be read by screenreader
users once they browse the website.
I think the most inspiring project in my opinion
has been Comics and Power which is a comic
book store created for the blind which features
several very popular comic books very well
that are narrated by a - generated by a single
person in a fashion that creates this illusion
that you actually reading the comic, you're
putting up the comic book reading from panel
to panel the text, but also the sound-like
descriptions of any kind of noises.
And I found this really cool.
Looking at this, and actually trying to find
out more about the guy who actually did this
to create this very immersive experience using
audio-generated comics, I wanted to try something
similar myself.
I wanted to dive deeper into what can you
do with audio?
How can you tap the potential of audio-narrated
stories and how can you make use of this quite
easily on the web?
I knew that screenreaders were a quite straightforward
approach because I knew so many web pages
could be read by screenreaders if it was done
right.
So I started out.
In my day-to-day work, I actually work at
a consulting firm that also specialises in
helping clients with Ruby and Amber, and this
would be familiar for me, I was thinking it
would be cool if it was like a JavaScript
application with the Amber text stack because
this is familiar.
Also, it actually helps me later on because
it's already a fully fledged single-page application
framework to scale my application easily with
co-released and co-maintained dependencies,
like data library, a testing solution, or
also routed solution out of the box to make
it easier for me.
I would know that two years and three years
from now, this app exists, and it should also
work and be maintainable.
Last but not least, I also thought it would
be so cool if it was like a proper JavaScript
application because then I can actually with
all of this interactivity, interesting animations
for a sighted user experience that might also
be very immersive and interesting to explore.
So, looking at the approach that comics Comics
of Power provided, I wanted to have a similar
user story for screenreader users for those
who use assistive technologies to browse the
web comic.
I wanted to write an embedded transcript.
I couldn't think about having the transcript
right next to the page.
I actually wanted to have the experience that
would be similar to someone coming to the
website and reading panel for panel.
I also wanted to include annotation for imagery,
not only to translate text, so people actually
can get, like, image of the scene, and last
but not least, yes, I actually wanted to create
this illusion that there is this inner voice
that you have when you have read something,
and that is what it actually reading to you.
I think it would be really cool to have it
all generated to have proper voice acting,
but for this first version of this application,
I really wanted just to have an approach to
make it as easily and accessible as possible,
and a screenreader approach seemed perfect
for me.
This storytelling that a is screenreader-driven
I realised was straightforward to implement
once I took advantage of HTML and the powers
of area.
In my application, for example, I have these
single frames that you can see here on the
left side.
Here, for example, be you can see like a person
on a boat.
They're, like, on the sea, and you can also
see is a speech bubble saying "no" and just
like a sound word saying "splash".
Each of these images can be contained in several
layers of images, so I can have an a background
image, a foreground image, and all kinds of
other text bubbles as well that I embedded
in the single frame, and I knew that to actually
make the whole scene be narrated as I would
see it as the reader, I wanted to have one
single description of it.
I wanted to have one single tag, or one single
labour for the screenreader to actually read.
I decided to make use of art attributes, or
area labels, and this case, and, more specifically
in this case, with the area label, and the
image roll, in my application to actually
make sure that everything that is told in
this image, it's also available for the screenreader
users.
There is also a word of caution, though: you
can use area labels when you want, if it is
necessary, if you realise that it really eases
your development effort, but using area all
over your place in your application, over
the use of using semantic HTML can also be
hard for screenreaders to actually read, and
therefore they should only be used sparingly.
What you can also do if you know you have
one single image, just use the alt attribute
of the image tag, and then you actually are
on the best way to actually implement this,
because browsers are actually built in a way
to support this straightforwardly with very
good support.
And 1&1 interesting thing I found with building
this web comic is realising how powerful it
is to embed not only an image but HTML, but
once I do so, it becomes the screenreaders,
and it's available just by default.
Don't have to do anything but it's already
there in my narrative.
I will show you how I like to test this later
on in my application to see what is actually
happening.
I like to use this specific screenreader called
Chrome Box.
It's like a free screenreader plugin you can
plug in Chrome, and in Mac Voiceover, and
Windows user - it's a popular screenreader
in the blind community.
I think any screenreader you get started with
is great for accessibility testing.
Let's see how it goes.
So, this is still a little bit quiet, I think.
Maybe let's try just how it goes.
Can you already hear something?
Here on the stage, it's a bit hard to tell.
Now we're we're on the website.
I have this frame embedded.
"Click here to maintain ...". With the screenreader,
it can navigate the page and skip from each
interactive element to the next interactive
element on the page.
Also, yes, described by the screenreader,
and, most importantly, each single frame can
actually be interacted with as well, and it
can actually be read.
"There is a person in a thick jacket sitting
on the boat in a dark and stormy sea."
Image.
I'm not a recognised book author yet, but
I'm getting there.
"The boat is rocking apply while the waves
splash against it.
Image "Swoosh.
Splash."
[Applause].
The person in the boat is sitting on it motionless.
Image.."
every element can be read to you by the screenreader.
Also, the text bubbles that might accrue.
"Their face still unrecognisable in the darkened
half hood of the cover of their jacket.
Which way?"
I found this impressive.
This comes out of the box.
Yes, I don't have to do too much effort.
HTML is already on my side.
This is is really great.
Let's just like it in.
[Applause].
Thank you.
Something I find super striking every time
I go on to Reddit or see demonstrations of
blind users showing how they interact with
the web is that the zoom feature is so - yes,
so obligatory for an experience on the web
for them.
Being able to not only on your desktop but
also on your hand held device, to go in and
tap in and zoom in with your two fingers is
essential.
What you might have seen in some of the applications
that you've wrote, yes, I'm guilty of this
myself, is something like that.
So this actually sets the maximum scale of
the whole screen to one, meaning you cannot
zoom any more, and this is something I sometimes
implement because there a user request that
every time I tap into an input field, suddenly,
the whole page zooms and I can't do anything
any more.
You add this, and the issue is fixed.
It also introduces a major bug for anyone
who has a visual impairment and can barely
see what is on the screen, so things are too
small, or the images are a little bit too
blurry, had too low contrast.
What is so essential for preserving this capability
is being able to zoom and not provide the
maximum scale.
I find it important to note out to actually
pay attention to making this possible.
Font sizes should be legible.
Use 60 pixel or larger and you're good to
go.
Having a rich contrast, having like favourably
dark colour on a light background is also
preliminary for a great user experience for
anyone who is visually impaired.
In my comic book, I was thinking it would
be cool to have fancy animations.
I wanted nice eye candy for anyone who is
sighted and wanted to enjoy the experience.
So, I was thinking, okay, like anything I
have to take care of.
And in this instance, I actually remembered
one very specific incident called the Pokémon
shock incident.
This actually occurred, maybe some of you
too young to still know this, but it's happened
around, like, 20 years ago in 1997 in December
in Japan, where suddenly, at like a certain
time of December 17th, almost 700 children
were admitted to the local hospitals, and
everyone was surprised.
It is, "What was going on?"
It was happening all over the country.
The kids had symptoms like nausea, dizziness,
some even had seizures.
Later on, it actually occurred to everyone
that just recently, a new episode of Pokémon
has been aired on TV.
It seemed there was a correlation.
The episode got taken down.
The agency broadcasting the episode went on
an investigation to find out what is going
on.
They actually came to the view that this one
specific scene might have been the cause of
this very adverse effects in so many children
all over the country who watched the episode.
So, in the episode, I won't show the scene,
obviously, because it's not safe, but in the
episode, there's one particular scene where
you can see two different specific frames.
I'm showing the frames, which is totally fine.
First of all, the creators of the episode
showed a very bright red frame right next
to a very bright blue frame in high frequency
interchangeably for around six seconds.
So, this created a very strobe-like effect,
and in people who have photo sensitive epilepsy
or those who are prone to seizures caused
by strobe-like effects, this can have adverse
health effects, and this is something that
really taught me that it's so important to
also watch out for this, and, in regards to
strobe effects, I also realised that so many
people are actually out there who don't even
know they have the condition because they're
ever exposed to any kind of lighting like
that.
The only safe measure that you can take for
making sure that no-one gets harmed is not
to use any of these kinds of strobe-light
effects at all.
This is when I realised that this is what
I wanted to take care of, and, last but not
least, make sure that animations are not autoplay
by default but can also be set this way.
There are many other things that I as a developer
can actually reassess before I can say, this
web application is really now accessible.
It's key part of accessibility to actually
make place for screenreaders or users who
own interact with the keyboard to go through
the application, but colour contrast, semantic
HTML, are so critical - correct heading RHD
to allow people who are not sighted to navigate
the page and actually explore it in a very
natural way, and also landmarks are one of
these things.
One other aspect I want to go into to is page
navigation route changes.
Many of us are building these single-page
applications or JavaScript applications that
have their very custom routing solution where
a lot of things we don't get out of the box
that we might have had with a server-rendered
app, and, in my application, this was also
the case.
If, like a user, for example, just navigated
to another page, for example, to a new chapter,
they wouldn't get any feedback on the screenreader.
Instead, they might further explore with a
screenreader what is going on in the page
but go like, "I think I changed the page,"
but not really sure what actually happened.
I actually found that, in the ecosystem that
I work in, there is an add-on, like a plugin
that I can snore in my application called
document title that helps me update the document
title of an application every time the route
changes.
This is a pre-requirement for the other solution
I wanted to also have in my application which
is called "accessibility announcer" which
is a simple component I can drop into my route
application template, and this will then keep
track of changes of the document title, will
observe this, and every time it does change,
it will make sure that screenreaders pick
up on the change, and can actually feed that
back to the user.
This is now Amber-specific, but I'm very confident
that, in whatever ecosystem you are building
an application - or be it like a vanilla JavaScript
application, there's already a straightforward
community solution for you there that you
can also as easily install, and if there is
not, I can also highly encourage you to start
building one and maybe ask the comment that
you're building in it for help.
Interestingly, just like getting into the
details of how to make that app accessible,
I also want to learn more about how in general
we actually make apps accessible.
In her very informative talk called Don't
Break the Web Melanie Sumner goes into detail
how the app is not accessible to some audiences
and what we can do to make it better.
I think the most striking number, or the most
striking summary I took away from the talk
are the following numbers.
There's been this kind of survey like this
investigation of the web AEM who actually
explored the accessibility of one million
home pages, and, more specifically, of the
one million most popular websites and their
home pages, thinking that it is the very first
page anyone sees.
It's probably the page where you put most
effort into that everyone can actually exit
from and further navigate from it, and looking
at the popular ones to have an estimate of,
okay, this is like how people usually experience
the web, because these are the most popular
websites everyone visits.
If you now look at this pie chart, you can
see there is this one number, which is a large
97.89 per cent and the other one is around
two per cent.
And looking at accessibility, the one to I
understood - they want to find out, like,
how many of these web pages are actually functional?
Don't have any accessibility errors?
It would be so great if you could say, most
of them actually are accessible.
Most are functional, like the most popular
websites, probably put so much effort into
making it functionable for screenreaders and
other kinds of assistive technology, but the
truth today still is that these two 2.2 per
cent that we saw on the chart are the ones
that actually work according to the accessibility
guidelines, and the other striking amount
of 98 per cent of sites accessibility-wise
are broken.
What does it mean broken?
Mostly, a colour-contrast issue, so someone
who is visually impaired can't read the text
properly or explore the elements on the first
page of the website.
It has a lot to do with images that actually
are informative but don't have an alt attribute
next to it, and also broken links, or empty
link tags that, for example, have opened up
a model but actually don't lead Anne anywhere.
As a screenreader user, you might want to
navigate to a link like that but once you
hit it, you realise I'm not sure, not getting
back from the screenreader.
So what is going on?
And honestly, it's some kind of work, and
we have to do something to actually improve
the situation.
There are things like we can install in our
test suite to make it possible to actually
automate the process of testing our applications
for accessibility, but also other tools can
help us to get a better feeling for it.
But most importantly, I think, we actually
have to practise empathy and get a better
understanding about what the experience for
other people who are not as sighted as us,
or not as, like, motor-skilled as us, actually
experience the web.
Therefore, I would like to encourage you to
actually get a screenreader running, and actually
do a real manual accessibility testing, because
this is how I see it.
Like, if you had had like a CSS-style bark
on your website, saying this is happening
in Firefox, you would say, wow.
I'm going to reproduce it this Firefox.
I'm going to check manually in Firefox as
well if it actually works to make sure that
it is functional again.
I think a similar thing might apply to accessibility
testing.
Getting a screenreader, reproducing what the
page actually does, and then, most importantly,
if you're a sighted programmer, unplug your
screen.
See what is happening, how you can actually
experience websites, see if elements are missing
or gone or you can't find them any more.
See if you're confused about the content they
want to explore is, and then figure out what
can it actually do to improve the situation?
In the end, I believe it's really about trying
to create great things on the web, and this
doesn't only include comics, this doesn't
only include art, this includes so many other
great things that you already build on the
web, and I believe it would be such a great
promise in the future if you can make it accessible
to literally everyone.
With that said, thank you so much.
I would also give a special thank you to Guy
from Comics of Power who helped me with reviewing
my web application just for free, which is
great, and all these great other inspiring
people who speak on accessibility.
If you're interested in the topic, follow
any of them.
I can assure you, you will learn so much.
With that again, thank you so much.
[Cheering and applause].
