This content originally appeared on 24 Accessibility and was authored by Sarah Higley
Zoey loves browsing the Internet. They enjoy getting lost in the interconnected web full of information, unraveling pieces of knowledge that are bookmark worthy. But they don’t enjoy skimming through large bodies of text. They prefer pictures. A lot of them. They go through their crush’s photos on Facebook before they even consider reading their bio. Their yearning for memes and visualizations is unparalleled to anyone on this planet and their Instagram stories reflect that. They are just, you know, heavily connected to their visual-learner nature. And there’s nothing wrong with that.
But the world doesn’t just have Zoey in it. There’s Trung-Anh, there’s Sewon, there’s Nayon, there’s Venkatesh, there’s Zeqiu, there’s Dinko, there’s Sade, there’s Ivan, and there’s Mohammed. As per the WHO, at least about 29% (2.2 billion) of the world population (7.7 billion) has some form of visual impairment, which is at least 3 people in the above-mentioned list. Hmm, so, umm … now that we know that 29% of the population might not be able to see visual content, what do we do? Do we still stand by the literal interpretation of Fred Barnard’s quote “A picture is worth a thousand words“? I dare say I don’t. Not always.
An often curious question to ask is – how do people with vision impairment use a computer? First, I think it’s important to understand that having a vision impairment is not a synonym for being blind. So, if you see someone using a white cane, it’d be wrong to assume that they are completely blind. When it comes to using a computer, depending on their level of vision, they might use screen readers to read the content on their screen. Some popular screen readers include JAWS, NVDA (free and open-source), and VoiceOver (built-in into Apple’s devices).
The State of the World
Great! So, we have a way for screen reader users to interact with their computers or mobile devices. But how can a screen reader read their crush’s photos? Or memes? Or graphs/visualizations? One possible response here is that we should make medical advancements to cure their sight or anything along the lines of them having a personal care attendant/friend/family who can explain to them what’s on the screen. Another possible response involves building a world where it’s possible for them to do it themselves. If your response was closer to the former, then you clearly need to educate and familiarize yourself with the concepts of the social model of disability.
Images
Let’s set our focus on the images. For the screen reader to be able to read out an image, it needs to know what the image is about and then present it to the user in a meaningful manner. For example, let’s consider an image of a family playing with their twin Huskies (Go Huskies!). As a non-screen-reader user, it’s easy to figure out what’s going on in the picture – not only what’s happening in the foreground but also the background. For example, Jialin, one of the family members is wearing a T-shirt that says “100% human”. Can the screen reader wholly extract the scene? To do this, the screen readers rely on the developers or content authors to supply an alternative text for the images using the “alt” attribute, which was introduced to the public in 1995 as part of HTML 2.0 (if you’re unfamiliar with what an alt attribute is or what significance it holds, this article provides a great overview of the alt attribute). The HTML img element then looks like:
<img src="image1.jpg" alt="This is an image of two Huskies" />Hence, the screen reader will now read “Image, This is an image of two Huskies”.
Leaving the alt attribute empty or supplying meaningless text such as “Image 1”, as you can imagine, is not very helpful. Even with the alternative text of “This is an image of two Huskies”, the information being relayed is nowhere close to what someone not using a screen reader would be able to extract, such as the text on Jialin’s T-shirt. Additionally, the screen reader already announces the content as an “image” or “graphic”, which makes “This is an image” redundant text. All of this is with the assumption that the image is posted by a user who has access to the code to enter the alternative text.
But what about places like social media platforms where the images are uploaded by users who do not have access to the code at all. Facebook, in 2016, more than a decade after its launch, began to employ artificial intelligence to add automatically generated alternative text to images, and allowed users to edit this text, if need be. Instagram followed and implemented this feature last year, 8 years after its launch. The questions, however, remain the same – How much information should an alternative text provide? Is a basic, higher-level description enough? In deciding what to present to the screen reader users, are we assuming and generalizing what the screen reader users are looking for in the image? If a picture is worth a thousand words, then, metaphorically, shouldn’t an alternative text be a thousand words?
GIFs and Animated Images
Leo has a strong meme game and is an expert in finding a cat GIF for any occasion. Given that a GIF is created by combining several different images in a way that the final result gives an impression of a very short video, do we face the same issues as we face with the images? Worse. As a developer, you can certainly (and should) add an alternative text similar to the way we do for images (GIF is an image file, after all). But on social media platforms, depending on how a GIF is processed by the platform, it is either rendered using an img element without an alt attribute, or using a video element. A video element does not support the alt attribute at all.
So, all those GIF widgets that we’ve been using to post animated memes on Facebook and Instagram, the ones that make us cool and everything, are inaccessible for screen reader users. Here our goal is not to stop Leo from posting GIFs (because, meow) but to ensure that such content is enjoyed by everyone and not just a subset of the population.
Graphs and Visualizations
All that and we haven’t even gotten to the “hard stuff” yet. Introducing graphs and interactive visualizations. Yisu and Xuhai are total visualizations nerds and much like any researcher, believe that graphs and visualizations are extremely valuable; there’s rarely an academic paper without at least one graph or visualization. A graph conveys highly visual knowledge and is usually embedded in a web page using one of three main techniques:
- as an image for static content.
- as an HTML
canvaselement or SVG charts (upgrade from an image on various aspects) for static content. - and/or as an interactive visualization using JavaScript libraries (that usually employ HTML
canvasor SVG as an underlying mechanism) to serve dynamic content and to allow users to interact with the graph.
When used as an image, the same considerations apply as we have discussed above with the added complexity of presenting scientific information. What should the alternative text say? Should it give an overview of the graph? Should it include statistics such as average, mean, median, mode, etc.? And if so, which ones? How much information is too little and how much is too much? These are hard questions.
An HTML’s canvas itself is exposed as a bitmap, and without the implementation of proper fallback content poses several accessibility challenges. However, there are several techniques to make them accessible and are only a Google search away. But of course, the developers are responsible for knowing those techniques and implementing them into their work – something I have seen improve over time but wouldn’t hold my breath on. On the contrary, SVG is encouraged for accessible charts as according to W3C specifications, the child elements are available to the Accessibility API. However, the browser support is still being worked on and a fully accessible SVG graph requires effort and at least some fundamental knowledge of SVG, which yet again, is a responsibility that falls on the shoulders of developers.
To address some of these concerns, I created evoGraphs – a jQuery plugin to create accessible graphs, which won the Delegate’s Award for the Accessibility Challenge at the W4A Conference in 2015. Admittedly, it does not address all of the highlighted questions regarding the complexity of presenting scientific information. Hence, accessible graphs are an active area of exploration for me and other researchers.
As an interactive visualization (such as ChartJS, Google Charts, and D3), the representation of dynamically updated information is tricky. Most screen reader users don’t use a pointing device (such as Mouse, Trackpad, etc.) and most interactions are either solely limited to or are more practically usable when a hover over certain elements is triggered. Without such interactions, the purpose of the interactive visualizations for a screen reader user becomes nebulous and arguably, without proper consideration, the content comprehension can become more perplexing.
Additionally, many modern graphing libraries allow for dynamic content modification. Relaying the information to the screen readers, when the content is modified, can be handled by properly using ARIA attributes, which became a W3C recommendation in 2014 and is honestly a godsend. But, as with SVGs, stable browser support for all ARIA features is still a work in progress, especially when used within SVGs. Proper developer training is still needed to fully utilize what ARIA has to offer.
The Path Forward
From when Tim Berners-Lee created the World Wide Web, to today, the technology has drastically increased. Unfortunately, the same can’t be said about the accessibility of such technologies. By the time a particular technology is made accessible to people with disabilities, the world has already moved on to more advanced technologies. So, the catch-up game never ends. And it won’t – unless accessibility becomes the fundamental consideration in the development of newer technologies.
But not all hope is lost. We have and continue to make great strides in the domain of web accessibility, both in academic research as well as industrial products. Students and new developers are being taught the concepts of accessibility and techniques to make the web more accessible. Moving forward, I envision taking a step back and thinking about adapting the software per user needs as opposed to expecting the users to adapt to the software. For example, do we keep assuming what information a screen reader user would want to extract from an image or do we build tools that learn more about the user and present information that the user prefers to apprehend? To me, the future moves us away from generalization and closer to personalization – a World Wide Web that is truly user-centric.
References
- “Vision Impairment and Blindness.” World Health Organization, World Health Organization, https://www.who.int/news-room/fact-sheets/detail/blindness-and-visual-impairment. Accessed 20 Oct. 2019.
- “A Picture’s Worth: D. H. Hepting, Ph.D.” A Picture’s Worth | D. H. Hepting, Ph.D., http://www2.cs.uregina.ca/~hepting/projects/pictures-worth.
- HTML 2.0 Materials, https://www.w3.org/MarkUp/html-spec.
- Sharif, Ather, and Babak Forouraghi. “evoGraphs—A jQuery plugin to create web-accessible graphs.” 2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC). IEEE, 2018.
- “WAI-ARIA Overview.” Web Accessibility Initiative (WAI), https://www.w3.org/WAI/standards-guidelines/aria.
The post A Picture Says a Thousand Words, But Not Really appeared first on 24 Accessibility.
This content originally appeared on 24 Accessibility and was authored by Sarah Higley
Sarah Higley | Sciencx (2019-12-06T00:41:46+00:00) A Picture Says a Thousand Words, But Not Really. Retrieved from https://www.scien.cx/2019/12/06/a-picture-says-a-thousand-words-but-not-really/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.