>> 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].