Jessica Jordan

Transcript

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