Your CMS is an accessibility assistant!

Transcript

[Intro music]

>>ROBOTIC VOICE: Welcome to Technica11y!

>>MICHAEL BECK: Hi ladies and gentlemen and all variations there upon, welcome to this — what month is it? It’s July [Laughs] — July 2021 webisode of technica11y! Thank you for joining us.

Today we have Hidde DeVries, who is a Web Accessibility Specialist and a Web Developer at the W3C and the Web Accessibility Initiative. He worked on accessibility authoring tools. Hello Hidde, welcome.

>>HIDDE DEVRIES: Hi, hello!

>>MICHAEL BECK: Great to have you with us today! Hidde will be talking about how your CMS is your accessibility assistant. Whenever content designer creates content, the CMS could help with the accessibility of it. For instance, the obvious one, the designer drops in an image, this CMS could point to the text alternative or calculate the consequences of color contrast but I’ll let Hidde talk more about that.

As usual, we’ll be doing moderated questions afterwards. And if once that’s completed, if anyone has any more questions, anything accessibility related, we can go ahead and throw that out to the consortium we have here. And so without further ado, it’s all yours Hidde.

>>HIDDE DEVRIES: Thanks, Michael. Thanks so much. Yeah, so as Michael said, I will be talking about how CMS’s can be an accessibility assistance. So I’m Hidde, I am presenting from Rotterdam in the Netherlands. And I work as an Accessibility Specialist at the W3C, which means that I spend most of my time on, on accessibility. This doesn’t make me an expert, per se, but I do spend time on it. And I worked on the Web Accessibility Initiative, which is a part of the W3C that promotes web accessibility in many different ways. I should say we have a website where we write about all sorts of things related to accessibility. You can read more about planning, designing, developing, testing, advocating and training accessibility. So there’s a lot of variety there, which me my colleagues work on lots of interesting stuff to find. So yeah, I did want to want to mention that’s w3.org/WAI. So that’s a way.

But today, we are here to talk about authoring tools. And for those who are not familiar with the word, authoring tools, means tools that create web content. So they are tools that you can use to generate anything that goes on to the web that will get its own URL, or that will be kind of presented in a browser or in something browser like. And authoring tools, because they are the tools that create web content, if we’re interested in accessible web content, we should know that the authoring tools are also tools that can improve a lot of accessibility at once because they are the thing that you create the content in. So there’s lots of opportunity there to improve accessibility.

Now, it would be good I think, to give you some examples of what authoring tools are. Obviously, CMS’s are our authoring tools but also WYSIWYG editors that you can use to create content while seeing what you’re doing. So it’s What You See Is What You Get (WYSIWYG) editors. Authoring tools also include, course creators or learning management systems. So if you work in higher education, in a university, there’s lots of authoring going on there. Like you might be presenting some exam to your students, you may be giving them access to the latest marks or something like that. That will happens through web interfaces. That is web content and it is created in early management systems. Of course, I mentioned CMS’s Wikis are another example. Save as HTML interfaces that you can have in things like Word. Social media, if you’re creating a tweet, you are creating web content. Form generators are a big one. Lots of accessibility problems exist in forms. So there’s a lot to win if the creator helps you do that properly.

And then site builders are another category and they are increasingly popular, especially site builders that help you create web pages without writing any code. They call those, “no code,” as well, which, you know, is a bit of a misnomer because obviously there’s code behind it and as an accessibility person, I’m interested in ensuring that that code that is there is good and is accessible and takes accessibility into account.

Now, specifically for CMS’s there’s a lot you can think about. There’s the CMS itself, of course, but it’s also, this whole ecosystem that’s usually around CMS’s, like plugins for them. Think about things like form builders, field managers, cookie, banner thingies, stuff, where you manage events, social buttons, web shops, all of that. There are plugins for that for most CMS’s and those plugins also have an accessibility angle. And of course, then there’s themes too. If the CMS provides a number of themes or if it provides capabilities, where third parties can create their own themes. Again, if you’re downloading a theme, you should be downloading the accessible theme. So all of this has accessibility angles.

>>HIDDE DEVRIES: Why don’t we want that? Well, of course, the web is for everyone. That’s the promise of the web. This is for everyone. And that is definitely something that way, that we believe and that we try to address to a number of different web standards.

The first one I want to talk about is WCAG. It’s the one that you’re probably familiar with if you’re in the accessibility field. So WCAG stands for Web Content Accessibility Guidelines and it is the set of guidelines, it’s a standard that many governments use when they mandate any kind of accessibility thing. So many governments around the world will say, “Here’s WCAG, and that’s how you should be doing accessibility.” So WCAG is, is a great way to measure accessibility and to look at how accessible a given website is. It helps governments prepare, or compare as well, between different websites as well. So if there’s 10 departments that all have a website, and therefore generate the report based on WCAG, then you can use that report and compare somewhat, what the level of accessibility is. It’s not perfect, it’s not gonna cover everything, it is a minimum that you can use. But you know, generally it is what people use to measure web content.

But besides web content, there’s a whole lot more that we can measure. And if we want an accessible web, it is also important that the tools we use to look at our content are also accessible. That’s where browsers come in, browsers also need to be accessible. If someone with disabilities wants to use their computer to go to a website, then the tool that they use, the browser, will also need to be accessible, and UAAG is a standard that addresses that. So it stands for User Agent Accessibility Guidelines. And a lot of it is implemented in many browsers, some of it is not. And UAAG is specifically for that. So making sure that the software that displays web content is accessible, just like the content itself.

And then there’s ATAG, which is about authoring tools. It’s the Authoring Tools Accessibility Guidelines. Again, we like that abbreviation AG for guidelines, and the Authoring Tools Accessibility Guidelines are what we’ll be talking about today. They are about those tools that create web content, and they’re essential. They’re essential for realizing that vision of that, you know, the web is for everyone. Authoring tools are essential besides the content and browsers because with accessible authoring tools and with tools that really embed accessibility, we’re able to include more content creators, so more people will be able to create content for the web. That’s important. We want to hear all voices on the web. And also, content creators can get some help with the right authoring tools to fix accessibility problems before their website goes live. That’s really interesting. We’ll be talking about that a bit more later on. But the gist of it is that all authoring tools sit in kind of the early stages of the development of web sites before you ship the website you’ve created, you author it. So if we’re able to fix accessibility problems during authoring, that’s nice and early. We can do that before the website goes live rather than after it’s gone live. That’s a good opportunity. Yeah, we’ll be talking about that in more detail soon.

So the latest generation of the ATAG Center is ATAG 2.0. It’s a couple of years old. But it’s the latest we’ve got. There’s a document online called, “ATAG at a Glance.” By the way, links for this presentation will be available later on. I’m sure the Technica11y folks will be able to share that later on. But I have this web page where I collect all my presentations and links will be available there for you to find. So there’s this page called “ATAG at a Glance,” that will give you an overview of ATAG or you can stay for this presentation and I’ll be giving you a bit of an overview as well.

So there’s two parts to ATAG, which address two different parts of the web. One is the editing experience. So that’s Part A of ATAG, and it’s all about whether people with disabilities are able to edit the website to create web content. So it is about ensuring that the CMS itself or the learning management system, or any of these systems are accessible for people with disabilities. Then the second file for B is about the output of those systems. It is about the end user. So where part A is about the user of the CMS, Part B is about the end user that’s going to use whatever the CMS produces. And you can think of that as the HTML that is being outputted and trying to make sure that HTML is, is accessible.

>>HIDDE DEVRIES: So let’s talk a bit about Part A of ATAG, the accessibility of the editing experience. This may affect people like Antonio who is 52, and a doctor and colorblind. He wants to set up a recurring prescription for one of his patients, and he may be using this medical system that, in fact creates a web page that this patient is going to see. But you know, it is an authoring tool in that sense. And he wants to make sure that, we want to make sure that he can be setting up that prescription, even though it’s been applied.

Ellis who is 27, and an HR Specialist has broken her arm. It’s technically not a disability, but it is a temporary impairment to her at least. She wants to publish a story about one of her colleagues promotions on the company intranet.

Or Mei, who is a teacher, 32, reduce dexterity, she wants to upload a take home exam for students.

Or Anne, who is 21, an influencer and motor impaired, wants to publish her latest vlog on social media.

So all of these people have in common that they want to publish stuff on the web, on a web platform on some internal system, sometimes on an external system somewhere on the web, and they want to create that web content. They want to make sure that it works with their environment. We want to make sure it does.

So a couple of things that ATAG recommends that I’ll be kind of paraphrasing ATAG, these are not literal quotes from ATAG but these are things that, in the spirit of ATAG, authoring tools can do to make sure they work for people with disabilities.

One is that they test with text zoom. That’s something you might know from WCAG, if you’re testing WCAG, you will be doing this with regular web pages. But it’s just as important in admin interfaces of CMS’s because when you zoom, you want to make sure that none of the text overlaps, so that the content is readable, that’s visible on the page.

You want to make sure that there are alternatives for all of the icons. There are some CMS’s that have menu bars that are mostly consisting of icons. And we want to make sure that those icons have tax authorities so that people with disabilities are able to use them. We also want to make sure that they work with keyboards. It’s quite a common issue amongst CMS’s that that I looked at for this project, that icons in the menu or generally buttons and controls throughout the interface are not available for the keyboard. So you’re using your keyboard to look and see maybe I want to go to my admin panel, and you’re not able to get there with the keyboard. So making it work with keyboard has two parts to it, you want to make sure there’s visible focus so that you can see where you are and also that you can use the controls. So that you can press buttons, activate them, open menus and those sorts of things.

So menu authoring tools don’t allow for doing that. So before you purchase an authoring tool or decide to use one, make sure that it does work with keyboard. Also make sure that previews are displayed excessively. Because many CMS’s will give you a preview of the content you’ve just created. For instance, on GitHub you can write the markdown file and then you can press preview changes, it’s going to give you a preview of that content. You want to make sure that preview is accessible as well. There are some authoring tools that, that fail at this and have previews that are not available or kind of inaccessible in some way to the end user and that’s not great.

And the last thing that authoring tools could do to make sure they’re accessible to people with disabilities, is to help with spelling, so that people with disabilities like dyslexia are able to write content that doesn’t contain spelling mistakes so they can get some help with that and help with spelling exists in the first place and also that the spelling help is available to use with visibility. So if there is a way to mark words that are spelled wrong, like in this screenshot, it says “auttoring,” it’s spelled wrong and there’s a red line just underneath that, that indication of you know, this word is wrong, that that’s also available to users with disabilities in some way.

>>HIDDE DEVRIES: Then Part B of ATAG is about the CMS ensuring that the content that’s being produced is also accessible. So the CMS helping to produce accessible content. And there’s a lot to accessible content, right? We want to make sure that tables have headers, that form fields have labels, that hero images have enough contrast with the text that is positioned on top of them. That videos are captioned, that content with multiple languages has lang attributes, that words or tags are nested according to specification, that carousels can pause and that there are sensible heading structures.

So lots of different things that are all things that we mean when we talk about accessible content. All of these things are, are important. And all of these things are stuff that a CMS could potentially help with, give suggestion about, maybe try and help avoid these problems. So if you want to avoid that, you want to avoid tables that don’t have headers, you want to avoid nameless form fields, illegible text, no captions on videos, multilingual content that don’t have lang attributes, non standard nesting carousels that don’t have false buttons and also heading for the wrong reasons.

There are CMS’s that address some of these problems, right? They will warn you, if you’ve created a field that doesn’t have a name. There are authoring tools that will say well, “wait a minute, this is not nested properly.” So that can be done. And some of these can be recognized automatically, and an authoring tool could, in other words, help the content editor avoid this inaccessibility.

Good CMS’s can help content editors to make their content more accessible. And that is relevant to a lot of people like Alita who’s 26, a privacy lawyer. She’s blind and she wants to arrange this lunch for one of her clients to take them out for lunch and wants to find out if the restaurant serves vegan food. Or Rick, who is an investor with severe hearing loss, wants to watch this interview with the Prime Minister on TV because maybe they’ve just announced some new rules around COVID or released some of them, as is the case in some parts of the world now. Xiao, who is 15, a student with low vision, wants to just access the results for their mathematics test. Or Erica is 31 nd a photographer with RSI wants to file a tax return online. So these are all kinds of things that these people want to be doing. All of these personas want to do things that are part of their life and they don’t want to have barriers when they when they try to do those things.

So far, the beauty of ATAG is really about kind of trying to avoid these barriers for these people. Wanting to ensure that this stuff just works. So one thing that a CMS could do is generate accessible content. So when there’s a table generator, that it generates accessible tables with the right headers, that avoids empty links. So when you’re creating a link, and don’t put any content in it, or put an image in it without alternative text, that the system warns and says, “Wait a minute, you need to provide a name.” In fact, when content is generated, you could prompt for required accessibility information. So if someone inserts a table, you could say, “Well, wait a minute, what’s this table called?” Or when there’s an image, it could say, “You need to put alternative text there,” or indicate that it doesn’t need alternative text. Or when there’s a form field that it asks you for a label.

You could also, CMS could also ask for, do some automated accessibility checks for you. So that you can avoid problems there. Only a small part of accessibility problems can be found automatically. But as someone who does audits sometimes, I know that a lot of problems that auditors find are actually things that could be found by automated tools. So these are all things we could avoid in the authoring process.

When content is generated, you could also do some manual checks. And the CMS could help you do that. It could say, you know, “Before you want to save this page, are you sure this heading structure is okay?” Some CMS’s will display a list of headings, right next to a field of content so that you can glance over that and make sure it’s good. Or if it allows you to manage image alternatives and some kind of media library, you could also do a quick check and say, “Does an alternative apply in this use case?” Does it make sense in this page, because sometimes it doesn’t.

>>HIDDE DEVRIES: A CMS also allows for creating accessible content. So some CMS’s don’t allow you to add alternative text or images or captions to videos. Social media used to be known for that. And in some social media, it’s still quite hard to add alternative text to images. So you know, to think an ATAG that is a, you know, the authoring tool should allow in the first place to create that accessible content. There should be fields for our text.

And that’s also important when you’re customizing a CMS and you’re creating some custom fields that do something very specific. If that includes an image that should also include the alternative text field for that image. And that’s something that people commonly forget when they build their own kind of components. If you allow for images, you should also allow for alternative text. If you allow templates, or there’s some kind of gallery for accessible templates, then it’s helpful if those templates are accessible, or if there’s a way to find the templates that are accessible or have accessibility built in. For us, fine that is possible. If you provide UI components, like some way to add a carousel, if you really must, or tabs for that matter, ensure that they are accessible, that makes a big difference. If a CMS comes with a tabs component, it is probably not going to be used in one place. If your CMS has more than one customer, you are going to make more than one website accessible with that effort. So that is extremely helpful. In the specification, this is called pre-authored content. I like to call it UI components. But basically anything that you can repeat, like tabs or like a carousel is something where you can make a big difference. If you ensure that it is accessible. If you decide to test it with users with disabilities, that can make a big difference because that is going to be repeated over and over. And that way, you can ensure that you’re repeating accessibility rather than repeating inaccessibility. So that’s helpful.

Something else that the CMS could do quite well is warn users when they introduce a color contrast issue. So for instance, I have this image of a black cat with some white text on top of it. And it has plenty of contrast, because the photo is quite dark the cat is quite dark, and the text is quite light. So I have good contrast there. But if the CMS allows me to replace this image, and someone replaces it with a perfectly fine photo of Korean food, that happens to be quite light, then it could warn and say, you know, “At this point, when you’ve just replaced this image, you no longer have enough contrast. So maybe you should try a background color on the text or a larger text or bolder font.” Automated tools could figure out what to do here and make suggestions to the end user. Or even have a button where as an end user, you can say, “Yes, please do add a backplate to this text, please add a black background to this text or something like that.”

Spell checkers are also helpful on on the B side of ATAG. If you add a spell checker to content fields, you can avoid things to go unnoticed like when I have a submit button that has a W instead of a U, maybe when I look at it visually, I didn’t notice that because a W looks so much like a U, but someone with voice control technology or maybe you’re screenreader might make them super confused if that’s the name of the button. So you want to make sure that you know you remove spelling mistakes from your content.

Readability is another huge thing in accessibility, you want to make sure that content is readable. Plugins could provide readability levels so whenever you add any content, that it is checked for readability, so that publishing hard to read content, is a little bit harder.

>>HIDDE DEVRIES: Something else that ATAG recommends is to have accessible examples. Such as, you know, when you have templates or documentation that you double check that all of the code examples there, have accessibility practices embedded into them.

So basically, summarizing all of that, the right CMS can encourage more accessible content and in that sense, be a personal accessibility assistant. That’s the vision I have for CMS’s. I think that can make CMS’s a lot better. If you own a CMS company, I encourage you to put it as your unique selling point, because there are a lot of websites out there who want to be accessible, legally have to be accessible, or willed to be accessible for, you know, a number of reasons. And if you can offer them a CMS that helps them achieve that accessibility, you can sell your CMS to these people, because it’s hard to find CMS’s that have all of the features I just mentioned. Many of them are in some CMS’s, but if you are the CMS that has most of them, you have a unique selling point there.

Now, let’s look a bit at when better authoring tools can help in terms of when you have an organization and you’re trying to build stuff for the web, you may have a process like this, which is a bit linear, waterfally. You start with planning new interaction design, visual design, development, quality assurance, and then you launch a product. Maybe your process looks different than it has many of those tasks kind of put together and has like a multidisciplinary team, it doesn’t really matter. Usually you will be going back and forth between different phases like maybe from launch, you will go back to planning or to interaction design, or visual design to kind of sometimes change part of your stuff that you’re working on. Sometimes you might be going back from quality assurance to visual design. So you may be making a lot of movements between these different phases. So it is important to know what you can do about accessible authoring in each of those phases. For instance, if you are in the planning or strategy phase, what you can do is choose an authoring tool that supports your accessibility. Choose an authoring tool that does many of the things that I’ve mentioned today. And if you do that, it will become easier to get your accessibility right. If you do interaction design, you could document how to author excessively like, if you have a form generator, you can document which buttons to press to make sure there’s a level that sort of thing. You can test your authoring with users with disabilities to make sure that all of that works well. If you do visual design, you can set constraints for customized color combinations for stuff like contrast, or you can provide accessible examples like large enough touch targets or those sorts of things.

If you’re in development, you can pick the themes that have accessibility support or plugins that do. If you’re selecting components, again you can look for that accessibility label. Make sure to test it thoroughly because there are more claims for accessibility and actual accessible problem products.

In quality assurance, you can work on things like embedding automated accessibility tests in the authoring process. So when someone writes new content that is actually automatically tagged as well. Basically, you can do things all the way until launch.

Now beyond ATAG, ATAG is a bunch of years old. There’s a lot of things that we can do in the spirit of ATAG that can help a lot with with web accessibility. Things that I know of is this component for react that will allow you to, and I think it’s actually done by Tenon folks behind this, this meetup. It’s a react component that will let you do headings automatically. So you have a heading component that’s generic, and then it will automatically set the right heading level for you, based on where you are at the structure, so that you can’t make mistakes, what your headings. Something else that you can do is run automated tests. As I mentioned before, they don’t cover everything, they only cover a small minority. Some say 20%. Some say 40. depends who the person is that’s telling you. But generally, automated tests will cover some part of your accessibility. And that’s helpful to get those things out of the way. You could also use accessibility style sheets that are stylesheets that will mark things in your content that are wrong, like missing alt text and that sort of thing.

If you have those style sheets, in the preview in your authoring environment, you can also warn users, like, “Oh, wait, here’s an image that doesn’t have an alt text,” or that sort of thing. Now, as I mentioned, at WAI, we think authoring tools are one of the secrets to making that more accessible to realizing that vision of this is for everyone. Just along with web content and browsers. We also need to make sure that authoring tools are in a good state. And one of the things we’ve done for that is obviously add ATAG standard and a document called, “Implementing any ATAG 2.0.” This document contains a lot of things that I have talked about today. And some practical examples. It’s a little bit like techniques and understanding that you may be familiar with for WCAG. But also more recently, because this document is from 2015. It’s many years old. More recently, we worked on a project called, “WAI Guide,” which is what I’m involved with. It’s co funded by the European Commission, who wants to make sure that the web works for everyone. And one of the things we do there is called, “Accelerate Support for Accessible Authoring.” And as part of that work, I’m giving this presentation. But I’m also working on a list of authoring tools that will allow you to filter by ATAG criteria.

So you could look for a CMS that meets certain parts of ATAG. You can find tools, basically, that support accessibility. So when you are in that procurement phase, you can actually say, I’m going to purchase a tool that’s going to help me with my accessibility better. And folks will be able to submit their own tool as well. So if you work on something that is an authoring tool, I’ve given a number of examples at the start. There are more authoring tools than people know and more things are authoring tools than people realize. So anything that creates web content, whether it’s a CMS or plugin or theme or whatever, you can submit your tool for this list. And we plan to ship that sometime this year. To really enable people who want to make decisions, purchasing decisions, to really look at whether the tools that they want to purchase have accessibility support.

Now, one thing we realized when we were building this list is that we weren’t too sure which things to include, because, obviously, we want this to be something that is objective. And the most objective thing we have is the ATAG standard. So what we’ve created two is an ATAG report tool, that will allow you to go through the ATAG standard, report on the criteria that are in there, and then save that as a JSON file, HTML file, and then put it on your website. So if you sell CMS’s or plugins, you can publish an ATAG report on your website. And this would also be able to be in kind of the input mechanism for that list of all variables that we’re working on. So if you have a tool, you can use the ATAG report tool that’s currently live. Again, I’ll be sharing links later as well. That stuff will allow you to… Yeah, the tool will allow you to create a report. And then we can display your tool into our list, as well. So we welcome submissions for that.

So concluding, the main things I would love you to take away from this is that CMS’s and other authoring tools are essential for an accessible web. If we want the web to be accessible, we’ve got to address authoring tools. And CMS’S are great at being an accessibility assistant. They can help content editors get accessibility rights. So yeah, please do spread that message. If your client is thinking about purchasing a new CMS, or if you are selling CMS’s or other tools that create web content then think about how well it meets the ATAG standard. Yeah, try to meet it as much as possible so that people with disabilities can create web content, or can access content that is created by by these authoring tools. So that’s all for, for me. I’d like to welcome questions. Now if you have any.

>>MICHAEL BECK: Yes, thank you so much Hidde. It’s actually Mike Gifford made a comment earlier that kind of hit one of the things you were talking about just at the end there. He noted that Drupal has certainly tried to promote ATAG but very few people are thinking about how the authoring tool can make a difference that people are just aren’t asking for it yet. So it really is kind of up to us to evangelize ATAG in CMS as an accessibility assistant with with people. So I think it’s a good point.

>>HIDDE DEVRIES: Yeah, totally agree with what Mike says there. It is not something that people are asking for just yet. But we can change that right especially as accessibility evangelists. We can tell our clients about this with the ATAG report tool and this list of authoring tools, we are also trying to make a small dent in that and we are hoping to get tools including Drupal all through this list and yeah, ensure that people are going to use this to find their tools that support accessibility and hopefully it will also encouraged vendors that create tools to really want to be on that list. And yeah, so we hope to create that effect their with those things.

>>MICHAEL BECK: Yeah, I certainly am thankful for the CMS we use for the Technica11y website that has all those kind of prompts for things, (it) doesn’t let me go forward if I forget to add an alt text or something. Because it’s just the name of the game, people do that sometimes. You sometimes forget or you’re in a hurry, go past it. But CMS will tell you “Stop! You need to do this first. Slow down.”

>>HIDDE DEVRIES: And I’ll say as an accessibility person, I forget it. So yeah, obviously people who don’t have that experience, they will forget it. Exactly. And that’s fine. If we can point them at it we’re making it a bit easier for them to not forget or correct that. Yeah.

>>MICHAEL BECK: All right. Does anyone else have any questions? PJ Gardner asked, Are there places to report problems with existing authoring tools that we find as we work?

>>HIDDE DEVRIES: I can give you my email address (laughs). I’m definitely interested to hear about this. I know that individual governments have places where you could report accessibility problems in general. So it may be helpful to report there. I don’t know about other governments. I know the Dutch government has nice so you can report things that your encounter here and I think across Europe, government generally have that. And there maybe place in other parts too. But if there’s a place to report problems with websites, do also report problems in authoring tools there. Because it is important that everyone knows that in authoring tools, it matters as much as everyone else.

>>MICHAEL BECK: Rian asks, “When you create a plugin to an inaccessible CMS, but do a lot to help people create accessible content with your plugin. How do you address this as an ATAG for your plugin?” – because you’re depending on inaccessible CMS.

>>HIDDE DEVRIES: Yeah, there’s this notion of partial reports where people say, “Well, this part of the website we’ve looked at, this other part we’ve not.” I think you could do the same as in WCAG reports, right? There is, I think you could apply the same principle to ATAG reports and say, “This report is just about this,” let’s say a form generator or something like that. It is not about the CMS itself. And I think that’s commonly the case in, in authoring tools that they rely on, on components that are sometimes more accessible than the tool itself, sometimes less accessible. So we’ll have to do a partial reporting on that.

>>MICHAEL BECK: Most important thing is just letting people, letting them know. Just whatever way you can let them know. Mike has another comment or question, “Commonly used tools like CKEditor have had a huge impact for authors, how do we increase the demand for a tag and essential tools?”

>>HIDDE DEVRIES: Yeah, we’re hoping that may somehow follow from having a list and kind of making people more aware of these these demands. I mean, if Drupal is going to work on the accessibility of the CMS and editors that’s built in to Drupal isn’t accessible, then Drupal folks will likely reach out to the editor folks. I don’t know if that CKEditor might probably know this, or another one. But yeah, that’s that’s hopefully what will follow if we ask CMS’s to be accessible that they also ask the tools that are used within those CMS’s like CKEditor. So yeah, please continue to put pressure. [Laughs]

>>MICHAEL BECK: Mike said, “It is CKEditor, and we’ve been trying to put pressure on them.” So yeah, keep it up. That’s basically all we can do is keep it up.

Anyone else? Have a question for Hidde? Or at this point, any accessibility question that’s bothering you. If you’re stuck on something, we have a nice little group here of people that will… we have a really nice group of people with lots of knowledge here today.

While you’re thinking… Well there your go: “Plain language isn’t presently part of a tag. Nor is it part ofWCAG 2.1 or 2.2. Any idea when we’ll see an update? Maybe ATAG 2.1?”

>>HIDDE DEVRIES: Yeah, they’re currently no plans for ATAG 2.1. There are plans for embedding some of this stuff in ATAG into the next version of WCAG, (Michael Beck squeals giddily in the background) also known as a “Silver.” So there is some thought about not only making WCAG about web content, but also about browsers and authoring tools, to kind of embed the authoring tool stuff inside of WCAG. But WCAG 3.0 is far future. It’s just being worked on. But there is some talk about that. ATAG 2.1 is less likely. And for those who don’t know, there is some mappings between ATAG 2.0. And WCAG 2.0. So sometimes ATAG will say, “Please meet this part of a WCAG, and it will say meet that part of WCAG 2.0.” So there’s a mapping between ATAG 2.0 WCAG 2.0, not to 2.1. So that that doesn’t exist, and I don’t think it’s likely it will exist in the future. Because efforts are focused more on WCAG 3 at the moment.

>>MICHAEL BECK: I think there might be actually, that’s a really good idea, because WCAG is the, the hot button term people know, if it’s already, ATAG stuff is already built in the WCAG, in some way, shape, or form. There’ll be at least aware of it and maybe look into it a little further, me.

Jules notes that she was surprised that EN301549 points to ATAG. And they just advise the client to use that for choosing their vendor. So, oh, that’s nice to know. I didn’t know that either [Chuckles].

But that specification, that conformance criteria pointed to ATAG, cool.

Mike City is going to go make sure that goes into the Wikipedia page to highlight it a bit more, which is good.

That’s good. All right. No one has any more questions. Next month, we’re going to have someone who’s in our audience today, I believe. Yep, there she is Sarah Brodwall. She will be discussing disclosure widgets, modal windows and toast notifications, those kinds of patterns that we have for showing the user more information after the page loads. She’ll talk about how to choose the best pattern for the purpose and context and how to ensure that the design and implementation provide a positive user experience. Is that correct? No, I’m sorry, Sarah, you’re not on until September [Laughs].

I’m, I’m a peeping you’re talk two months early!

Next month, we’ll actually have Jesse Hausler. That will be talking about drag and drop. That, that pesky little drag and drop and the best ways to implement it, those in an accessible way. So again, sorry about that, Sarah, you’ll get a you have a neat, neat little glimpse into the future, knowing that Sara will be presenting on September 1st. But the next one is on August 4th – Jessie Hausler talking about drag and drop. So thank you all again for showing up. Thank you Hidde, for that wonderful presentation. And we will see you all next month.

Thank you!

Hidde de Vries

About Hidde de Vries

Hidde de Vries(https://twitter.com/hdv) is an accessibility specialist and web developer at the World Wide Web Consortium (W3C) in the Web Accessibility Initiative (WAI), where he works on the accessibility of authoring tools.

When and how to use the ‘<section>’ element

Transcript

[Intro music]

>>ROBOTIC VOICE: Welcome to Technica11y!

>>MICHAEL BECK: So, ladies and gentlemen and all variations there upon, welcome to this May 2021 edition of Technica11y. For those new to our series, I’m your host Michael Beck, the Director of Operations at Tenon. Before we get to today’s guest, I do have a quick announcement, on Monday, May 17, at 11a.m. Eastern, that’s US time, we’ll be launching our new German speaking edition of Technica11y hosted by Joschi Kuphal. And the first guest will be Eric Eggert, who is a professor emeritus of Technica11y, so to speak, of at least of the English speaking version. So if you are a German speaker, keep an eye on our Twitter account @twitterapi…I’m sorry, @tenonapi for registration info. The German Technica11y will be a monthly series that will be on the third Monday of every month. And with that out of the way, let me welcome today’s guest Martin Underhill! Welcome, Martin!

>>MARTIN UNDERHILL: Thanks Michael. Thanks for having me.

>>MICHAEL BECK: Yeah, thank you for being with us today. Martin will be talking about the `<section>` element and answering the burning questions such as, “What on earth is a ‘<section>` element? How do we use it properly? In what ways is the `<section>` element different from other elements like the `<article>` or the `<main>` elements.”

If you’ve ever asked yourself this or any questions like it, today’s your day because Martin is here to explain it all!

And as always, if you have any questions for Martin, please put them in the chat and we’ll answer them after the presentation and if there’s any time after that, we’ll open the floor up to any accessibility related questions for our little brain trust that we have here right now. And so, without any further ado, the floor is all yours Martin.

>>MARTIN UNDERHILL: Thank you! Yeah, thanks very much for having me, again, Michael! It’s great to be to be on and good to see everybody on the call. Let me just jump quickly to a (brings up PowerPoint on screen share) There we go.

So, I’m Martin Underhill and I’m a principal experience designer at Sage, which is a quite large company that does accounting software role of all kinds. As well as being a designer, I’m a bit of a frontend developer and I’ve got a strong background in in things like HTML and CSS and then avoidance and other things like JavaScript, wherever I can. But yeah, so I’m that. I’ve got a background in a UK government’s digital side of things and the GDS principles and all that kind of stuff. I’ve worked for for a few years doing that so and all of the, all the prioritization they put on accessibility with government services being something that everybody has to use, so making sure that everyone is included.

So that brought me into my current role where I am an Accessibility Specialist. But I guess above and beyond all of that, I’m a dad of two children and I’m a husband to Bea, so that’s me in a very quick nutshell.

Let me dive straight in, so I should also mention at this stage, I don’t speak the Queen’s English, necessarily, so if anybody struggles with my accent please pipe up. Let me know and I’ll either rephrase the language I’m using or I’ll try and slow down a little bit. It’s easy to, to sort of take the, take the boy out of Glasgow but not necessarily to take the Glasgow out of the boy, if that makes sense.

So, HTML5 and cowpaths is where I’d like to start. So, the idea of HTML5 was that where it took over from or it superseded XHTML was that it would be paving the cowpaths. That was, a that was one of the design principles behind it, so in 2019-ish, ISH, HTML5 is starting to get a bit of traction and seeing some adoption. And the idea was to design it around, what people were already doing, so there were things like, I think there were the bots were sent out across the, across the worldwide web and they found that there was lots of commonalities across all these websites. So people were using things like a <div> with a class of header. So, from that they inferred, “Okay, header is something that’s quite useful. So why don’t we make a <header> element in HTML. So that was just one example of many. But that’s only part of the story, so that’s paving the cowpaths. But there are also some new paths that were forged. HTML5 changed and repurposed some semantics and the <AI> element and the <B> element being, being a couple of kind of prominent ones of those which are not I could, I could digress but I won’t.

It also introduced a new semantics like the <header> element that I mentioned and the <footer> was one. <main> was a bit of a late comer but that was another one that arrived. And the main thing was for me, that it raised lots of questions. It wasn’t like for like anymore. There was lots of new things to learn.

So, one of my questions was, “What on earth was a <section> element even for?” And this was a, it may not be a direct quote but this was something around the sort of, the sort of question I would have been asking around 2009 when I started to use HTML5.

So let’s start by talking about landmarks. Landmarks are things that a sighted user can identify on a page, so you have a header, you have a navigation, you have maybe a main content area, a sidebar, and a footer so that’s, this is a diagram here, a very, very rough wireframe of all those things, very sort of classic website in the desktop mode.

Here I’ve numbered those elements so number one is the header, right at the top there. Number two is navigation which is inside the header and kind of maybe off to the right hand side. Again, we’re looking at this and I can have a laptop view rather than a mobile view. And we’re concentrating on, on the, on the visual aspect of it as well as stage. Number three, we’ve got the main content area. Number four, you’ve got a sidebar, and then number five, you’ve got a footer down the bottom there, those are things that, that they found to be common across almost every website across the web.

But just as a sighted user can visually identify those landmarks, screen reader users have superpowers as well.

So what they can do is they can quickly bring up a list of all the landmarks on the page and then jump to any one of them that they choose. In the same way that the sighted user can visually identify these things and then zoom in or zone in, zone in on that one that they’re interested in. So okay, “I’m interested in the footer, because I came here to find your Twitter account. Probably it’s in the footer,” so as a sighted user I scroll down, find the footer. “Okay, there’s a footer link.” As a non sighted user, I can find that landmark that, that footer landmark and jump straight to it and have a look around, have a poke around for the Twitter link.

So, this is where things get interesting. So, those new elements that we were given in HTML5 came with implicit rules. And the idea here is that screen readers can take one of these elements and then give it a rule to communicate to a screen reader user. So, the screen reader does that. It kind of goes across the page, picks out the rule, finds a <header>, “okay this is a header.” So, it communicates that to the user. In order for them to have a look through the, the different elements on the page and these common landmarks and because it’s implicit we don’t have to see anything. We don’t have to add any attributes like, role=banner, or something like that to our, our <header> anymore just, it’s just implicitly added there.

So here’s a, here’s a very rough look at what the markup for the example page may look like. We’ve got the <body> element containing everything there and then it’s very bare bones so at the top we’ve got <header>, and inside the <header>, just like the diagram, we’ve got the <navigation>. After the <header>, we’ve got a <main> element, which, which it contains all of our, our <main> content. Then we’ve got the <aside> element, which is used for the sidebar. And then at the bottom of the <footer>. So that that structure there would be what we would use to create the page that I’ve shown you before.

So, with those we get these lovely implicit rules here. We get the <header> becomes a banner, the <navigation> is a navigation and <main> is a main. The compliment of the <aside>, or the <sidebar> is complimentary and in the <footer> is what’s known as content info to tell you about the contents of a page. And these rules allow screen reader users to identify those landmarks in the same way that a sighted user could. But there’s more, so custom landmarks become a thing. So, this is where the second element comes in. So some visually identifiable landmarks that aren’t included in HTML. I guess it could be, it could be anything really, but if you scan around the page and you can, you can lock onto something and say, “Okay, I know what that is. I’m going to, I’m going to have a look at that thing.” Some of those things may be headers, footers, but it might be more nuanced things like perhaps blog post information.

It might appear on the side of the page where the, where the sidebar would be but it’s not strictly speaking in <aside> which, I’ll get to. But yeah, blog posts information, that kind of thing. You can have a filter panel that would be what you can use a <section> for as well. Just ya know something like on an E commerce site where you can refine your search if you’ve looked for something you can say, “I want, only want to see the blue versions of this or the red versions.” That kind of thing, so yeah filter panels could be a landmark. Then calls to action are probably a good one as well, so in marketing websites you might have the call to action down at the bottom there. That would be something that you’d be able to easily visually identify. And the same way that you’d want to give that same power to non visual users and give them that that call to action, a rule using a <section> but, “A <section> is essentially a <div> from a semantic perspective.” – And that’s me quoting myself here, so this was an article that I wrote a couple of months ago, that kind of sparked this whole discussion off.

The screen reader doesn’t know anything about a <section>. So we need to tell the browser what each <section> actually is, before we can, before we can do anything with it. And what we do there is we give a <section> meaning by using ARIA to label them. So we can either use aria-label=”” or we can use aria-labelledby=”” and I’ll take you through each of those and the sort of pros and cons of each.

So if we were to use aria-label, here’s an example where we’ve got a <section> element with an aria-label attribute on the <section>, opening tag and it says, “Join the mailing list,” <section> has a header, heading sorry, which has an <h2> to “Join the mailing list.” So those two things are exactly the same. And I use an example from VoiceOver on macOS. It says, “Join the mailing list region.”

So, that’s all pretty straightforward. A screen reader user would understand that they’re in a joining, there is a join mailing list region and then they can jump straight to that. Then they get the header, which, which reinforces where they are and then they can read the details about joining the mailing list. Maybe, maybe, sign up at that point.

A call to action is, a sort of a nice, simple example of this. The problem is that it’s a bit repetitive. We’re adding the same content in two places. We may be using a templating language, something in nunchucks or, or twig or something but, but where we can input the same piece of data in two places but still there’s a bit of duplication there and we can probably do with avoiding. So, the problem is if the headings changed there’s a risk that the aria-label value is forgotten about and doesn’t change as well.

So you might end up in a situation like this, where you’ve changed your heading but you haven’t changed aria-label. So in this example, we’ve got the same, the same code, the aria-label still says, “Join the mailing list,” but we’ve updated the subscribe to the heading too, “Subscribe to our mailing list.” And now, first of all, I guess first of all the Marketing Department might not be very happy that you’ve done that. They’ve put all that work into, into that brilliant new copy that’s gonna get all those new subscribers and then you’re, you’re giving screen reader users the old experience. So, they’re not gonna be very happy with that.

There’s also the issue that you’ve got a mismatch between the landmarks label and the heading. So that can be a bit disorienting for some users. A screen reader user would expect to see a <section>, that would be reinforced by this heading or this main heading. So here, we get the same landmark in VoiceOver and if we look, if we were to look at our kind of elements in our router view it would say, “Join the mailing list region,” rather than “Subscribe to our mailing list.”

So a better way to do it is to use aria-labelby. This takes out all of the repetition that we have. So we’ve got the <section> that has an aria-labelby attribute on the opening tag this time. And that aria-labelby value matches the ID that we’ve added to our <h2>. So, the <h2> says, “Join the mailing list.” And if we reference that, that means that wherever, wherever we update the heading to, it’ll always be reflected in the <section> so there’s zero risk of any mismatches, or, or any of the Marketing Department coming after you. So that would say, “Join the mailing list region,” in this example. And if we were tempted to subscribe to our mailing list, it would then say, “Subscribe to our mailing list region,” and VoiceOver. So you’ve got that aria-labelby hooking itself up to the <h2>, or whatever value that is, that’s exactly what it will tell you, that region.

So, with that there’s no repetition and the <section> refers to the heading through successful name, and the heading is changed. If the heading is changed, the section just uses the new heading content. And again, I’m referring to myself, of course to myself “A <section> is a custom landmark… give it some semantic meaning with ARIA and screen reader users will be able to jump right to it, just like a sighted person, a sighted user can.”

Right, so I’ll talk now a little bit about some other powers, I’ve talked about the, the landmarking superpowers that you give people with, with using the, by using the <section> element correctly. But you’ve also got sectioning, in and of itself. So, what you can do is you can section headers and footers, so I’ll explain a little bit more about that.

Some, some landmarks are unique. So you’re only allowed one banner. You’re only allowed one main, you’re only allowed one content info. You can have several of other landmarks like, you can have several adverts, so you might have several complimentary landmarks but these three elem… these three landmark rules here, you’re only allowed one of each. But I don’t even know how to make sense visually because you’re, you’re looking at a website, you want to only know there’s one ,, that’s, that’s kind of the way these things work, you’ve got one bit of main content, one, one footer and that makes perfect sense.

But then there’s a bit of a clash and in that, we are actually allowed to use more than one header or footer. So where does that leave us? So I’ve had a look into HTML5 Dr. Website here where it says you can use multiple headers. “You can use multiple headers, each of which will then become a header for that section of the document.” So, this is also true of footers. But, what’s going on here? Well, and also yeah I mean what does it have to do with the <section> element? Well, <section> elements are, unsurprisingly, unsurprisingly sectioning elements. Sectioning content from the HTML living standard sectioning content is content that defines the scope of headings and footers. And there are four sectioning elements, one of which is <section>. We also have <article>, <aside> and <nav>. Those three, those four elements are what’s known as sectioning elements. So if you have a header or a footer inside there, it removes the implicit rule.

So, if you have those nested headers and footers, then they don’t, they’re not exposed as banners and content and info rules or landmarks. So what we’ve done here is we’ve made sure that we don’t give our users multiple headers, multiple footers. As far as the landmarks are concerned but we are able to use <header> and <footer> semantically inside discrete <section>s, whether that’s an actual sectional,<section> element or one of the other three there.

So, yes, so what we’re doing is we’re scoping <header> and <footer> elements. A <section> can have its own header and footer, and this is not the page header or footer. And this is an example, so if we go back to our, our amazing website that we’ve, we’ve wireframed and we’ve put the basic HTML together for, this is the bottom <section>, which was where we look at the packages and we’ve got a bunch of packages and this is very typical on websites. You might have three tiers, you might have basic Standard and/or Pro or something like that you got the three, three different versions and they all cost different amounts and that kind of thing. So, on this website, that’s what we’ve done, is we’re offering a Pro package and that’s our most popular package.

So we’ve got a <section> and inside that <section> at the top we’ve got a <header> and at the bottom we’ve got <footer>, and in between that we’ve got a heading, saying, “The Pro package,” and we’ve got a list of all the amazing things you get when you buy that Pro package. In the <header>, we’ve got an image, which is what makes its header, so it may be, maybe it’s bronze, silver, gold, you want to use that kind of metaphor. This one here would maybe have the silver or the gold badge or a little trophy or something like that. And some kind of identifiable marker that you can put in inside the <header>. And then the <footer>, you’ve got the, “Terms and Conditions,” and I may have a link to a page with some terms and the terms and conditions on it. So that’s how you would use a <header> and a <footer> in a <section>, as opposed to being part of the main page.

So now that we’ve talked about sectioning, we can talk a little bit more about outlining, or talk about outlining, for the first time. So, this is a bit more of a historical study, and I’ll tell you why. There was a thing when HTML 5.0, 5.0 came out back, I think it was released in 2008. So when that was finally finished they had this idea, a great idea of the HTML5 document outline. And I’ll start with a spoiler alert, it has been deprecated HTML 5.1 kind of got rid of it. It was tried, it didn’t, it didn’t take hold, but yeah, so it’s deprecated. So don’t use it.

What it did do, it was interesting because it allowed <sections> to be moved, moved around, without you having to worry about the markup. So you wouldn’t have to change a heading level two to a heading level three, if you were to nest deeper, or you wouldn’t have vice versa, or you wouldn’t have to worry about anything.

Basically, it would all take care of itself because it would be all be scoped to that <section>. And it’s a great idea for modular content, and if you’ve got to like a CMS that kind of works in that kind of that kind of way, where everything has its own place and you’re kind of in pulling those things out and putting them in your own order on the, on the homepage or whatever it may be, then that was a good idea. And it allowed you to mix and match it with <h1> to <h6> markup. So you weren’t locked. You didn’t have to have an <h1> for everything, which is what I’ll show you in the next example.

You could use <h6>s or <h2>s, and <h3>s. Or you could have a one page that has the HTML5 document outline and then another page, and then maybe written with with <h1> to <h6> and kind of more classic fashion, which is probably more for things like blog posts and things that you might want to use markdown to write. So that’s that’s the, that’s the kind of mix and match difference but very useful in certain circumstances. So this is the code that it may be built with going back to our wireframe earlier we’ve got the <main> element which has got everything inside of it and inside that <main> element, we’ve got a heading level one, which is the name of the company, “Example Limited Web Services,” and then you’ve got three <section>s.

First <section> is for,”Services,” The second <section> is for, “Testimonials,” and the third is for, “Our amazing packages,” and we’ve seen an example of what that markup inside those packages might look like in the last part of the talk.

“Services,” there we can see we’ve got two nested <section>s, one for, “Web design,” and one for “Web development.” And basically what what this very simple, simplified to is outlined example does is it demonstrates how everything has an <h1> and we’re using <section> elements to, to scope the level of the heading. So the ones that are surrounded by two, a parent and a grandparent <section> element, those ones are heading level three because their three levels deep. The ones that have one <section> as a parent, are our <h2>s effectively. And this is sort of how that would look as an outline so you’ve got the, example with limited “Example Limited Web Services,” and then you’ve got the three <section>s and then inside, “Services,” you’ve got those two bullet points, nested in there for “Web design,” and “Web development.”

So as I said, unfortunately, “The HTML 5.1 specification requires developers to use <h1> to such an <h6> to convey document structure, the HTML5 document outline is not implemented.” So that was from an article I think again it was on HTML5 Dr.

Computer says no to HTML5 document outline so that there. I mean, that was it, basically it was a it was a it was a shame. But, you know these things, these things are the way they are, and browsers even fail your nested headings properly when their scoped with the <section> element, you give it, give it a shot. It’s quite quite interesting to see how far it goes down the line. Google have confirmed that it’s cool with the outline algorithm that you’re not going to be competing for <h1>s as long as it’s all scoped <section>s from an SEO point of view but it was never fully adopted by user agents and assistive technology just means <h1> <h1> <h1> <h1> heading level one, so it doesn’t, it doesn’t make any, any doesn’t discern between the <h1> and the, and the nested two levels, <h1>, which should be an <h3>. So, we’re stuck with <h1> to <h6> for everything. And the good thing here is that it’s nicely backwardly compatible. So in our example here, we’ve just got the scope and same structure there, and <h1>, three <h2>s, and after the <h2>s two <h3>s. <h1> with the Services, Testimonials and the Packages and then we’ve got those nested, “Web design,” and, “Web development,” services in there as well.

In a way I’m kind of glad, I think the HTML5 document outline wasn’t really it, wasn’t really progressively enhanceable or, or a progressive, progressive enhancement. So it doesn’t really feel all that HTMLly, to me, because the idea of HTML is that it’s always going to be backward compatible, but what we’re doing here was we’re breaking things. And for users that may be using, well, screen reader users, for the great extent and also all the users that use older browsers as well.

So I think the final thing to take you through is the similar elements, how does s<section> differ from certain other landmarks? I mean, headers, navigation or <nav> & <footer>. They’re all pretty obvious in their uses, you know, they’re quite it’s quite, You know those are what they are basically. But some elements aren’t as distinct from <section>. So, we might benefit from a bit of a deep dive into those.

So, the <main> element as the most recent addition to the spec. This is the stuff that your <title> is talking about so the the <title> being that kind of meta data that appears in your browser tab. That is important for assistive technology and search engines alike. Basically this <title> is, this document is about this thing. This is the thing you can drill right into. It is for the main content of a document. You’re only allowed one on the page, and I mentioned that they’re perceivable so you can only have one displayed at one time, whether it’s visually or otherwise. But yeah, so if you have two <main> elements, one has to be hidden, and the other has to be shown, then you can maybe toggle between the two. I mean, for me I don’t see that being too, too much of a use case, but it is allowed. Essentially though you’re only allowed one.

It is probably the destination of your, “skip to content link,” so, and you’re, you might, you might be helpfully jumping past the big block of navigation at the top for keyboard users or screen reader users. So they can, the use of the tab index, they have this language which can jump past that, conveniently, and you’re going to want to get into the <main> element, because that’s the main part of the page. It’s also the thing that’s used by Safari for it’s reader mode, And I know that Firefox and edge, probably Opera it but not Chrome, for probably obvious reasons but the reader mode is basically zooms you in right into that main content of the page and gets rid of all the distractions so that you can really focus.

It’s also what we do later, services like Instapaper, pocket or Safari reading list is used as the kind of main focus of the page, they’ll, they’ll grab that and then stick that in your, in your reading list for another time.

It’s a, <main> isn’t a sectioning element. So we can’t nest another header or footer in there, and it’s worth mentioning, just because it feels like it should be but it’s not.

So the next thing is, is an <article>. The <article> element is a self contained chunk of content and it’s reusable elsewhere. And by reusable elsewhere, it could be the same site, it might be that you’ve got blog listing. It doesn’t have to be the whole article. It can just be a little snippet, teasing you, “Come and read this next article.” But it lives on a different page so it can, it’s that content, it can be put anywhere on your website, and it would make sense. You can also use it in an RSS feed, JSON feed or something like that. If you’re more if you’re a geek like me and you like to keep up the RSS or you can have it on an entirely different website. The the <article> is something that would make sense out of context. And it might link back to your main field blog post for example, but yeah that’s kind of what the <article> is for. It doesn’t have, doesn’t have to be a blog post, either it could be it could be something, something else, but yeah something to make sense out of context, context, you can have as many of those as you like. They can be nested one inside the other. And that is a sectioning element. It’s also worth mentioning that this is potentially the same thing as the <main> elements of what you may have as the <main> element wrapping an <article>. So, another <article> does expose things. I think that does have an effect for things like if Apple Watch and things if you, if you wanted to read an article in your Apple Watch or look for the <article> element. If someone sends you a link, for example, I mean it’s a very small article, very small canvas to be reading on but yet nonetheless. But yeah, so that’s, that’s how the <article> element works.

The <aside> element I mentioned earlier, that’s, it’s for content that’s not really related to the page. And so, for adverts. They might be related, you know they might be, they may be over theme, but it’s not what you’re there for. It’s not the content of the page. Social media feeds may come into that. they belong to belong to you there, they belong to Twitter or whoever, but the, you know, the, the, they’re your thing, but yeah, they’re an <aside>, they’re not part of what you’re actually there for and tangentially linked content of any type, really.

So they’re known for things like pull quotes, are often info or content filters and sidebars and things like that. I have seen a few things that point towards them as being for pull-quotes. The problem with that is that if they’re a child, they should be a child the <body> element because if the scope to something like an <article> or a <main>, then they’re not, then don’t get exposed to assistive technology. So non sighted users can’t ignore them in the same way that you could as a sighted user. So, yeah, the sighted user might have that banner blindness, the idea you know they’ve got that top right hand corner that’s for the advert, “I’m gonna ignore that.” And we want to give that exactly the same power to a non sighted user so they can dodge the sides and just concentrate on what they’re actually there for. So that’s that one. And finally, the <div> element, the, this is something with absolutely no semantic meaning or power at all. You can’t do anything fancy with it, without adding ARIA rules and all that kind of thing but but that’s probably something that you that you want to avoid if possible, or certainly if there’s a if there’s a semantic HTML element which will do that job for you.

And some questions to ask yourself, “Do you need to expose the element as a landmark? And do you need sectioning powers?” If not, it’s a <div>, and that’s, and that’s, those are the those are the kind of similar elements.

So just to sum up, <section> is for creating landmarks on the page for assistive technology. It’s for sectioning Header and Footer elements, so you don’t end up with multiple, which can be confusing, and you’ll, you’ll be breaking, breaking your automated tests with that I’d imagine. It used to be for outlining, not anymore. And then, as well as something different to me in <article>, <aside> and <div>, it has its own has its own use, as distinct from those. Thank you very much. That’s a, that’s me.

>>MICHAEL BECK: Alright, thank you very much Martin. Do we have any questions from anyone,

You need to throw it in the chat, or you can, if you feel like it you can unmute yourself and go ahead and throw that out, well PJ has question.

>>PJ: Now that we don’t have outline and we have the h1 to h6 giving us the structure, one of the problems I think is, is trying to prepare things and have it in a content management system and then being able to pull it in with the correct, you know the correct header. The advantage of something like, I guess a <section> or. Too bad about the outline is that you could create it with, you know, say in h2 and it would always be an h2 but you can pull it in, you know like, wherever it went instead of having to worry about it falling into the structure of the document. It’s more a comment than a question I think.

>>MARTIN UNDERHILL: No is a good point. My templates are often littered with context (Michael Beck laughs) so if this bit of content appears in this particular position, then give it an h2, If not use h1 and h3. Yeah, it gets a little bit burdensome doesn’t it, it’s the, the burden is on the developer I guess. No it’s, yeah, not ideal but…

>>PJ: Well especially if you have lots of people working on teams. It’s really makes it difficult.

>>MARTIN UNDERHILL: Yeah (pause). Yeah, it was one of those things that was a kind of a double edged sword when they, when, I remember being disappointed when it was, when it was removed back in, I think, 2014, but at the same time I guess that whole, that is not a progressive enhancement. It kind of felt like, “Okay, well, this is this, is probably for the best because backward compatibility or we’re not breaking things for, for, for certain users.” But yeah.

>>MICHAEL BECK: Gonzala Saverio ask, “Is the approach you are outlining hold across assistive technology products in versions. And how about the technical ability and age of users?

>>MARTIN UNDERHILL: Is this for the for the for the landmarking for the adding the rule to the <section>, adding the aria-label to the <section>, particularly?

>>MICHAEL BECK: Yes.

>>MARTIN UNDERHILL: Yeah, it’s pretty well supported. As far as I’m, as far as my experience goes, and the you have tested and, in, in, with lots of different combinations from your VoiceOver in Safari on Mac, same on iOS, and then looking at things like NVDA and Firefox, on Windows, and it doesn’t quite say exactly the same thing but it does convey the meaning of the of the <section>element. Different versions of the screen reader and browser software I wouldn’t want to comment too too authoritatively on that as time is goning by, but but but certainly things are looking good at the minute.

>>MICHAEL BECK: Bruce Blaser asked, “To clarify you do not need to make a <section>, a landmark in order to use the header or footer in it?”

>>MARTIN UNDERHILL: No, no, you can submit a <section> without, without an aria-label or an aria-labeledby attribute. It is just a dev effectively. Apart from the fact that it’ll, it’ll do that sectioning thing with nested footers and headers. It will remove the implicit rules from them, but effectively it’s a <div> so you can use any heading you want inside there. I would use a heading. Just for you, just for the way that document might be, maybe put together, and expect it to be, to be read. But, but yeah, it’s answered your question. Okay,

>>MICHAEL BECK: Let us know if not, but in the meantime, Elizabeth Patrick asks, “Is a section, the same as role=region?”

>>MARTIN UNDERHILL: Yeah, yes, that just exposes something as a region, yeah.

>>MICHAEL BECK: Okay, Sarah Bourne had a comment that, “Our folks, wanted the outline because they couldn’t make it work in their content management system. It turns out the browser’s couldn’t either. Oh, it’s probably still easier to get your CMS to do it though.”

It’s interesting. Okay. Anyone else have any questions for Martin or for, for anybody here? Any burning things that are going on at work. Just don’t get can’t wrap your head around.

Nope?

>>PJ: Um, I have one more, which is we just mentioned, role=region. How is that it, can then be used in conjunction with <section or other?

>>MARTIN UNDERHILL: Oh, it would be, I guess it would be implicit, with the, with the name, you could add role=region and it would expose as a region but without a label, it’s kind of meaningless. You want to give it some kind of meaning. And you would just use a section element anyway so because things may change things, you know, so the role=region may have or I might know some, I might not know something that the role=region would be, I guess like a button, if you’ve got a button and you give a <div> class of button you’re also gonna have to give it tab index=zero and all those other things that you need to do to expose it as a button properly so you end up doing more work to, to replicate the same thing so I would, I would always air towards using the HTML rather than the role.

I guess it’s a bit like a <nav> element, if you’ve got several <nav> elements on a page which is fine, you’re probably going to want to give each of those, a label, just in terms of looking at all the landmarks on the page, you can read through that list and know that you don’t just have navigation navigation navigation you’ve got primary navigation, you’ve got app, app specific navigation you might have global navigation you see you got different labels for each of the navigations and the same way that you would label each of the <section>s.

>>MICHAEL BECK: Alrighty, I think we are done with our questions and that brings us to an end to this webisode of Technica11y. Thank you Martin for that presentation. Thank you to our attendees, of course, for joining us. Our next episode will be on June 2 at 11am Eastern and features Stockholm’s own Daniel Goranson. He hasn’t said on a topic yet he has three or four that he’s bouncing around and trying to figure that out. But keep an eye on Twitter @tenonapi for that info once he makes that decision. And thank you again, Martin, and we will see you all next month.

>>MARTIN UNDERHILL: Thanks, all.

Martin Underhill

About Martin Underhill

Martin is a principal user experience designer who specialises in accessibility. He designs, builds, mentors, gives talks, writes (https://www.tempertemper.net/blog/), and is a proponent of minimalist, progressively enhanced, usable interfaces and experiences for all users.

Usability: the nexus of accessibility and design

Transcript

[Intro music]

>>MICHAEL BECK: Welcome to technically. So ladies and gentlemen and all variations there upon, welcome to this November edition of technically, for the new folks, I’m your host Michael Beck, the operations manager at Tenon. Today we are honored to have with us Kevin Kalahiki, the founder of Halemano designs. Did I say that correctly?

>>KEVIN KALAHIKI: Pretty good. Yeah. (Chuckles).

>>MICHAEL BECK: Welcome.

>>KEVIN KALAHIKI: Thank you.

>>MICHAEL BECK: Kevin will talk about how accessibility and design are like two languages that share common root and that root is usability. In this webisode, he’ll talk about some common issues, and how you can bring them up with your design partners in ways that you’ll both understand, and you know, won’t be talking past one another. And hopefully, you’ll be able to implement these to make your project accessible to all users. So without further ado, the virtual floor is all yours, Kevin.

Oh, and one quick thing, since we don’t have a little Q&A box on these meetings, go ahead and just put any questions you have in the chat and we will get to those at the end. So… all yours.

>>KEVIN KALAHIKI: Excellent. Thank you, Michael. And thank you Tenon for having me speak this morning. Thank you all for coming in. I’m in the US. Today’s a little weird, last night’s a little weird. So for anyone watching this on video, hopefully, things work out however you wanted them to work out. All right, and that’s as political as I’m getting today.

Accessibility, design, usability, like Michael said, you know, all sides of the same coin. Before we dive into this, though, let me talk a little bit, (computer makes noise) let me figure out my computer first and then let me talk a little bit about me.

The reason I want to sort of go into my background a little bit is to give you a sense of where I’m coming from, what experiences I had that led me to where I am now. So I started my career as a front end web developer at Wells Fargo back in like 2000. In 2007, I believe it was, Target was sued, that infamous lawsuit. And that’s how I was introduced to web accessibility. Somebody within the product team that I was working with said, “Hey, this is the thing we should probably start paying attention to.”

So that was it. In 2007, I started looking into it. 2008 I think it was I attended my first accessibility conference… And that was amazing! You know, I’m sure this is a something that’s shared by most of the people on this call, you know, going, going to a conference seeing… for real firsthand what it means to be an advocate for people with disabilities, what like, what it is you’re advocating for, was huge.

Throughout my career, I’ve led a dev team, prototype design team, design system teams and accessibility team and the product design team. So that’s kind of where this is coming from. The idea that, yeah, within my experience, with accessibility, I’ve also been on the dev side on the design side. And through all of that, kind of realized that, when we’re talking about accessibility, we are all kind of talking about the same things just from very different angles.

And then the last bit is, I know nothing when it comes down to it. There’s this sense that every day, it’s a learning experience every day, you’re looking for something to explain something else. Every day, I’ve got a million more questions than I had the day before. I find that to be important, but also a precursor to this conversation. If you have any questions, please let me know. And I apologize if I don’t know the answer to it, I’ll try to get back to you.

So, usability, for those of us on this call, I’m going to assume most of us are coming on to this, this call joining this meeting from the angle of accessibility. But hopefully there are others.

So you say accessibility, they say design, you’re both advocating for usability. That’s the truth of it. You’re both advocating for an experience that’s clear, nothing’s hidden from the user. You’re both advocating for removing all roadblocks from the users ability to do what they came here for. You’re both advocating for an experience that’s intuitive, through the use of established patterns and relatable content. And you’re both advocating for the user’s ability to choose when and how they access the experience.

You know, the perceivable, operable, understandable, robust, the, these are pillars for usability for everybody, even though, you know, we talk about them within accessibility as a way to sort of group organize, make it easier for us to to understand how to achieve accessibility within any project we’re working on.

These are pillars of usability that, you know, Designers don’t necessarily call them by the same names, but they actually kind of use them. They may not know them that way, but they’re there. And this is how… you, if you’ve been studying accessibility can help to bridge that gap, you’ve got these foundations of usability that are already a common ground with designers. Your focus may have been on advocating for people with disabilities, which is awesome, it’s needed, it’s absolutely needed. But when you’re going into the conversation with the designer, just broaden that focus a little bit, you know, and I think that is, in my experience, how this connection starts to work. Because in the end, it’s all about the user really.

>>KEVIN KALAHIKI: So conversations are kind of the key to all of this and some of them are really hard. These are some real fake quotes. I say they’re real fake quotes, because I didn’t actually pull them from anywhere, they’re not attributable, but they’re real enough, I’ve said these things so often, “Nobody else in the organization cares about accessibility.” This is a hard one for those of you that feel like you’re fighting the fight on your own. And it is, it is truly hard. How do you find your, your allies, your, your partner, someone that you can, you can really get together and help work towards a common goal with, when accessibility seems to be such a different principle than other people are advocating for. So that’s one.

Another quote, “This pattern is used everywhere, we can’t just change it.” This one’s pretty common, you have an accessibility issue with with, let’s say, a form field and that form field is in an application that is form heavy and maybe that application, maybe those forms have never been componentized. So if you fix this one issue over here, you’ve got to fix it everywhere. And that’s painful, that’s going to be hard.

This is the truth. None of this stuff is easy, none of this stuff is going to be easy.

Another quote, “The color palette defined in the brand style guide doesn’t have any viable color contrast options.” This is something that I come across all the time with color contrast being one of the easiest issues to identify, sometimes it is one of the hardest issues to fix. Because I just had a project this summer where all of the text, except for where they were using black on white, all of the other texts absolutely adhere to their brand Style Guide, which unfortunately did not meet any color contrast minimums, the colors they had chosen for their brand just didn’t work. So that requires this heavy, deeper conversation to go back up to brand.

Depending on where you sit in an organization, it can be really painful for you to be the one bringing up the fact that, hey, all the way up, that design change, somebody else needs to make a call that’s going to impact everything. My point here being these are hard conversations, nothing here is going to be easy. Well, hopefully some things will be.

But there’s a flip side to it, you know, coming from the design background. Designers also have to understand a few things. One of those things is, design is not about forcing a personal aesthetic on your user. I’m willing to bet that most of the people on the call if you’ve been doing accessibility for a while you’ve talked to designers, you get pushback, they just don’t like the idea sometimes of using a higher contrast color because it doesn’t look good. It, it offends a personal aesthetic. And that’s a conversation that happens.

But as a designer, it also has to be understood that a personal aesthetic isn’t what you’re there to do, you’re there to work in service of the user. And your personal aesthetic isn’t about that. It’s about what can get the user to do what they need to do. And so sometimes you have to help the designer come back, come back to that.

Another thing is innovation shouldn’t come at the cost of the user experience.

For those of you that have had to build crazy complex new interaction patterns, new new new widgets, new components that do a thing, that’s really cool. Sometimes it is really cool, this can be fun, this can be awesome. I don’t want to belittle the idea of exploring and building and doing new cool things. But sometimes all that work sort of defeats the experience. I think we always, I always advocate for if there’s a semantic element in HTML that does the job kind of look at that first because the experience is going to be easier for everyone, not just people with disabilities, anyone. Every browser knows what to do with basic form element, you know, that old thing.

So helping a designer understand sort of how to maybe sometimes it’s worth reining it in. If you’re advocating for the experience, just rent it out a little bit.

One other thing that I think is really important, and this is an extremely common ground here between designers and accessibility is, designers use things like research personas, journey maps, for a reason. They build empathy. They build empathy for their user. Designers have to kind of be all about empathy, how the, you know, you can’t design a thing, unless you really, really understand why the person who’s coming to use that thing, why are they doing that? What are they, what are they there to do? Why did they even come here? When they do get here, what do they need to do?

>>KEVIN KALAHIKI: It’s kind of, it’s kind of key empathy, this empathy thing, we have it, we build it up with accessibility, designers build it up. So lean into that, like rely on empathy. That’s, that’s going to be huge. That’s a, that’s a key tool that that both sides really advocate for and talk about.

Building trust, and I should, I should step back a bit and talk about what I’m, what I’m talking about in the beginning of this, is really just, some ways that you can maybe mentally approach what you’re doing when you’re talking to designers. When you’re working with designers, I will get to some examples, a handful of examples as well in a little bit.

So building trust is really key. One thing that I’ve learned over time is, in most cases, designers aren’t just being lazy when they don’t incorporate accessibility or they don’t want to do it. It’s hard. This is a new thing, potentially, for a designer. Or it’s a thing that’s always been a pain to them but they’ve never quite understood the reason why, why, why, do they need to do it. So I’d say step back to that empathy thing. You know, try to find that common goal where the designer understands there’s really an empathetic reason to be doing this.

Personas, you know, if you can get involved and help drive the conversation around design personas to include some elements of accessibility within them. One thing that I’ve done in the past is had personas that include users that use keyboards only. And you know, that covered a lot because we then had a persona that we had to, we had to address and that we had to test for, that said, this is a power user that just uses a keyboard, they don’t use a mouse, they can use a mouse, but they don’t. So we were able to work with design to sort of build that trust, doing things that way.

Understand that designers are looking for the best possible experience too. They’re not really trying to block you, they’re really looking for the best experience. So get with them and advocate rather for that experience together. One thing that’s really hard is sometimes it feels like accessibility is getting in the way to a designer. And I think that’s because accessibility is often the last thing to be considered. So really, from a certain point of view, it kind of is getting in their way. And that’s key when accessibility is the last thing. It’s, it makes it really hard.

So one other element of this is to see if you can build that trust, build that relationship and get in there earlier. Some ways that you can try to do that is talk to your designers. The idea of prototyping to me has been a key way of bridging the gap between design and accessibility because it gives you a way to walk through the experience together. Sometimes you don’t need a prototype, sometimes you can just sit with your designer, one thing, maybe the first exercise I ever did that really opened my eyes to using an accessibility with thought, to help a designer discover for their, on their own, things that I was going to need them to address at some point. I just sat down with them, one on one, and had them walk me through a flow. And I sort of asked questions on every step of that flow. It was a form. My background is mainly in the in the financial industry, so I’m talking about a lot of forms about collecting information, moving money, things like that. But it was really important to be able to sit down with that designer and just say, hey, okay, you tell me how this works. And I’m going to ask some questions, just from a usability perspective. And what that was able to do is sort of allow the designer to walk themselves into these dead ends, into these scenarios where they were just like, “Oh, I haven’t thought about that. I haven’t thought about error handling yet. I haven’t thought about what happens when this goes wrong. I haven’t thought about how weird this experience might be.”

So all of these little things that, when it comes to you, if you’re, if you’re in the position from an accessibility perspective, to have to code a design without ever having contributed to the conversation or if you’re in the position of having to assess a design without having contributed to the conversation before that point, those things get really hard because it is being tacked on at the end. You are having to work with something that is fundamentally not going to work. But in a lot of cases that doesn’t really have anything to do with accessibility, it has to do with the usability of a flow. And what I see maybe way too often is people whose job is to address accessibility. They’re really trying to shoehorn usability into something that may not have been usable in the first place. So these walkthroughs are key, they’re so key! If you can get in, get early, that’s going to help everything.

>>KEVIN KALAHIKI: So whenever possible, show the experience that you’re talking about. This is where prototyping comes in really handy if, if walkthrough of a static set of wireframes or mockups isn’t really happening, or it’s not getting what you need, or it’s not even drilling into, let’s say you’ve got a really complex interaction that you really want to show, hey, this is, this is weird, it’s going to be a weird experience. Maybe in your mind, you’re thinking of all of the ARIA craziness that you’re going to have to sort of pile in to make a thing work. But really, that’s also a flag for me, if you’re, if you’re thinking about having to pile on a lot of ARIA craziness to make a thing work, it might be good to go prototype that thing with your designer and walk through it. Because all of that ARIA craziness is really also sort of trying to serve some usability craziness that maybe could be simplified, maybe you could change. So building a prototype showing that tighter interaction in a way that actually shows the interactions, you don’t even need to talk about accessibility at this point. But if you can, sort of through, I don’t know, envision framer, if you can do sketch Figma. Build a basic prototype to get to the fidelity that allows you to have this more detailed conversation with the designer before, before a developer is trying to build it. Before anybody’s concerned about the accessibility of the thing… get there early.

And the last bit understand the tools that designers are using well enough to use them to communicate each other’s ideas. So kind of what I was saying with prototyping, a lot of the more modern design tools actually have prototype tools built in. So in little ways, if you know a bit about Figma, it really depends on what, what your design team is using, what tools they’re using. But I’d be willing to bet at this point, most of them are either in their primary design tool or in a secondary design tool, like InVision. They probably have access to some sort of a prototyping tool. And as prototyping tools, you know, they generally don’t get really into the details of interactions. So that’s a little hard, because that’s a lot of where we live when we’re doing accessibility. It is really in the fine tuned interactions.

But this idea is all about taking a more abstract idea of the usability of a flow and making it more concrete. Prototypes absolutely help lead you towards that concrete idea. It, it refines the focus a little bit and puts both accessibility and design on a bit of a more common ground when you’re talking about what the experience is supposed to be versus what it might be.

And this is all about conversations. I was working with a Content Strategy Team once who really opened my eyes to this. If you’re if you’re dealing with forms, if you’re dealing with user input, really, you’re talking about a conversation. What’s your name? What do you need to do today? How much money do you need to send? You don’t have that much money in that account. How about this account? Does that look good? All right, we’re done. That right, there was basically a money movement transaction form.

It’s not that simple. But one thing that I’ve come at, come to the conclusion of is, if I’ve been thinking about a flow, if I’m thinking about sort of any form field or any sort of user input, I think about it as a conversation. I imagine that two people are talking this thing through and then saying, Okay, what does, What does the first person say? What are the possible ways that the person that’s trying to do something can respond to that. And what this does in my mind is also gives me an a framework that I am then able to go back to the designer and sort of talk through a flow.

Because, again, designers aren’t lazy designers aren’t, (mumbles: not all of them) designers aren’t against accessibility. They’re also under the gun. They’ve got a deadline. They may be working on a two week sprint where they’ve just got to power through these designs. And maybe they didn’t have a chance to go talk to the product team about the requirements. So maybe they’re dealing with their own problems that we never see, you know, and maybe all the problems that the designers are dealing with are just turning into this, really, they’re really rushing through a thing. And they didn’t have a chance to think things through as they were designing a flow. So for me thinking about a flow, at least in the the case of user input as a conversation really helps that because then I can go back to them when I’m having that sort of wireframe walk through with them, if I’ve got it, at least in my mind, what would this conversation actually look like? It helps to sort of drive that, you know, and again, it’s not accusing a designer of missing things. It’s just sort of walking through scenarios, a little bit of role playing.

>>KEVIN KALAHIKI: So continuing the topic of it being all about conversations, if you have a Content Strategy Team, anywhere in the organization, get to know them. This is something that I also learned early on in my career. One of the biggest accessibility issues that I had to deal with, fairly early, was a password strength. What do you call them? I should have thought about this ahead of time. But when you’re entering a new password, you’ve got feedback that says, “Yeah, that’s a great password.” “No, that’s a terrible password.” “Here are the password minimum requirements.” And in this particular case, none of that feedback was visible at first, it only started to show up after the user start typing things in and failing the requirements, then they would see Oh, you didn’t do that. So you didn’t do that.

So I pulled in the Content Strategy Team. And I said, “Hey, if we think about this, like you tell me Content Strategy (Team), how you would picture this information to be displayed back to the user?” how to like, you know, take it as a conversation. How would you want the user to know that these requirements even exist?

And I was able to actually kind of put this accessibility task back on the Content Strategy Team. And have them sort of figure out, “Okay, what is the content that we’re trying to tell? How should this be presented to the user? Is it important for them to know all of this immediately before they enter the password? Or is it okay for them to discover this after they fail?”

You know, content strategy goals are often really aligned with accessibility, even if it’s not explicitly about accessibility. They, the goals are about helping the user understand the thing. Content Strategy can be your ally in some of those painful conversations.

So like I was just talking about, it’s not just in that particular case, it wasn’t just me, against the designer and the whole design team, as it were, at that point. I was able to find an ally in the Content Strategy Team and have them come in. And sometimes it’s good to just have friends on your side of the conversation, you know.

And also, they might be able to use your help, too. And maybe they’ll give you a trophy, like they gave me, that was really cute. But that was fun. It was a there’s a trophy screenshot here on this particular slide that I was given by the Content Strategy Team I was working with. And I was working with them specifically because of accessibility. And I was really trying to get them to help me define content types, define all sorts of things that I needed definition for. They existed, this is their world. So I really just kind of pulled them in. I gave them more work to do. But they gave me a trophy. It was weird. It was awesome. Content Strategy, I can’t say enough, if they exist in your organization, get to know them, lean on them a bit.

And yeah, questions. Michael mentioned earlier that we don’t have a Q&A. But if you have questions, start queuing those up because you don’t want to listen to me talk for the next, you know, 30 minutes… just rambling like I am.

All right. Now, a few examples. But first, keep these things in mind, not everything has to be a flight. But if you find yourself walking headlong into a design fight, bring everything you already know about usability. So remember, the perceivable, operable, understandable, robust this principles that you already know, these are foundations of usability, just walk in with that. This isn’t a fight. This is design and accessibility looking for common ground. That’s all this is.

Okay, picking on carousels, I think we probably all have our own horror stories related to carousels and they never seem to go away. Just yesterday, I was writing up a requirement for a carousel. And the first question that I ask when carousels come up is, “How important is all of this content?” Right? You’re talking about an element that is fundamentally hiding whatever percent of content it contains. If you’ve got a five slide carousel or a five segmented carousel, whatever you want to call it, you are fundamentally hiding four pieces of information from the user. At any given time, you are potentially hiding that from them forever. Depending on what you have, where this carousel lives, whatever the purpose of this particular screen happens to be. It’s highly unlikely the user is going to see all five slides of the carousel, much less two of them.

So the next thing I ask is, “Which slides do you think are super important?” Because, you know, what’s the default slide that’s going to show up on the carousel? If, if you actually want, if you want all of the content to be given to the to the user, the fact is, they’re not going to get all of that content. It’s just not going to work out that way. Unless you’re carousel happens to be living on a page where the carousel is the reason they’re there. And they’re there to sort of watch content flow through. But I think for most of us, that’s not the case when carousel pops up, and most of us, for most of us, the carousel tends to be a sort of a lazier pattern. And I will say this, I think it’s a it’s a lazy design element. It’s a lazy design pattern, not that the designers who implement them are lazy. It’s lazy in the sense that it’s a really quick, easy shortcut for everybody to be like, Okay, I’ve got all this content, it’s maybe not that important. Let’s throw it in the carousel that obligates, that meets our obligation to show this content in some way.

But these conversations that I’m having at this point often are not with the designer. This is also probably a key point to take away, sometimes you don’t just talk to the designer. Sometimes you’ve got to have the designer and maybe a product person. Maybe whoever’s driving for this content to exist, maybe it is content, maybe pulling content strategy in at this point would be a really good idea. Maybe it’s them pushing for the carousel. Again, none of these conversations are cut or dry, cut and dry or necessarily easy.

Which slides are you cool with the user never seeing? That’s an important question, kind of going back to what I was just saying. And how important is all of this content? Again, in a carousel, unless the carousels is the focal point of a given page, the user is never going to see all that content. So whoever thinks it’s important for that content to be there really has to understand that the content is never going to be seen by everyone.

So moving on: Form fields: Alright, so I added two screenshots to this. The contrast issues with those screenshots came as they were on the screen, on the scene, that are sorry, on the site that I took the screenshots from. I won’t say where I got them from but the screenshots are of form fields. And the form fields have no labels. So, “What happens when I type in the field?” This is a common question. Whenever I see it, a form field with no labels, with no visible labels, where maybe the placeholder is acting as the label. That’s, that’s usually my first question to a designer. “What happens when I type in the field?” Because labels make it clear when information is expected. And the opposite of that is 100% true as well.

If I’ve got three form fields with placeholders as labels, but no visible labels, and I enter values into each of those fields, now I’ve got three form fields with my values in them. I’m hoping that whatever I entered was right. But what if what I entered was not correct?

Now, I have no idea what the form field was about. And what happens when an error occurs? Users not always going to get it right. So you have to account for an error. And if your error state is just turning the box red and putting an unhappy face on there, with no additional messaging, not only do I not know what that field was, now, I don’t even know why it’s an error state.

So another conversation to have with the designers is, this kind of goes back to that idea of potentially, this is used everywhere, change is hard. This is an opportunity to help them build a design system that kicks a little bit more ass. You know, it’s a little bit more robust. Hopefully, they’re using a design system. Design system style guides, these are things that help build a structure and a sense of, sort of reusability, a sense of commonality across a site, across an app, that are really key.

>>KEVIN KALAHIKI: You know, developers, if you’re a developer on this call, who’s working on accessibility, you were probably a huge advocate for componitizing your, your accessible components, your accessible widgets. Build it once, reuse it often, bake in all that accessibility goodness and then use it everywhere you can. That same idea applies to design in a design system.

Within Figma now, there are still the notions, the same notions of components. You can build design components, of a form field, for instance, a text, a text input, can be designed and that component can be designed and then that component be added to a library that then is consumed throughout Figma files. And here I’m talking very specifically about Figma because that’s a design tool that I’m currently using. But this concept works and other things like sketch and probably others.

But the idea that there is a design system that you as the accessibility advocate can now help tighten up, if you find yourself dealing with an issue where form fields don’t have labels or form fields don’t have proper error handling or messaging, work with the designer and advocate for them to create a design system if they don’t already have one. Because the benefit that you already know, you get from componentizing things, they may not know that yet but it’s pretty clear once you tell them, “hey, you fix this once, and then you push that out to all of your designs, and it just automatically gets that fix.” That’s huge. That’s, that’s awesome.

So this might be a really hard conversation to have once, twice, a handful of times. But hopefully, if you can get the designer to understand the the fundamental usability issues that are at play here, then you can also help them understand how to make their process and their practice work better.

Alright, links in text. So I totally stole a tweet from Shell Little. This happened to come out like just the other day If you look up the date, October 30th, the tweet and I apologize for the language, “Hi, I’m Shell and my only job is to remind designers to underline that beep (says “beep,” to replace the swear word in the text he is reading) link. Thanks.”

Links in text. This is an interesting one to me because I think you can come at this in a bunch of different ways. Well, maybe two different ways. The way I come that a link in text is, yeah, number one, that link definitely needs the underlying, it definitely needs a way to sort of stand out from the other text that happens to be sitting and sure that’s the usability side of a link in text. But And just to be clear, what I’m talking about here, sorry, is the idea that say you’ve got a paragraph of text and within that paragraph, maybe you’ve got an email address that you want to be able to have a mail to link on. So within a paragraph of text, you’ve got one linkable active element, maybe that that content links to another page. So the underline will help to call out that within this regular text page right there in the middle, highly visible, easy to spot, is something that you can take action on. That’s the usability part of a link in text.

My first question is always, should that link actually even be there in the first place? I think of links and text, I think of them like trapdoors, like you’re reading along and then suddenly, bam, you’re on a new page. So think about you’re reading a paragraph of text. Then within the middle of that paragraph of text, here’s this link. So you just click it, because you know, there’s a link, you click it, and suddenly, you’re not in that paragraph of text anymore, you’re on a completely different page. So is the content that the user fell into more important than the content that the link was in? Like, to me, that’s a super important question. And this is really taking what seems like a really simple thing, I’ll link in text or an underline on that thing. And really questioning the fundamental idea of its existence in the first place, this really existential idea of should that link have been in the paragraph of text in the first place? Because remember, think of these things as as conversations, the users on this page for a reason, is that link functioning like a trapdoor in the middle of a paragraph of text, does that service, that conversation? Did you really think of the conversation as being, “hey, let’s talk about this thing. We’re talking about this thing, let’s talk about this thing,” boom, “now we’re talking about this other thing?” And yeah, probably not.

That’s probably not how the conversation would have been outlined if you’d had a conversation. It probably would have been more about discreet thoughts, discreet thoughts, maybe an action in support of that thought, after the fact, once you’ve got all the information.

So does sending the user away from this page help them do what they came here to do in the first place? You may not have the time to go into this very deep level of conversation about a link in text. But I do question given wherever I happen to be in a project, sometimes if I’m just the accessibility auditor, who really has to just like, Hey, this is an issue. Yeah, I’ll say, “hey, throw a link, or rather throw an underline on that text”. But I will also try to say, “and by the way, you know, think about this from a content perspective. You are providing a way for a user to lose their focus. You brought your user to this page but then you’re giving them all of these little trapdoors to leave this page. Is that what you want to do?” You brought them to this page to do a thing, let them do that thing. And in the course of that, maybe inform them of these other options.

But keep in mind, are those things options or are they fundamental to the flow? And if they’re fundamental to the flow, then probably you need to rethink the conversation in the first place.

And this is going to be the last example that I’ve got. Because I do want to leave room for questions and to sort of talk if, hopefully, people do have questions, but visible focus indicators. You know, again, all of these examples, I am not talking about them from an accessibility perspective, I’m talking about them from a usability perspective, usability for everyone. I’m not talking about them just from the use cases that we might think of them .When we’re talking about a visible focus indicator, from an accessibility perspective, these are really truly from the usability perspective. And with a visible focus indicator, when you don’t, I shouldn’t say when you don’t provide it because most of the time, what’s happening is, it’s actually being taken away from the user. You know, most browsers will by default, show a visible focus indicator that works for someone who’s tabbing through a site or through a web app, or, or an app. But, you know, removing that default visible focus indicator is actually an explicit action in most cases. So talking about this from usability from a usability perspective, the secret usability tip is that sometimes navigating with a keyboard is actually easier, even for people who can use a mouse. Ask a bookkeeper, someone who is constantly, as their job, working on something like a spreadsheet or forums or data entry. Watch them, see how often they use a mouse. And it’s not going to be very often.

So giving someone the ability to sort of use the keyboard as their dominant way of entering and navigating the site can actually really help out. Except when the person can’t tell where they are on the page again, ask a bookkeeper. So if you’ve taken all the visible focus indicators away, let’s say that you’ve got a Google Sheets type interface, for instance, and somebody is using that. They tab, they arrow, but they have no idea where or what cell they’re in or if they’re on a page long data entry form field, or form entry and they want to tab to fields but they can’t tell which field they’re on. So they’ve got a tab and click new type just to be like, “Okay, well, there it is. Okay, cool.” That’s very frustrating. It’s very angering.

So these are just usability things. I mentioned earlier, the idea of leaning on some very basic design principles that you can use to help bake in your, the accessibility concerns that you might be bringing to the table. Personas, again, become a thing. So right here where I’m talking about a bookkeeper as being a persona that might actually need to use a keyboard all the time for their work.

If you aren’t sure about this, advocate for user research, usability research. This is also a design thing. Hopefully designers are advocating for this. For them to be able to do their own work. But if they’re not, if it’s, if it’s not part of the process, advocate for it. Go and tell your design partner, “Hey, I think we might want to see how bookkeepers use this thing that is fundamentally a tool for them. Let’s go talk to 12 bookkeepers and really say, Okay, how do you do this? How do you do this on a daily basis? What do you do when you’re working with a form field like this, or when you’re doing something like this?” and just let them show you.

You know, that way, this research can help to provide a grounded unbiased approach to why you do something in the first place. You know, it could show you, the accessibility advocate, something that you’d never even thought of before. It might be able to provide you with some hooks into a conversation that again, when you’re coming at this thing from accessibility, oftentimes there’s this perceived idea that, you know, we’re just talking about blind people or people who are using a screen reader. Like it’s really hard to break someone out of that preconceived idea of, “accessibility is all about color contrast,” and nothing else.

That’s still a conversation I have on a, not a daily basis, but way too often. I’m sure everybody else does when you bring up accessibility, I think more people are aware of what accessibility is now, but still their scope of what they think it is color contrast or some handful of other things, text alternatives on images, you know. The accessibility is become more common knowledge but not to the, to the depth that allows other people who aren’t accessibility experts to have an informed conversation on it. So what I always advocate for here is to try to meet on their common ground. Yes, you, you as an accessibility advocate, you have a very important job to do. And sometimes it sucks that nobody understands it. But in order to get people to understand that one way to do that is find the common ground that you have with them and bring it together that way. So if you can rely on things like personas, research, basic underlying principles that designers rely on, you can hopefully make that design accessibility conversation a lot more seamless, a lot smoother.

And that’s it for me. I really hope y’all have questions. Otherwise, this is a relatively short presentation.

>>MICHAEL BECK: Not at all, that was 40, almost 45 minutes.

>>KEVIN KALAHIKI: Okay. (laughs relieved)

>>MICHAEL BECK: I actually really liked that you brought up look at a bookkeeper. I was a librarian for 20 years before I got into accessibility. And the cataloging systems that we use, I was a cataloger and the cataloging systems we use, I would use the keyboard constantly because having to use the mouse to flip in between fields because it was all forms. Basically, I was filling out forms to catalogue books and other materials. And my boss would always use mouse and she had carpal tunnel because of it. She learned that or figured that out. But I learned how to use the keyboard very quickly. But there was there definitely were some focus issues and I, our provider at the time, I actually let them know about that. And in a later iteration, they actually did fix that.

>>KEVIN KALAHIKI: That’s awesome.

>>MICHAEL BECK: That was, that was, I was very impressed with how receptive they were in the end. I think that they knew that. But then whenever they pushed out the the version that we got, they weren’t quite there yet. They hadn’t quite figured it out yet. So I kind of just gave them a little, gentle little nudge to something they already knew was an issue and now they actually had the user who was like, “Hey, what about this?”

>>KEVIN KALAHIKI: Yeah, yeah. You’d be surprised how often that becomes the thing. I, one of the projects I’m working on right now, they are taking on accessibility not because they got sued but because two or three of their users have said they can’t read the type on their on their app. And yet, sometimes just reaching out to people and just being like, “Hey, I can’t use this.”

>>MICHAEL BECK: That’s great for your client, actually having the wherewithal to be like, “Oh, yeah, let’s, let’s do that. Let’s get ahead of this.”

>>KEVIN KALAHIKI: Yeah.

>>MICHAEL BECK: That’s good… Well have any question? That’d be amazing questions.

Sarah has a comment that said, “The best use case she has ever seen for carousels is to stop arguments about what goes on the homepage. But that’s, an it’s an internal user problem.”

>>KEVIN KALAHIKI: Yeah. Which in that case, I’m curious. So Michael, how does this work? They can chat back, right? If I have a question for Sarah? Okay. And Sarah, you don’t need to reply to that, but…

>>MICHAEL BECK: Mmmhmmm

>>KEVIN KALAHIKI: Okay. And Sarah you don’t need to reply to that, but…

>>MICHAEL BECK: Sarah can actually unmute herself if she would like to have an actual conversation.

>>KEVIN KALAHIKI: Yeah, that would be awesome. But, Sarah, I’m curious about that. Do you mean in the sense that everybody wants something on the screen and they’re like, equally have weight in the conversation? So just somebody is just like, “Okay, look, but we’ll put it all there in a carousel. There. You all have your content.”

>>SARAH: Yeah, that’s it exactly. Especially since it’s usually something of really important to themselves. So I work in a state agency. So they’re doing some sort of marketing campaign to push a certain program but that’s not what the users are actually coming to their site for. And and it would be, you know, people would have to scroll for miles before they could actually get to the things that the users care about.

>>KEVIN KALAHIKI: Yeah.

>>SARAH: So so that kind of solved that. And I think that that even doesn’t even actually happen as much as it used to because so many people now, don’t go to the homepage and navigate, right. They’re searching from someplace. (giggles) So some of those arguments have gone away. But but it did make that whole discussion just change course. We stopped wasting time having conversations like that.

>>KEVIN KALAHIKI: Yeah.

>>SARAH: And they were happy because their content was right at the top of the page and we were happy because we didn’t have to look at. (Laughs)

>>KEVIN KALAHIKI: That’s, that’s a really good point,ya know. I don’t think any commonly derided element necessarily needs to just be banished and go away. I think what you just talked about is maybe a really good use case for a carousel. As long as it’s accessible, as long as you can put controls on it, like pause, stop, play, toggle through, maybe it is a really good way to sort of bury some things and bury a potential fight between partners. That’s it. That’s a really good use case.

One of the other things that I’ve done on carousels, when it hasn’t been necessarily so many people fighting but somebody advocating for things was just be like, “Hey, go check your analytics. You go go look at the analytics of this. Tell me how many people have accessed all of the content in your existing carousel, from the carousel.”

That oftentimes is a really good argument because then there’s like, “Oh, we get no return on investment for these slides that are buried deep in the carousel, because nobody’s even clicking on them. yet. We’re spending all this time figuring out content design accessibility for the carousel.”

I think when you point out how much work goes into something that users never use or see, sometimes that’s a good argument as well.

>> SARAH: I do. I do like carousels for pictures. If I’m shopping, I like being able to swipe through pictures of the product I’m looking at from different angles or somebodies photo album. It’s, you know, especially use touchscreens a lot. So swiping is easier than scrolling.

>>KEVIN KALAHIKI: Yeah, it is, that is an absolutely great case. I did try to call it out at the beginning. Like that idea that sometimes the carousel’s purpose actually is why someone’s there. Shopping. You’re You’re totally right. I think that’s that’s an excellent use case. That is exactly why, if I’m shopping and I need to see a thing or at least understand what this thing is, the carousel probably is really helpful for that.

>>MICHAEL BECK: Alrighty, anybody else? Back to my zoom meeting area. Nope. All right. Well, thank you, Kevin. That was, I really liked that you kept advocating for pushing left as we say at Tenon. Getting this, getting everybody involved in beginning so it’s not an afterthought and therefore accessibility becomes a pain.

>>KEVIN KALAHIKI: Yeah, that that really is it man, you. All of these things are eased up so much. I mean, I’ll tack that on, the idea, ya know talking about my career path. At the beginning, this is kind of that idea, I think my career path shifted left, if you will. And it helped to drive the conversation on accessibility. It helped to wedge it in earlier because that’s, my role became more about being in the on that left side of it. So it’s it’s huge. That is, that really is, you’re right, Michael, that really is where that conversation needs to start, where it needs to be.

>>MICHAEL BECK: We’re working with a client now that came to us for an audit and now they’re actually excited about injecting us into their, in their workflow, because they’re, they’re new, they want to make sure they do it right the first time.

>>KEVIN KALAHIKI: Nice!

>>MICHAEL BECK: Fantastic. Alrighty, so that brings us to the end of this webisode of Technica11y. So enjoy the rest of the year, as much as you can. Thank you to Kevin again for that wonderful talk and all of you for joining me, especially making it here today. And I will see you in the new year.

>>KEVIN KALAHIKI: Thank you!

Kevin Kalahiki

About Kevin Kalahiki

Kevin Kalahiki is the Founder of Halemanō Design.

ARIA Serious?

Transcript

[Intro music]

>> MICHAEL BECK: Welcome to technica11y, the webinar series dedicated to the technical challenges of making the web accessible. On this webisode we have web accessibility specialist, Eric Eggert.

>> MICHAEL BECK: It would really help if I unmuted myself. (Chuckles).

>> MICHAEL BECK: All right, ladies and gentlemen and all variations thereupon, welcome to this October 2019 edition of technica11y! It is fantastic to have you with us today as we kick off our second season. Yes, it’s been a full calendar year since our first webisode, so a hale and hearty thank you to those who have been with us every month since then and I do see some of you in the participant window and an enthusiastic and warm welcome to those of you who are joining us for the first time! We hope you’ll continue to join us in the future as we continue to present these deep dives into the, well, technical aspects of making the web accessible.

Today’s presenter is Eric Eggert. Welcome, Eric.

>> ERIC EGGERT: Hello. I’m unmuted! (Chuckles).

>> MICHAEL BECK: Eric, as I said, a web accessibility specialist. He is with Knowbility and a member of the W3C’s Web Accessibility Initiative and he’ll be talking today about the pitfalls one can come across while using the Accessible Rich Internet Application attributes in one of the most cleverly named presentations I’ve seen in a long time “ARIA Serious?”.

I know I hear a lot of about the misuse of ARIA on a daily basis at Tenon and how it’s meant to supplement HTML but, unfortunately, too many developers tend to use it instead of proper semantic HTML but I’ll let Eric cover that, so take it away, Eric!

>> ERIC EGGERT: Thank you for the invitation. Yeah, this is my talk, “ARIA Serious?”. I’m a web developer and teacher who works with Knowbility, which is an Austin nonprofit, on improving the web for people with disabilities. And 50% of my time I work with Knowbility goes to W3C in a fellowship model so I can do things like working on tutorials and other stuff.

So that’s really nice from Knowbility, so that’s why I want to shoutout and say, “Thank you,” for that.

And yeah, this is a presentation that I like to give because it has two components in it. It’s first an overview and then we look at like practical examples, real life examples. But that means because those are real life examples, I have to put a warning up first.

This presentation contains ARIA examples that are preventing Websites and applications from being accessible. So, please, don’t just copy and paste the code that is in this presentation because, you know, it will break stuff. That’s the whole point.

And yeah, I will do my best to describe the code examples that I have in there and read them aloud. So, if there is something that I need to repeat or specify, please let me know. So what is WAI-ARIA, really? So, Michael already said, it’s the Accessible Rich Internet Applications. That’s the ARIA part. And the WAI part is Web Accessibility Initiative. So, there had been a name clash so we had to prefix it, so it was one of those. You can basically ignore the WAI part and be good with it.

But the core with ARIA is the attempt to take accessibility APIs that are present on the desktop, in this case a Windows XP type of desktop environment and map that to the web.

So, making it possible that web applications can basically use the same APIs as like native applications on those platforms.

So, it’s really important to know that this is about Internet applications, the emphasis is on that. And we have to keep that in the back of our mind when we use it, especially on “non-applicationy” websites.

Some might think ARIA is just, “You put it on and it works!” But it’s neither witchcraft nor sorcery; it just doesn’t work like that. You really have to know what you’re doing. There’s no `ARIA-make-accessible = true` that just makes your website accessible, like, in one fell swoop. It’s how ARIA interacts with the rest of your content and we have to understand ARIA and the principles, the underlying principles, fully, and then deploy it where we need it.

There are five rules of ARIA. From the Using ARIA document.

And I think going through them one by one really gives us a good impression on what that is and I have a couple of examples and demos in there, so we know how to use ARIA.

The first rule is, “If you can use a native HTML element or attribute with a semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so.” That’s a very complicated way to say, “If there’s an HTML element that does what you want it to do, then use this HTML element.”

The second rule of ARIA is, “Do not change native semantics, unless you really have to do.”

And that basically means the semantic of HTML elements is already set; a paragraph is a paragraph, a list item is a list item.

We already know that.

So if you don’t really have to change that, then don’t. And there are only a couple of really good reasons to change the native semantics.

So this is one example here and I’ve seen such things in real life. It’s an `<h1>` with a `role=button` and then it is a heading button. That is what the developer thought they were doing.

But the problem is that, because we have the `role=button`, this is not a heading anymore. So a screen reader user using heading navigation would never find the `<h1>` because it’s not a heading anymore.

Once you put a `role` attribute on an element, it takes away the semantics that are already there. And replaces them with the new semantics. So this is now only a button and only semantically. Please don’t copy this.

The good example is having `<h1>` and then a `<button>` inside that. And then you have basically both. You have an `<h1>`. And you have a ‘<button>’. And that works.

And it also has like keyboard navigation stuff built in, which is also important.

If you say, oh, this makes — nobody would do stuff like this, sometimes you see gems like this from my a colleague Nick Steenhout who found this in an accessibility audit an h2 with a class h3 with a role heading because it already is a role heading but we add role heading just to make sure and then there’s ARIA Level 1 so actually this is an h2 that looks like an h3 but for screen reader users it’s actually announced as an h1.

Why would one do something like that? I don’t know. But people are doing some stuff like this all the time. So in this case there isn’t an element that has a role heading and a Level 1 and that’s an h1 element so use the h1 element. Really simple rules here for ARIA.

Third rule, already talked about that. All interactive ARIA controls must be usable with the keyboard.

And that’s interesting because there are two things in there. So first there’s the keyboard. And the other thing is interactive ARIA controls.

So there are two classes of ARIA controls. There’s simple controls like buttons and stuff like that. Those are interactives. And then you have like the really complex ARIA widgets like let’s say a date picker or a grid navigation or something like that.

And those have different needs for keyboard navigation.

If you create a widget that the user can click or tap or drag or drop or slide or scroll, a user must also be able to navigate to the widget and perform an equivalent action using the keyboard.

So if everything you can do with the mouse to an interactive element, there must be an equivalent way to do it with the keyboard.

Which makes sense.

And all interactive widgets must be scripted to respond to keyboard keystrokes or keystroke combinations where applicable.

So this is basically reformulating the same thing. So basically if the element does not have the native way to react to keystrokes, then using standard key stokes can help — then you have to use JavaScript to put those native keystrokes in and basically rebuild it.

And that’s a good example in the ARIA practices guide. And I use it because this is a really simple thing. So if you use role button on a div for example, then the element must be able to receive focus and the user must be able to activate the action associated with the element using both the enter or return key and the space key.

So if you are using JavaScript to build a button, it must work with enter on Windows or return on Mac OS which is just the same key it just has a different name and nobody knows why. Somebody probably knows why.

And it also has to work with the space key. If it doesn’t work with both, then you’re basically violating the expectation of the user for such an element. And now a user expects that the button works with the space bar.

And I have a demo here.

So those are four buttons. And they are labeled first, second, third and fourth.

And they are implemented in different ways. So going back to the HTML, the first one is a real button with the class button and then we got a div then we have the div with tabindex equals 0 and then we have div with tabindex equals 0 and the role button.

And I also have an event list now that listens for the click event and that’s on purpose.

So if we go through it using the keyboard navigation, probably I just tell what happens and be the human screen reader.

So you tab through and this, because it’s a button, it would announce as first button. This would be great. So now if I press the tab key, because the second button is just a div and although it works like, you know, with the mouse as you would expect, but because this is only a div without anything else, it can’t actually be focused. So it is automatically skipped.

So I go to third. And this is only readable because it has a tabindex 0.

So from here to — from first to second we have basically given up all of the semantics. It would not announce as button because it doesn’t know that it’s a button. And the third would just announce as third group or other screen readers would be different. But it would not be announced as button. It would just — because that information is not given anywhere. So we can use role button and then when we tab here, it would be equally announced as the first one.

So the fourth button would be announced as fourth button.

And that’s great, that’s what we want. This announcement. But this gives us still a problem. Because this first one, I can go back and I can — if I find it again. Oh, live — live demos. It’s exciting. If you press enter, you get the dialogue box. As what you would expect.

And if you press space, the dialogue box is there, as well.

With the third one, I can press enter and space and nothing happens and the same is for the fourth one. Because we only have put on the role buttons and tabindex 0, the browser knows it’s button. But there is actually in the background of the browser they — on real buttons and real links, they interpret the event listener — the click event as keydown events and basically make this transparent so you always get the same interaction when you’re using a button.

And this is not there if you’re just repurposing div. So the long story short really is use a real button if you want button functionality because otherwise you have to do all that work for yourself. You have to put in all of the event listeners for yourself. You have to make sure that it works the right way. So for example, on a button, if you click, then you drag away from the button then nothing should happen if you implement it wrongly like in a different way, you might run into problems where this expected feature is not working anymore.

So while a button seems to be a relatively innocent and simple thing to do, it can be actually quite complicated to implement it if you have to do it by hand so let the browsers do the hard work.

Fourth rule.

Do not use role presentation or ARIA hidden true on a focusable element.

The thing is, role presentation and ARIA hidden true, they remove either the semantics of the element or they remove the element completely. So if I got a button which is inside a role presentation, marked up container or has raw presentation on it, it will not be announced as button, it’s undoing the semantics there.

And if you have ARIA hidden true, then this button will just not be there if you’re using assistive technology.

On screen you’ll see your focus, it’s all good. But a screen reader would just not hear anything. It’s like there is nothing and they tap to nothing and that’s bad. And the fifth one is all interactive elements must have an accessible name.

So if you have a button, it has to have some text on the button. That’s useful. If you have a link, if you have a menu item, those are — you need to have an accessible name because you navigate through it with your screen reader and the screen reader needs to read something. If you don’t have an accessible name, there’s nothing to read and you know a screen reader user does not know what’s happening for example if you use an icon without any alternative text.

There are different ARIA components. So the first thing is roles and we talked about roles a little bit. We know something like div role main can mark up like the main region on the page. It’s better to use just the main element because you know it’s built in. It’s already an element that has those semantics. And those are completely equivalent. So you can just use that.

You can give a form a role search. So you can use it as a search form. There are role tooltips and alerts, those are not landmarks but they are like telling screen reader users — mainly screen reader users — what this element does.

And that’s probably a good thing to underline here at this point. ARIA is working mostly for screen reader users so if you don’t use a screen heard there’s nothing that tells you oh this div is a Tooltip or this form is a search form. There’s no interface for that.

So a lot of people are trying to augment their web applications and Websites using ARIA. Which is a good thing. But it only works for people who are using assistive technology that actually interprets those ARIA things so if you’re using ARIA and the assistive technology doesn’t understand it or the user doesn’t use it, then the problem is that you don’t get any result. ARIA does not help people who are not using ARIA. It seems pretty clear. But yeah, it needs to be underlined here. But there are not only roles in ARIA there are also states and properties.

So properties are basically things where you’ll say, oh, this thing — this element has something that gives it more meaning. So for example, you got an input with an ARIA described by so you’re connecting two things. An ARIA described by points at some text that basically is additional description for the input field.

But then there are states. So if you have a button, it can have an ARIA pressed attribute. That can be true or false. So that’s the state this button is in.

So you can have an ARIA pressed fails and then a user gets to it and it says this is a button not pressed then the user presses it meaning presses return or space and then your ARIA pressed would be true, in which case it gets read to the user as this button is pressed.

Which can be used for toggles and stuff.

But that’s the difference between a property — sorry for that.

Between a property and a state.

Yeah then there are things like ARIA hidden true which as I said hides stuff from screen readers which can be useful sometimes but more often than not, yeah, you shouldn’t use it.

Then there’s a tiny portion of ARIA container thingies that are live regions. So if you’re using ARIA live polite the text inside that div once it’s updated with JavaScript will be read out to screen readers. If you’re using assertive, the screen reader will under certain circumstances even stop what they are doing at that point and say oh you only have like one minute left in this transaction. Do you want to extend your time or something like that. So if it’s really important, then you can use assertive. But you always have to change the text inside of the div to do that.

I already talked a little bit about ARIA support. Yeah, when you’re using — there are some that use it the support is relatively good for a lot of those landmarks, regions, roles and states and properties. Usually that’s really okay. It also depends — because this is super complicated, the ARIA support not only depends on the screen reader but also on the browser and on the operating system so you get basically seven layers of fun with ARIA which is great. Heydon Pickering wrote an article called ARIA controls is poop which always amazes me because emojis are great and he went in and looked at the support for ARIA controls. And ARIA controls is a property that you can use for example on a button if that button controls another thing. And then in some screen readers, you could go back to that button. For example you got expand collapse and then you expand it and then when you’re inside the expand collapse you’re reading the text you say I actually want to close this and go to the next one, you can go with — with ARIA controls you could go back to that button, close it really easily. That was in 2016. And today Leonie Watson actually tweeted that JAWS which was the only screen reader really supporting ARIA controls has recently reduced support so the user has to enable it, which is a shame. Because it could be a useful thing to do. But it had so many cases that it didn’t get broad appeal.

And that can be a problem with a lot of stuff like in the details of the weeds of ARIA. This is the whole organizational tree of ARIA. And you can see — well, maybe you can see. But I described it, too. It’s basically like a big net of different boxes with different roles and attributes and they are pointing at each other because they are dependent on each other and it’s like crossing and really confusing and complicated because ARIA is really complicated. That’s full stop. And that makes it very complicated for web developers, as well.

And this is where it goes into the fun part where I tell you stories about really bad code that I’ve seen.

So this is one I’ve seen a link with the ID airline logo and the ARIA — the class logo and ARIA label airline name and then a non-breaking space in between. So that means a screen reader user would be totally fine with this. The screen reader would tab to it and it would read the airline name. But for an input user under different circumstances, the ARIA label wouldn’t be supported. So they couldn’t click on the home logo. That’s bad.

And we do have a way to do this, it’s using an image with an alternative text. Or you can do an svg with a title that could work. There are a lot of different ways to approach this.

Second one, I always, always think is interesting which is this one which is a navigation div. Oops. And it has three links in it basically going to slides. The href is JavaScript:void 0 which means when you click on this link do nothing because the action is prescribed in JavaScript behind the scenes. And it has a class navinactive and a role button because this is a clear button going to a slide so it’s not going somewhere. Then there’s a span class hidden text Slide 1 and this is useful but it’s very complicated and it also doesn’t convey to a screen reader user for example what the active slide is. There’s only a class that says nav inactive or nav active and that’s not too helpful.

What one could do is basically this, we have a nav with three buttons and like button elements and you have a nav element if that makes sense and then you have ARIA pressed false and an ARIA label Slide 1 if you hide the text anyway you know sometimes it’s okay to put it into the ARIA label and do something like I did here. And then, you know, only the one which is active has the ARIA pressed true this is relayed to a screen reader user and they can go to Slide 1 which is unpressed and then Slide 2 which is pressed.

That makes sense. But it goes even better if you put in an alternative text and an image with the alternative text if you’re using a graphic for those 1, 2, 3 buttons.

Another thing I’ve seen where a developer — and I know that because I’m a developer by heart we want to be very, very clever. You know, if someone looks at our code, we want them to go like, oh, that’s clever. That’s what happened here. And this is from a sortable table. And basically it’s a th with the content name and it has a tabindex equals 0 and role button and ARIA label sort column.

Now, I know what the developer is thinking, oh a user has to tab to this table header in order to sort the column and then the screen reader needs to know that this is a column they can sort so I put the ARIA label on it and it needs to be a button so I put a button on it. But what that does in combination is this is not a table heading anymore, a table header anymore. So this is not just a — now just a button and it has no connection to the other table data elements in that column.

So it basically broke the accessibility completely and if the role button wasn’t there everything in that label would be labeled sort column and as most columns would be probably columns to sort, that means everything would be labeled with sort column which makes no sense. Name is much better as a label there.

So actually this doesn’t happen. This is a tweet by Paul J. Adam where he basically had a similar thing happening. So it’s a button with the type button and the role button ARIA required false tabindex equals 0 and then just a 2. And he asks what the heck #facepalm #A11y. Which is a fair reaction I think. So try to unpack that. Going from — back to false. So 2 is not a really good accessible name. That should change. But it also depends on the context. But then you’ve got tabindex 0. A button is already reachable by keyboard. You don’t need a tabindex 0. So just remove it.

And ARIA required false. You can’t really require a button. I don’t know how that would work. I mean, you could theoretically say, this button must be pressed. But that’s something you would need to change in JavaScript or read throughout JavaScript so you couldn’t require it. That makes no sense.

Especially if it’s false anyway. Because buttons by default are not required. So you can get rid of this. Then it has a role button, which a button already has. So get rid of that. And then you basically have a button type button, which is useful if this button is used inside of a form. Because inside of a form a button by default submits that form and you don’t want that for all of your buttons so you can use type button. But outside of a form, you don’t need that.

Another thing that I’ve often seen is this pattern, it’s a span. And it’s for an icon. So there’s an icon using CSS background or icon fonts, something like that. Then it’s span ARIA equals true role image class icon. So you don’t need to put a role image on something that you immediately hide from screen reader users. The role image would make this announce as an image. Then you use ARIA hidden true to say oh please don’t announce this image. That makes little sense. So don’t do something like that. If you’re thinking about hidden true you can just in this case probably just remove the role image and the ARIA hidden true and then you’re good. Depending on your technique to put that icon in. Icon fonts can be tricky.

A really bad thing I stumbled on was this one. And this is from a big framework that used to have dialogue component. And when the dialogue was up, they wanted to prevent screen reader users from accessing everything inside of the bottom of the page because it’s a dialogue people should interact with that and they put ARIA hidden equals true on the body. Which seemed like a good idea at the time. But it really is not. Because that hides everything inside of the body. And as your dialogue is also inside of the body, that would also be hidden. You can’t selectively unhide stuff inside of an ARIA hidden field. That’s just not how this works. So they basically hid everything from screen reader users. It’s not for people who actually needed to use that slide or those slides. But yeah, it’s like a big misunderstanding. And so it’s really important to keep that in mind. If you put ARIA hidden true on a container, everything inside is just gone and dusted.

So sixth example. And that’s one I’ve found basically it’s — it was a spread in a textbook kind of application. And you had a lot of these links that opened stuff in your windows and had a title click here to view the video on tabindex minus 1 because they put the tabindex of the — or the taborder manually on stuff, which yeah you can do that. But it’s work. Avoid work, if possible.

Then you get a role button. And ARIA label external link.

So — and there was nothing inside of that link.

So what they didn’t think about was that ARIA label is overwriting the text of that link. So in the naming algorithm, it would have been okay to have the title and that would be read like click here to view the video. But using ARIA label overwrote that. So you had basically like ten external links on every page. And you didn’t know which video is that and where does it link to.

Also something I’ve seen using an ARIA live region on a carousel. That’s always a lot of fun. Just screen readers constantly getting disrupted because of the content changes. It makes it impossible to use. A lot of fun.

And a little bit of like HTML curiosity. If you’re using label for ID and you have an input with the same ID but it’s in a different case, upper case, lower case, those attributes are actually case sensitive. So this would break your stuff. So if you’re using ARIA label by or something, upper case and lower case, they matter for some obscure reasons. But they do. So just keeping that in mind.

There are two really good resources to read up on that whole thing, how to implement stuff properly. There is the authoring practices guide WAI-ARIA practices guide and on the left in the navigation you basically get grids. You get model dialogues, links, list box. The whole thing. And it will also tell you how you have to implement keyboard navigation on those more complex — on those more complex widgets. Because that can be very intricate. You know, what happens when you press the right arrow in a calendar grid when you are at the end of the week, where do you go from there? That’s identified.

And then there’s the using ARIA resource that is written by Steve Faulkner and David McDonald. The editors make a great job to basically lay out those rules, make sure that you can use ARIA really well with HTML and by the way, the team doing the authoring practices, also great, great people. Zoe and John and Gima are great people all around.

Conclusion for this whole thing, use landmarks. Use states and properties. If you can. They make sense to you.

If you’re using widget roles like the more complicated things that are in the ARIA Authoring Practices, just keep in mind that there’s a lot of keyboard work you have to do. A lot of things that depend on each other. It’s quite complicated. And to read up. And then also test it with browsers and screen readers and make sure that it actually works. Because sometimes, you know, there is like a small thing in there that doesn’t work. And then, yeah, it’s — it’s not fun if you put a lot of time into it and then you see that something is not supported.

One quick shoutout.

There is a workshop I will do in Berlin in November. It’s just (inaudible) and you can join with Accessibility Club. I linked that with my slides, as well. And I will talk more about funny things that other people do wrong so I don’t have to talk about things I do wrong.

Just kidding.

And that’s it. I’m Eric. And my Website is yatil.net and I’m @yatil everywhere else. And I’m open for questions.

>> MICHAEL BECK: All right. Yeah, if you have any questions, go ahead and throw those up in the chat or in the Q&A, if you’re so inclined.

Actually we do have somebody have — somebody had a hand open up but they just put it up. Oh there we go, attendees. Who has their hand up? Stuart Nelson. If you have a question there, Stuart, go ahead and throw it in the chat or in the Q&A — there we go. Hello, Stuart. I think he’s writing something.

While he’s writing that, I actually have a little curious question for you. What’s the yatil? (Chuckles).

>> ERIC EGGERT: People are always asking that and it’s — basically when I’ve been young, I had French class. And Yatil with three dashes y dash a dash t dash il, that basically means what is.

>> MICHAEL BECK: Ah . . .

>> ERIC EGGERT: And I found it funny that it has three dashes. And so I just took it on as my name. And when I stopped taking French classes, my French teacher said to me, this is a great day for the French language. So you know this is basically my French language. (Chuckles).

>> ERIC EGGERT: Relationship.

>> MICHAEL BECK: Fair enough. All right. Stuart asks with ARIA-required attributes, will the HTML required attribute on its own be sufficient?

>> ERIC EGGERT: Short answer yes. So the — basically the HTML required attribute does everything the ARIA required attribute does but it also does something more. It gives you automatic validation of your form. And that is useful in certain use cases. So it can — it has — it works a little bit differently. But if you have a required on your HTML element, it should be okay.

>> MICHAEL BECK: And he has a follow-up question do you have a favorite pattern for ensuring that form inline error messages are accessible?

>> ERIC EGGERT: It’s a little bit hard. Because it always depends on the form. Sometimes inline error messages don’t make a lot of sense like it makes more sense to like throw the user back and say, oh, there are several things. But sometimes they make sense.

I actually wrote or edited a tutorial on W3C.org. That has several things, W3C.org/tutorials. I would need to be able to spell that. (Chuckles).

>> ERIC EGGERT: And there is a forms one. That has error validating input on the left. And that has several different things.

And usually, you know, I usually use the standard HTML input fields. And then make sure that I use ARIA described by with the arrows.

>> MICHAEL BECK: Okay. Let’s see.

John asks, can you speak about if there is a need for elements to have both the same ID and name attributes being the same?

>> ERIC EGGERT: I don’t think there’s a need for that. It used to be that I think Internet Explorer 6 or 7 or so did not support jumping two names — jumping two IDs. So you would need to also give them the name. But I don’t think that modern browsers are doing that.

>> MICHAEL BECK: Would you recommend role equals text to help VoiceOver better output text that has multiple spans?

>> ERIC EGGERT: So two answers. (Chuckles).

>> ERIC EGGERT: I think it can help a lot to do that but on the other hand I don’t feel that this should be on developers. I think VoiceOver or any screen reader needs to do a better job to do this and work with native HTML. And role text is a non-standard attribute so I’m varied of it. If you have a certain use case where it is really distracting then, yes, use it but otherwise I would not usually use it.

>> MICHAEL BECK: Okay. Roger has a question that’s not ARIA related but varied form links can be always deemed bad and demand a change, is that true? Do you think?

>> ERIC EGGERT: Like, yeah, when there’s no href attribute like no proper href attribute then the question is, is this really a link? And usually it’s not. Because of course you can change the location in your browser with JavaScript and then, you know, then it would be a link. So yeah I usually would change it to a button but yeah not always. So the basic rule is if you go somewhere to another page, if there’s a reload, then use a link, even if you’re doing the change with JavaScript. If something happens on the page, then that’s a case for a button.

>> MICHAEL BECK: Okay. Karli asks can you tell me when you should use a widget versus a straight nav element?

>> ERIC EGGERT: Yes, I can. So if you have a web application which means something like Google Docs or something like that then you want to use menu and menu item. If you don’t have that, there is little reason to use it. Better use a navigation and just pointing back, there is a tutorial on that. (Chuckles).

>> ERIC EGGERT: You know, I’ve written about all of that. So you just —

>> MICHAEL BECK: Perfect. I will definitely have a link for that in the description for the YouTube video.

>> ERIC EGGERT: Yeah so yeah, I think for most people menu and menu item is overkill and it also changes the way you use it with the keyboard so that can throw keyboard users off.

>> MICHAEL BECK: Okay. We have a couple more questions and then we’ll wrap up. Richard has a question. He wants to revisit exhibit No. 2.

Would the ideal situation for that one just have the text instead of ARIA labels equals dot dot dot?

>> ERIC EGGERT: Yes.

>> MICHAEL BECK: And that would generally be better for accessibility and SEO do you think?

>> ERIC EGGERT: I don’t know a lot about SEO. Because my philosophy is search engines want to present stuff to users so if your code is user friendly it probably would be picked up for — from search engines, as well. The thing is if it’s a button it does not have any like big impact on your SEO I guess. But the thing where having Slide 1, Slide 2 inside of the button really shines is when you have voice input because a voice input user can immediately know what that is. So actually it would be good if the text would actually be visible.

>> MICHAEL BECK: Okay. Is native browser validation accessible enough or do we need to make it accessible by means of ARIA attributes for example only first non-valid entry is highlighted or announced?

>> ERIC EGGERT: I think it works pretty well almost always. If your user presses the submit button and there’s an error going through the first instance makes sense, setting that — or highlighting that input field, yeah, but the user — the browser should do the heavy lifting for you usually. I’m trying to break that as much as possible. (Chuckles).

>> MICHAEL BECK: Okay. And Stuart has a follow-up question. I know what the real answer is do you have a favorite automated accessibility testing tool? I know what the real answer is but he asked if you have tried AXPro.

>> ERIC EGGERT: I have to say that Tenon is my — (Chuckles).

>> ERIC EGGERT: No it’s — just kidding it’s a great tool I use every tool that’s out there on and off but I’m not much of a tool user actually so what I usually do is use bookmarklets that are written for mostly myself or I adapted. And there are a lot of good bookmarklets out there that just reveal stuff to me and then I do the heavy lifting manually that’s how I roll because I don’t trust no one except for Tenon obviously.

>> MICHAEL BECK: Obviously. (Chuckles).

>> MICHAEL BECK: All righty then. Well thank you very much, Eric. That was wonderful. That was a deep dive. I will say the whatchamacallit the contents fit definitely. So thank you, again, and thank you all so much for being with us today and I hope you’ll join us next time when Tenon’s own Karl Groves will be presenting on what? Who knows. We all know Karl has a whole lot to talk about just about everything and he hasn’t quite decided on the topic yet so it will be a bit of a surprise for us all. So on behalf of Eric and Clare, our captioner from ACS, thank you all for joining us and as always I hoped you learned something today. Have a wonderful day!

[Title: technica11y] [Title: Presenter – Eric Eggert @yatil] [Title: Moderator – Michael Beck @stilts121] [Title: Music – bensound.net] [Title: Captions – acscaptions.com]

Eric Eggert

About Eric Eggert

Eric Eggert is a Web Accessibility Specialist and works with Knowbility and the W3C’s Web Accessibility Initiative to make the Web a better, more inclusive, place.

As a web developer, he understands the needs of developers but also knows about the big picture: Management, design, user interface, and UX decisions that pave the way to accessible web sites and applications.

Data Verbalization

Transcript

[Intro music]

>> MICHAEL BECK: Welcome to technica11y! The webinar series dedicated to the technical challenges of making the web accessible. This month, our presenter is SVG and data visualization expert Doug Schepers.

>> MICHAEL BECK: Hello, everyone, and welcome to this September edition of technica11y. I’m Michael Beck, your host and moderator, and this month we have Doug Schepers with us, SVG expert and CEO of Fizz Studio.

>> DOUG SCHEPERS: Pretty much everything at Fizz Studio. (Chuckles).

>> MICHAEL BECK: Everything at Fizz Studio. So yeah, he’ll be discussing data verbalization today, making images and data visualizations accessible to everyone, which is something we haven’t touched on quite that deep yet, so Doug, is going to take his deep dive today and over to you, Doug!

>> DOUG SCHEPERS: Great. Thanks, Michael!

Okay. So, I want to start off with a little intro. Who am I? My name is Doug Schepers, obviously and I’ve been coding SVG and JavaScript since around 2000. I was doing other kind of programming before that, so I’ve been a programmer for a while. I worked at W3C for ten years and I was on the SVG working group WebApps. I started the Web Audio Working Group if you know what that is. I’m not technically an accessibility expert by training. I have the same sort of imposter syndrome that many of you probably feel when dealing with accessibility.

I am sort of a niche accessibility expert. I’m an expert in accessible data visualization. So, that’s a very tiny niche within a niche. I’m also the founder of Fizz Studio. We’re an accessible dataviz startup and I recently started a job at UNC, University of North Carolina at Chapel Hill, as a digital accessibility consultant. That’s sort of my side gig. So, thank you for having me here!

Let’s jump into accessible data visualization!

So, the first thing I want to talk about is colors. You may have heard of “web safe” or “colorblind safe” color palettes. There’s one that I’m particularly fond of and that is the Brewer Palette. This is done by someone named, oh, I can’t remember her name, but it is not Judy Brewer, if you know the W3C WCAG person. But, it is Dr. Brewer from, I think, Pennsylvania, and she came up with this set of colors for maps. And there’s three ways to think about these colors.

There’s discrete colors. Discrete colors are for categories. They are for individual items that are distinct from one another.

Then, there’s sequential. You would use this, for example, when you are trying to show that some things are related in some way, that there’s a series of things.

And, then, you have diverging. Diverging is sort of something where it’s going from one category to another category.

And, so, discrete means it’s quantitative. There’s no perceived order. Sequential means that these are perceived order, uniform steps.

And diverging means that these are two sequential colors.

Why am I talking about these kinds of things? One, the Brewer Palette has a lot of really great colorblind safe accessible options. And the second reason I’m talking about when you use these kinds of colors is because accessibility is not just about accessibility for blind people. It’s also accessibility for everyone, of course, but specifically people with cognitive disabilities. For example, by setting things up in a way that makes sense to people, that feels natural to people, you are setting yourself up for thinking about how to approach data visualization in the right way. In other words, how do you think about how people think about what you’re showing on the screen?

So, the rest of this talk is going to be about colors and which colors to use…no. Colors are an important part of data visualization but they are not the most important part, nor, in fact, do I think it’s the most interesting thing to talk about in data visualization. When you look at most products, unfortunately, when they say that their data visualizations are accessible, what they mean is you can choose colors that are good for people with colorblindness. Not to dismiss people with colorblindness, but, there are a lot of other issues that you need to think about when dealing with accessibility. So this is pretty much one of the few times I’ll be talking about color in this talk.

I want to talk a little bit about complexity. So, this is a beautiful example of data visualization.

It happens to be about the Internet. This is a map of the Internet. But,and I look at it, and it’s beautiful, but I really can’t extract any information from it. I can appreciate the aesthetics of it, but, I cannot really understand what’s going on here. So, you might have complexity like this. You might have a lot of complexity in your data.

This is another example of complexity. We have what is, frankly, not a very attractive, beautiful image to look at. And I also can’t get much out of this.

I’m not saying that people can’t learn to read graphs like this. They can. But, I am saying that for most people most of the time, whether you’re trying to explore data or whether you’re trying to explain data, you don’t want to introduce this kind of complexity in your charts because you are excluding the vast majority of people from being able to understand what they are looking at.

So, my big takeaway here is complexity is the enemy of clarity in terms of data visualization.

The big thing that you need to take away is think about your data visualizations as a poem, not as a novel. Make the most discrete, the smallest possible thing you can make in order to convey the idea that you are trying to convey.

That is going to serve everyone. It also happens that it will serve, for example, people who use a screen reader.

The first thing you need to think about when you’re thinking about making a data visualization accessible is what is the absolute minimum I need to convey to this person so that I don’t waste their time and waste their mental energy, waste their cognitive load. So, you really need to think about when you are making a data visualization accessible, what’s the first thing, what’s the most salient thing, that you can take away from that?

And, in general, that is, give them before you do anything else, give them sort of `alt` text, give them an introduction that is, for example, “North Carolina was the top state in this or that figure,” or, “This is a stock market chart, the trend is upward from this value from you know 50,000 to 100,000,” whatever it is.

Give them a one-sentence takeaway that they can approach to understand it from a cognitive perspective, from a screen reader perspective, and from there, they can decide if they want to drill down into the table of data or however else you’re presenting that data.

So, that’s the big takeaway there: reduce complexity whenever you can.

So, here is an example of an accessible chart. How is it accessible? Well, for one, it’s done in SVG, which is Scalable Vector Graphics, in case you don’t know SVG. You see it used a lot for things like icons or very simple images and you do see it used a lot in data visualization.

I don’t think that people really understand that SVG is like HTML in that you can completely control the document format, you can completely control aspects of the document to make it navigable in the same way that an HTML document is navigable. What do I mean by that? Well, for one thing, we could say, BOOM, right off the top, “There’s an accessible SVG chart.” Now, we don’t need to tell them how many elements there are in it, but you tell them immediately when a screen reader hits this SVG, it says, “Accessible SVG chart.” Then it points out there’s a x-axis; we are setting context. It says, “Here is the x-axis, the kinds of things we will be talking about, this is the independent axis.”

Then we have the y-axis. I’m going in order, starting at the top I’m saying, “This is a bar chart. This is the x-axis,” then I’m saying, “the y-axis,” and then, I let them walk through the individual data points: Saturday, 8 hours; Sunday, 6 hours; Monday, 4 hours; Tuesday, 12 hours. By using SVG, I’m actually able to let them drill into and tab through and get at all of the data in the same way they would be able to get at it through a table.

I want to talk about how do we exactly do we achieve this.

Partly, it is just through using tabindex, things like that. But, partly, we have these new standards coming out about ARIA. So, ARIA is about categorizing different kinds of controls. At Benetech, there’s an Accessible Data Visualization Task Force. That’s not actually part of ARIA, but there is a Task Force working on helping to inform the next generation of ARIA standards. There are some new ARIA roles within SVG: the Graphics Accessibility API Mappings in the ARIA graphics module. They have things like `graphics-document`, `graphics-object`, `graphics-symbol` and you can use these in your SVGs in order to make the screen reader understand what exactly the person is supposed to be looking at.

I want to talk a little bit about screen readers; not about screen readers themselves, but, about how the information gets from the browser into the screen reader. So you start off with a document, say, an HTML document. If you know about the DOM, the DOM is the Document Object Model. That’s what the browser sees in a document. And then it presents that directly to the user. And that’s a pretty straight-forward transformation. Document gets turned into a DOM, Document Object Model. And that’s presented into the browser. It’s a little bit more circuitous to use for a screen reader. For them, the DOM is converted into an Accessibility Tree; this is a subset of everything else that’s in the document.

So, going back to this image here, there’s a lot of things that we don’t talk about in this image. I don’t talk about the individual lines at the back that show sort of the tick mark lines that help a user visually track going from “8” over across the screen. We don’t mention those in ARIA because they aren’t useful to a screen reader. There’s a lot of elements here that we simply don’t have to mention. We don’t have to mention that there’s sort of a 3-D effect in this bar chart because that’s not information that’s adding to what the screen reader sees.

So, going back over here. We’ve got the document. We’ve got the DOM. And the Accessibility Tree is subset of the DOM that’s presented to the screen reader. After it goes into the accessibility tree, it goes into the operating system’s accessibility API, and then it goes to the screen reader, and, through the screen reader, it’s presented to the user.

So once you understand the flow of how the information gets there and understand how you can filter out pieces of information that are extraneous to the screen reader user, it’s a little bit — an analogy might be when you have an image that’s meaningful, you use `alt` text. When you have an image that’s not, meaning it’s just decorative, you can just say `alt=””`. It’s sort of like that. You highlight the things that need to be highlighted and you sort of hide away the things that are already extraneous.

Let’s step back and look at what is data visualization in the first place.

So, this is a fancy word for — or I say data visualization, I also say dataviz a lot — it’s jargon, a fancy word for charts and graphs and diagrams and maps. And a common metaphor in dataviz circles is, “Data visualizations are a story about data.” I don’t dispute that; it’s certainly true. It’s a story you’re telling people about the data you’re looking at, but I have a more functional metaphor and that’s, “Data visualizations are a user interface for data.”

And my goal in this talk is to get you to rethink what a data visualization is.

So, many people say that data visualizations — and I’ve heard this for years –that data visualizations aren’t accessible and can’t be accessible but in fact data visualization is accessibility technology.

I’ve popped up on the screen here a spreadsheet, an image of a spreadsheet, that shows the raw numbers for population for the four biggest countries in the world, Brazil, China, India, and the United States, or the most populous countries, rather. And I show that the years from 2000 to 2016. So, at this point, if any of you are able to see this image, I could ask you a question: “Which country of Brazil, China, India, and the United States, which of them has the highest rate, not the highest number of population, the highest rate of growth in population?”

And I could sit here and solicit answers and the fact is most of you would not be able to tell me right away. But, if I show you a line chart that shows the rates of population, you can see that China has the highest population. But, you can also see that India has a higher rate of growth because the angle of the line is steeper. And it’s very interesting: when I showed this presentation to a person with low vision, they couldn’t make heads or tails out of the table of data. But when I showed the line chart, they were able to immediately tell me that India had the fastest rate of growth. Now this was a mathematical person who knows how to read charts well.

But, the point is, instantaneously, you were able to take the data that, from a table view, is not very accessible and in a dataviz role, in a line chart, is actually much more accessible. It’s much easier to notice and think about patterns certain kinds of cognitive disabilities and low vision. And it helps really reduce effort and it helps you to catch attention in a data-flooded world. What it’s doing is it’s creating a functional model of the data in the minds of the audience and there’s nothing inherently visual about that.

So, Ben Shneiderman is a pioneer in what was called HCI at the time; we would probably now call it UX. Human-computer Interaction has sort of become User Experience and he’s also a dataviz pioneer.

And he said, “The purpose of visualization is insight, not pictures.”

That’s really where we’re going here: the purpose of visualization is not pictures.

So, the immediate question might be, “Why is it visual then, why do we do things visually?” Well, because the visual channel is very broad. It’s very fast: ten million bits per second. Thirty to sixty percent of the brain is dedicated to visual processing. This corresponds to our fight or flight reflex. If you see something moving quickly towards you, you immediately have a reaction. It’s the difference of between, “Seeing dinner or being dinner,” is the expression.

In comparison touch and hearing have a much lower bandwidth than visual information does.

Vision is also multichannel. I won’t go into all of the details here, but there’s something called saccade where your eye is moving around; you’re constantly pulling in multiple pieces of information and correlating them in your mind. This helps us detect, match, and make sense of patterns and we use these capabilities, these visual capabilities, to convey things in a way that’s faster than we could do through serial access. So. it’s parallel processing with vision and serial access when we’re, for example, listening to numbers in a table.

There’s also something called the Pictorial Superiority Effect.

And again, the breakdown of the senses : I’ve got a little pie chart made out of a brain with allocations of the senses. The allocations are not exact because we don’t really know how exactly the brain processes different sensory information, but, generally, between a half and three-quarters of the brain of our cognitive capacity is dedicated to visual processing.

The Pictorial Superiority Effect affects memory retention. So, if I showed you this whole slide deck with just text, no images, you would retain about ten percent of that information after three days. However, if I add images that sort of help you frame the ideas in your mind, you will retain after, three days, sixty percent, or sixty-five percent, actually, of that information.

So the curious thing is this effect increases with age. You think little kids: “Oh, little kids are very visual. They see pictures and things.” Actually, once we reach a certain threshold, the older we get, I’m a 50-year-old, visuals become more and more important to me and more and more effective on me. And this increases with age. If you’re interested in reading more about that there’s a book called, “Brain Rules” by John Medina, that talks about that a little bit more.

So, I mentioned cognitive load earlier. What is cognitive load? Actually cognitive load can be broken down into a few different categories. There are different types of cognitive load. Intrinsic cognitive load is the bare minimum you need in order to understand an idea. And then there’s a bunch of extraneous cognitive load. These are all the things surrounding the idea that are actually distractions from you understanding the core idea. This extraneous cognitive load, it’s basically clutter. And there is some redundancy, though. Redundancy is actually helpful. Saying things twice in different ways, or multiple times in different ways, can actually reinforce the main point so redundancy actually has a function.

When you combine the intrinsic and the necessary parts of the extraneous clutter, we get what’s called Germane Cognitive Load. This is stuff that people feel is relevant. It sets context. It helps people establish what they are trying to understand. Germane cognitive load is the brain looking for patterns within the clutter to develop context.

Serial tasks, that is, say, tasks where you’re doing one thing at a time as opposed to doing multiple things at the same time, cost more cognitive load than parallel tasks. And this is why, for cognitive accessibility, visualizations are actually often very effective. It does introduce some challenges, though, and we’re going to explore that.

I’m going to be talking a little bit more about the brain and how it works, so, I hope you’ll bear with me, because I think it’s germane to you understanding how to think about accessible data visualizations. There’s something called the Preattentive Attributes. The Preattentive Attributes, these are features that are processed automatically by our visual memory or iconic memory. These include color, form, position, and movement. And I’ll show you some examples of each of these.

Color: it’s pretty obvious. There’s things called hue, saturation and lightness; HSL for the designers among you. And each of these sets one color apart from other things in the same set.

Another feature is called Texture. When we see something has a different texture than other things, our eye immediately jumps on that.

Then there’s things that comprise form, like orientation, alignment, co-linearity, length, shape, size, curvature, width, added marks, intersections, spatial grouping or numerosity, that being our inherent ability to see roughly how many of a thing there are that usually tops off around four or five, is when numerosity starts dropping off but up until that point, BOOM! Our brain is actually counting those things immediately.

So, then under Position we have things like 2-D position, stereoscopic depth, concavity, or convexity, and under Movement we have size change, direction and velocity, rotation, and flickering. I’ll take these animations off because the movement ones are so distracting to me as somebody with ADHD, I can’t have them on the screen when I’m trying to concentrate and do a presentation, and I think it would also distract some of you.

So several of these Preattentive Attributes, these automatic attributes, are ideal for quantitative mapping and others are good for qualitative mapping. In other words, some of them are really great for showing numbers and others are great for showing categories. The ones that are great for numerical or quantitative mapping are length and you can see three little lines and one is taller than the other. Immediately, you realize, “Oh! That’s how we use a bar chart.” The 2D position (this is like a scatter plot) and size.

These are the three that are really great for quantitative mapping and the rest of these you should consider as things for showing categories.

To go along with these Preattentive Attributes, there’s something called the Gestalt principles. And this is one level up. It’s a higher level pattern recognition that organizes all of those different little things that our eyes and brains immediately grab and it organizes these discrete elements into a unified whole. So, some of these are Proximity: when things are close to one another , you assume that they are a group and I have three examples. Two examples where you see Proximity, you see things as a group and then another one where there’s no clear grouping. That things are a little more scattered.

Then there’s something called Enclosure : when we see things that are wrapped in another element, wrapped in another thing, we tend to think they are somehow groups.

Connection: if there’s a line drawn between things, we think that somehow those things are connected. Our brains immediately think that.

Similarity: if I have here some red boxes and some blue boxes, they are not clustered together, but you think, “The blue ones are similar to one another and red ones are similar, they are distinct from one another.” Maybe so, maybe not, but our brains definitely see those connections. As I’m showing you these, I invite you to try to look at these things and think that these items I’m showing you are in fact not connected to one another and it’s actually difficult for you to do. It’s difficult for me to do!

Closure: this is an interesting one. I’m showing you a series of lines that seems to show the outline of a box. There are several breaks in it, but, our brains fill it in and it looks to us like a rectangle. It’s not a rectangle, it’s a series of three different angled lines, but they look like a rectangle.

And Continuity. Continuity is interesting. I have two bars here. One bar in front of the other. A dark blue bar and a light blue bar in front of it, but when I mouse over it, I can show you that in fact it’s not two bars. In fact, it’s three bars. It’s just that because one of the bars is crossing over, it makes the one look in the back look like it is a continuous bar and even when you see that it’s an illusion, when I dispel the illusion, you still see it when I go back to it.

And then, finally, there’s Common Fate. Common fate is one things seem to be moving together, you assume that they are somehow connected.

These are processed after your sense memory but they are still preconscious and they are processed in parallel with one another. Like Preattentive Attributes, there’s little to no increase in the cognitive load.

This is a really key concept here: the Fast and Slow Mind. The Fast Mind is called System 1. It’s fast, it’s automatic, it’s frequent, it’s emotional, stereotypic, it’s unconscious. This is where immediate reactions — this is where racism comes from. This is where very positive — our reactions to attractive people come from. These are immediate reactions that we don’t have much control over. Preattentive Attributes and Gestalt principles fall under this.

Then there’s the System 2, the slow, effortful, infrequent, logical, calculating, conscious part of the mind. This is when we’re looking at dataviz, the first thing that happens is we’ve got this preattentive automatic assumption about relationships. But then after that, we can start thinking about meaning. So, with dataviz the first thing we do is convey the properties of the data. And the second thing we do, that takes more effort, is we explore and we think about that data. But, when we only give somebody serial access to something, in other words we substitute a table for a data visualization, what are we doing? We are taking that serial access and we’re forcing them to use it for both conveying the properties of the data and to explore and think about the data. We’re increasing their cognitive load. So it’s cognitively expensive, it’s mentally taxing and it slows task performance.

We really want to try to avoid that in our data visualizations. This is why I keep saying, “Give them the gist.” Give them the ability to quickly assess how deeply they want to dig into something. This also applies to a table of data. Provide a summary for the table of data that gives the key takeaway. This is going to help everybody. So what we need to do is we need to reduce the speed and effort needed to accomplish tasks in a non-visual way. In other words, when we’re making a data visualization, we also need to think about how it’s handled otherwise. So, in other words, in a non-visual way.

We have different kinds of sensory memory. And when we see a data visualization, it goes into our — sort of our visual — our sensory memory. Then it goes into our working memory, then our short-term memory, and then to our long-term memory. And at every point, some information is being filtered out. The benefits of a data visualization, that it effectively acts as part of our brain, it acts as an external memory register. We can immediately access that information very quickly going back and forth between what our brain is able to hold in at any one time and what we can see. And so what we really want to try to do is we want to try to emulate that kind of fast control with non-visual means, as well.

There’s something called Affordance. Affordance is how you expose information or expose some functionality and also immediately show how to use that thing. So, “Affordance and Equivalence,” is not just a long-lost Jane Austen novel; this is an idea where we need to take each feature of the chart that includes an affordance and a set of tasks that that affordance is geared towards and we need to make an equivalent experience for someone who has a different way of accessing that information.

One way we can think about doing this is to consider a data visualization as a document. So we have a title. We have where it came from. We have an introduction. We have a body. The introduction in the case of a bar chart, for example, are: the axes, the x-axis, the y-axis, I showed this before; we have the body, which is sort of the data itself; and then the conclusion. And the conclusion in a document is a paragraph. But the conclusion in data visualization is the actual insight that the reader has gained and the decisions that they have been able to make based on that data.

You want to think about document order when you’re making a data visualization. You want to think about what order the person is navigating in order to get to different parts of your document using, for example, `tabindex`.

This idea of adding information into your data visualizations, not just thinking about them visually, is something I call, “deep graphics,” and deep graphics is basically when the graphic has more metadata to it that adds context and adds for example links to data sources and other things.

I think the final thing I want to talk about around this compositional view of data visualization is exposing each landmark in a sequence to provide context. So here we have the title of a document, of a data visualization. In this case it’s “Snowfall by Decade in Columbia, Missouri from 1971 to 2010.” And then we have the x-axis which is the range of years. So 1971 to 1980, ’81 to ’90, ’91 to 2000, 2000 to 2010. Then, snowfall in inches on the y-axis. So, we’re setting context at each point. And then we’re showing the data. So we have three bars. You can see that these bars are decreasing. And the key here is we mark all of those up in a way that a screen reader can actually understand. We have labels on them. And we provide access to each individual data item, the values. But, then we also say things like, “We can pull out the high. We can pull out the low. We can pull out the range. Give them the total.

Tell them maybe the mean.”

Here is a real key point, the trend line. You can tell them (I told you as I was showing you the individual bars), “These go down, this is a downward trend.” And telling them right off the top of the bat saves them from having to try to deduct that themselves. So by preprocessing what your point is, by presenting your point at the beginning, you actually set them up to understand how they can drill through the data and derive what they need.

Finally I’m just going to say that my functional metaphor, I hope I’ve shown you what I mean by this: data visualizations are an interface for data. Different types of data visualizations are optimized for different tasks like comparison to whole comparison to other data points, trends over time, breakdowns of categories, connections between items, navigation of focus and I just want you to understand that when you think about data visualization you should be thinking about all of these things.

So, the mission I have at Fizz Studio is to make implicit interactions into explicit actions that will give the power to question and to answer to everybody.

So, there are a number of libraries and tools that you can use to make data visualizations accessible. You’re going to be using a tool to make your data visualizations. You’re probably not going to draw them by hand. Just make sure to choose a library that actually supplies the data in a way that’s actually accessible.

And a final thing I want to mention: there are various levels of data visualization accessibility. The first level is just generic `alt` text. Well, actually, the first level is not having any kind of accessibility at all. So that’s base level; let’s go beyond that.

You can provide generic `alt` text. The next level up, provide detailed summary in `alt` text. So, show market trends, the highest value, et cetera.

Then, the next step up, provide hidden content that is a table with the same information. And the next step up from that is actually to embed that information directly in the chart so that it travels with the chart and they are in the same context. And the last bit is basically: think about it from a task-oriented perspective where you’re giving them context for each choice that they are being meant to make.

And I think I’m going to end it there. If you want to get in touch, we have our alpha release of our software that is accessible. And I think I’m going to stop there in order to make space for some questions.

>> MICHAEL BECK: All right, you actually answered someone right before you went into the `alt` text, David Annen had asked, “How should a caption look like on a typical dataviz?” and right on cue, you went into discussing the data accessibility specifics. So, if you want to go into that more, that would be great.

>> DOUG SCHEPERS: Sure. The unacceptable level is not telling them that there’s a database on the page at all. Right? Using `alt=””`.

The next level up is telling them that there is a bar chart. But telling somebody that there’s a bar chart on the page is sort of like telling somebody a joke and not telling them the punchline. Most pages that have a chart on them, many of them, that’s the main thing.

The main point of that page is to convey that information. And if you made it inaccessible, just tell them, “There’s a chart here,” you’re basically providing them nothing. So don’t do that.

What you should do is, for example, say things in the `alt` text like, “Line chart showing market trends with a downward trend over the last year,” or, “Bar chart of costs with 12 bars. The highest value is 1500.”

Then, you might actually have a chart where you cannot make an accessible version of that chart. Somebody else gave you this jpg or PNG or whatever of a chart and your task is to make that clear to somebody. Well that’s how you do it. You do it through `alt` text.

However, if you are able to get access to the data, you can do other things like provide a table to them with the same information. But this doesn’t mean that you shouldn’t have the `alt` text. This doesn’t mean that you shouldn’t have the summary. You should. But if I’m looking at a chart and the highest value is 1500 and it’s for North Carolina. That’s great that North Carolina is the highest value, but, I might want to find out, because I’m from Missouri originally, I might want to find out what the number is for Missouri. So, if they have that information available to a sighted user, you should provide that information to a screen reader, as well. In other words, one way you can do that is by having say a hidden table. A better way because tables and dataviz can often get out of sync especially when one thing is hidden, I think we all know that problem of the accessibility ghetto where there’s one page over on the side or some piece of information that’s hidden that’s only updated infrequently, it’s really much better to have the data embedded into the image itself, into the SVG for example itself.

So, let them drill into that. And what my software does is it let’s them really drill into relationships and things like that. But, at the bare minimum, I would say give them very good `alt` text. Then that really says what is the point of this chart, not just, “This is a bar chart.”

And then go up in exposing more data to them as you can. Does that make sense?

>> MICHAEL BECK: Yeah, that makes complete sense. I hope that little deeper dive was good for David. We have an anonymous attendee that says, “When you use SVG how do you make them accessible?” and I believe you answered that. That’s just part of creating an SVG itself, you can do that.

>> DOUG SCHEPERS: Yeah, so each pie slice in a pie, each individual pie slice, is its own element just like each individual paragraph in an essay is its own `<p>` tag. So each of those individual pie slices is a path and you can add the metadata in there using a `title` element in SVG. You can also use ARIA, `ARIA labeledby` for the same purpose. And you can basically add the text version of that directly into the chart. You can say, “Pie slice 1; value 30,” in the title. “Thirty. The next one is 25.” Whatever. So, you can add the data directly in there. And just make sure you have it in the correct order so that as they are tabbing through, they are seeing it in the same order that everyone else is seeing.

>> MICHAEL BECK: Okay. Any thoughts or considerations on animated or time-based data visualizations?

>> DOUG SCHEPERS: Oh, that’s something I’ve thought actually a lot about. One of the things — immediately — I try to think of things in terms of the challenges and opportunities. The challenge for animation is that you might be excluding some people from understanding some things. The opportunity is that animation is actually a really effective way of drawing somebody’s attention to a particular piece. So, with animation, what I try to do is I use animation in order to draw someone’s focus to a particular thing. But if I’m drawing someone’s attention to one bar, for example, well obviously things like flashing, flickering, et cetera, you need to be mindful of frame rates, animation should be slow and discrete. They should not be constant. They should be time limited because if they are constant, it’s going to be distracting to someone. If they are very frequent, if they are very fast, you risk giving somebody seizures; that’s not a good risk to take. But if you use a pleasant, I’ll say, animation, when you’re doing that pleasant animation, maybe use `ARIA-live` to say, “I’m drawing your attention to this thing.” So, don’t just use one medium. Don’t just use animation. Also say `ARIA-live` and then draw, maybe say, highlighting, “New York 3.5 billion” or whatever it is. Does that make sense?

>> MICHAEL BECK: Uh-huh. It definitely makes sense to me. Let’s see, what else do we have? How would you approach data visualization of say a geographical map?

>> DOUG SCHEPERS: Oh, right, that’s actually something I’ve thought a lot about. Maps are interesting because we think of a map as sort of a single thing but, in fact, there are lots of different kinds of maps and this gets back to my point about it being a UI for data. What is the function that you’re trying to use this map for? Is this a navigation map where you’re trying to help somebody navigate a particular path? Is it something that’s trying to show the relationship between different items? Or is it something like a choropleth?

A choropleth literally means “many places.” It’s a terrible name for a data visualization that was coined in the 19th Century. But we are familiar with these things. I mean, the “red-blue” map or “red-blue-purple” map that you might see in election results. I call them theme maps or color maps. So the function of one of those is not about navigation it’s not about showing necessarily the relationship, the physical distance between one area or another. In fact it’s just a list of individual items that are categorized in a certain way. You know, did they vote mostly Democratic or did they vote mostly Republican or were the votes very mixed? In that case, you can actually effectively have a map in which each of those different items is available. A person can tab through or they can jump to an individual state, for example, and find out the answer for that. Effectively, just think of it as a list that also has a visual component.

So, again, with the list, it’s a long list of things and doesn’t give the overall context so what I would do is I would provide a summary in text that says, “The number of states that voted blue, the number of states that voted red, the number of states that voted purple.” You don’t usually see the purple, but I try to point it out, but you get the point. Tell them multiple ways. That’s that redundancy I talked about, give them multiple ways to consume the information, either discrete elements or as an overall summary.

>> MICHAEL BECK: Okay. You answered Isabella’s question perfectly. She found it really helpful.

>> DOUG SCHEPERS: Oh, well that’s okay.

>> MICHAEL BECK: Excellent. (Chuckles).

All right. Well, that concludes this webisode of technica11y and that also concludes Season 1 of technica11y!

>> DOUG SCHEPERS: You didn’t tell me I was the season closer.

>> MICHAEL BECK: Yeah, you’re the closer, man. (Chuckles).

>> DOUG SCHEPERS: I would have put a cliffhanger in there.

>> MICHAEL BECK: Well, people are clamoring for a Part 2.

>> DOUG SCHEPERS: Okay.

>> MICHAEL BECK: So you can go even deeper. (Chuckles).

>> MICHAEL BECK: But we’ll have to keep that in mind for next year. Yeah, so thank you to everyone who has joined us over the past year, especially those who were here for every webisode; there are a few of you!

And speaking of next season, we’ll be kicking that off with Knowbility’s Eric Eggert. The title of his presentation is “ARIA Serious? The good and Mostly Bad of ARIA” or, “a-REE-ah” or however you pronounce it. Great title and great topic. We haven’t really touched on that yet. And so, thanks again to Doug for that fascinating — that was, whew, that gave me a lot to think about and some of the stuff I’m working on myself outside of this and Tenon. And thank you to Clare from ACS for the captions. And of course to all of you for attending. Have a great day. And we will see you all next month!

Doug Schepers

About Doug Schepers

Doug is the founder of Fizz Studio, a startup specializing in making accessible data visualization software. Previously, Doug defined Web technologies and standards at W3C for a decade, where he launched or worked on fundamental projects such as SVG (and the Accessible SVG Task Force), WebApps, Web Audio API, Touch Events and Pointer Events, Web Annotations, and many other technologies, as well as starting the W3C developer relations program. Working with the accessibility community at W3C inspired Doug to found Fizz Studio, based in Chapel Hill, NC.

What makes an accessible card?

Transcript

[Intro music]

>> MICHAEL BECK: Welcome to technica11y, the webinar series dedicated to the technical challenges of making the web accessible. This month our presenter is Rian Rietveld, senior accessibility consultant at Level Level.

>> MICHAEL BECK: Ladies and gentlemen and all variations thereupon, welcome to technica11y! I am, of course, Michael Beck, the operations manager here at Tenon. And it is fantastic to have you here today! We have with us one of the most anticipated presenters of this year, Rian Rietveld. Hello, Rian!

>> RIAN RIETVELD: Hello!

>> MICHAEL BECK: Welcome to Technica11y. Today Rian will be discussing the considerations for making an accessible and flexible card pattern. So without further ado, take it away!

>> RIAN RIETVELD: Okay. Thank you. I will start my slide show now. What makes an accessible card? I’m not having all the answers. I just want to discuss some options and show some major things I see going wrong in the reviews I do.

So, first of all, I’m already introduced but this is the required slide. My name is Rian Rietveld. I work as a senior accessibility consultant with Level Level. And these slides are on SlideShare.net/RianRietveld. So, I just published them if you want to look at them. I think there will be a blog post with all of this information later on, but, not yet.

So, what is a card? A card is a teaser on a webpage. Basically, a component with a link to other content. It wants to tease you to click the content and read that and they come in many forms and shapes. This is, for example, from the Huffington Post. You have an image and the title of the post you’re linking to, an excerpt, a description, and who wrote it. And there’s different layouts. The first row you see two cards and then the row below three cards.

And this is another card. These are search results by Google. If you search for Rutger Hauer, one of my favorite actors that died recently, you see there are top stories with an image with the title of the post it’s linking to, the URL, and the days ago that it was published. So, there are many forms.

This is one from our own website, from our Level Level website. It has the category, the post title, and the “Read the article” link.

In this talk, I refer to “post,” but it can be a page, it can be any content you want to link to, but I just refer to “post” for convenience.

A card can contain many different elements.

Well, at least, it should have a link to the post and a title of the post: that’s the bare minimum.

But, also what I came across: an excerpt; tailor written teaser content or just the first few lines of the post; an extra “read more link” to the content; a featured image; an image slider; video embed; an indicator if the content is the post of a video; or the possibility to like and share the post on social media in the card itself. That last one I think is very ridiculous, but I see it many times.

And then there’s also the metadata belonging to the post: publishing date; last modification date; author name; maybe there are multiple authors, so there are multiple names; the author avatar; the author’s job title; a link to the author’s archive page; links to related categories and tags; the number of comments; the number of likes and shares on social media. There’s a ton of things!

How much info does it take to make you click? I wonder.

Is this all necessary? It’s not really an accessibility issue, it’s more usability, UX design. What does it need to make your audience click?

And that can be different things. For example, this is a PlayStation blog and they mention the featured image, the title, and author, also the job title of the author of the review (and this is about games!), an excerpt, the date published, how many likes and how many reviews. Maybe this is important for the audience that they know: “Okay, there are so many people commented on that. That must be a really interesting piece to read. Many people liked it.” So, this can be useful information.

This is USA Today and they have the featured image, the blog title, the post title, and the date it’s published. They made another decision. These are not accessibility issues, but I think you have to reconsider what actually you want for information to put on the blog post to put on a card to tease people to click. Maybe sometimes it’s too much.

But, what are the accessibility issues I encounter? And I want to discuss with you.

First of all, in every review I do, I see broken semantics: HTML that’s wrong, that’s not rightly used; a flat DOM, like everything is `<div>` and `<span>`. It’s very convenient for the developer, but it’s hell for someone who, for example, has a screen reader or uses only a keyboard.

HTML5 is really the basic of the web. It’s not only `<div>` and `<span>`. So, broken semantics is what I see a lot.

What is important for accessibility? The order of things: how are things presented in the code? The heading structure: what headings do you give and how do you use them? The link text quality: what do you put inside the link? And the taborder: if you tab through a page, if you cannot use a mouse, you can use the tab key to go from focusable element to focusable element. And if the taborder is a mess, it’s very hard to make sense of where you are.

So, these are the four things I want to address and I’ll start with, what’s the order in the DOM? The DOM means “Document Object Model” and we all see that if we inspect the code.

For example, this is a page of Reddit and if you inspect the code, you see the generated HTML: this is not what you write but what’s generated by the browser, so, all of the JavaScript, all of the CSS. is actually put in place here. So, this is actually what every browser works with, and what all the screen readers work with, and all of the assistive technology that looks at your website, if not to interact with your website, reads. So, the DOM must make sense. And then, it’s very important that the order of things is logical because if a screen reader cannot see a website, it’s read outloud to them. So you actually have to read top to bottom to make sense of stuff. And if the order of what’s represented isn’t right, it’s very difficult to make sense of it.

This is a very simple example. For example, you have here a card and when you can see, you see, actually, there are two different cards. It’s very clear. But, if you cannot see and you have it read out to you, you think, “Okay, photo of the week. That’s the heading,” and you read from there. And then you encounter the writer, the author and then another header. Then, you can get it wrong.

Someone with a screen reader can jump from heading to heading and then you expect, “If I go to heading, everything that belongs to the card is below that heading.” And here, the author is above the heading. So, when you encounter the next heading, you have a different author, the author that’s above the next heading. So this is very confusing for screen reader users. They get the wrong information out of this.

Headings should represent the content below and not what’s above it because that’s not really logical. Headings also reflect the page organization.

This is a very good example. This is from technica11y.

You have latest episodes. That’s probably a heading. And then, you have the heading of the and the link to the post: “Designing and coding for low vision.” And then by Mallory van Achterberg, recorded at, and then the excerpt, and then the next heading for the next card. So, this is a logical order, so people who are blind can actually make sense of who is the author here.

You have to use your heading right. This is an example from Reddit, and here the heading is actually describing the content of the whole card. This is actually used as an excerpt. This is a very large heading: “The official licensed browser game of Game of Thrones has launched! Millions of fans have put themselves into the battlefield! What about you?” That’s one heading. That’s not really describing what is the content below, that’s really describing the whole content. That’s a lot of text for someone who uses a screen reader to comprehend.

Also in this card, when it’s published, it’s above the title. So, maybe that’s content someone with a screen reader can get wrong then because the order isn’t right.

Then there’s another thing and that’s up to debate. So, I would like to hear your suggestions if you have one. Don’t use a heading when you have no content, use only a link. What do I mean with that? This is from a Dutch website, Volkskrant. And on the right, there is a list of posts and it’s only the post title. Above that, there’s a category: News, and then there are several post titles.

Don’t make headings out of this. Because then you get a list of headings with no content below.

This can be very difficult if you have a Content Management System. If you have, for example, a mix of excerpts and no excerpts, if you give the content manager the option to add an excerpt or not an excerpt. So, maybe, for some posts, you only have a heading and for other posts you have a heading and an excerpt. If you choose where, “I have not an excerpt,” then it shouldn’t be a heading, then it’s all [unclear], the heading structure will be all mixed up. So, this is really something to debate. How should we do this? And it’s bad to have here, for example, only headings.

I think no screen reader user will die from this; it may be a bit mixed up if you have headings only. It’s something to debate. I don’t know the answer for this. Because you give the content manager the power to add an excerpt. So, be pragmatic.

That’s my solution.

Okay. Other about headings is, “Use a meaningful heading level.” What do I mean with that?

Headings are the backbone of your content. And don’t mess it up. This is one of the Volkskrant, this is a Dutch website. If you are the developer of this website, I will give you some free consultancy how to fix this.

But, what you see here is the headings on the left and there is no H1. There is H4 for the main article. And then there is H4 for the news category. And there are a lot of empty H4s and a H3; it’s just a big mess. You cannot really make out the structure out of this. Here headings are chosen for the size or just left empty because maybe in another view there’s a heading visible. This is really sloppy code.

This is the headings map from the BBC. The headings map is a really cool Firefox extension; it’s an add-on. So, this is what I’m using here to show the headings map. Here you have H1 is BBC homepage, and H2, “Welcome to the BBC,” and then you see the biggest topics of the day. And they are H3s and those are the blog posts. Then another H2, that’s the main category, “News,” and then H3s there are the news items under the news.

This is really a good structure. Here you can see how the page is put together. That’s not only very convenient for blind people but also for search engines. They can see this is the structure of the page. That’s about headings.

Link text quality. Link text must be meaningful and clear. Right. We all know that, don’t we? This is from the Mirror website, a UK website. Screen readers can call a list of headings, but can also call a list of links. And on the left you see a featured image of someone injecting herself with something to lose weight, I guess. And then, there’s the link to the category, “Obesity.” And then, there’s the blog post title: “Miracle flab jab branded ‘wonder weight-loss treatment’ yada yada yada,” and below that, there’s an icon of, I think, comments: it’s like a little balloon or something and then after that there’s the number 12.

If you look at the link list, the first one is the link on featured image and that’s actually the URL it’s linking to, I think.

Then “Obesity” is a link to the category. You can see that. Below that, there’s a link really describing the content it’s linking to. Then, you’ve got a link: a question mark 12. That means VoiceOver doesn’t know what that icon is.

So, these are the links of the featured image and the link for the comments are really not understandable. They should be very clear.

For example, you can use an ARIA label on the link to the comments and you can say, “Amount of comments: 12” or something. You can overrule that. But what do we do with the image?

Linking an image. What should the alt text be? And this is where I get the most questions about with all of the designers and, especially, the developers, from the developers. And I don’t know why, but, it’s a heated discussion. I posted this once on Twitter what I thought to do and I got a lot of comments from people who didn’t agree. So, I want to make one thing clear. WCAG says, “All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.” It doesn’t say you have to describe what the image is. You have to say what the purpose of the image is. And this is Level A. Single A.

So, I wanted to let you know in CodePen what I mean, what I think is good practice. and what the fight is about with the frontend developers.

Okay. Linked images if you have no alt attribute. So, you have the link, and there’s an image, and there’s no alt attribute: how does that sound? I will fire up VoiceOver.

>> VOICEOVER: That sound VoiceOver on Safari, VoiceOver window.

>> RIAN RIETVELD: Okay.

>> VOICEOVER: Comma sound VoiceOver Safari. VoiceOver window cover Rian Rietveld okay. Comma sound voice on Safari.

>> RIAN RIETVELD: I think it’s —

>> VOICEOVER: One single window comma sound VoiceOver sound Safari comma Rian Rietveld.

>> RIAN RIETVELD: I think something is interfering, the Zoom is interfering.

>> VOICEOVER: Sarah comma Rian Rietveld.

>> RIAN RIETVELD: I will stop this and I will say what the screen reader announces and you can practice this at home. If you have no alt attribute, then the screen reader thinks, “Okay, this is the content, the image is the content,” and because there’s no alt attribute, the image or the URL of the image is announced. So, what the screen reader announces if you give focus to this image, this linked image, it says, “Home flowers dot jpg.” If you have an empty alt attribute, then there’s no content at all in the image, in the link, I’m sorry. There’s no content on the link so what the screen reader does, it reads the URL.

So, if the link just says that it’s a link and it goes to HTTPS://RianRietveld.com. That’s not very convenient for screen reader users because it just gives the URL instead of what the link is going to.

If you describe what the image is about in the link, for example, you give it the alt [text], “flowers,” then the screen reader will see, “Okay the link text is ‘flowers,’ so the link text will be ‘flowers.'”

So, that’s not really information about where you’re linking to: you’re not linking to flowers. You’re linking to the website of, my website, Rian’s website.

So, if I use this alt attribute, the link mentioned in the link is “Rian’s website.” Then, the screen reader will see that as the link text. So, the link name will be announced as, “Rian’s website.” And most people don’t want that because they say, “That’s wrong.” But, this is how it works.

This is really the content: the text that’s inside the link, the accessible name, will be the alternative text. So this will be announced as, “Link: Rian’s website.”

If you are so upset by losing something else as an alt than describing the image, you can just use an ARIA label. The ARIA label you can override. You put it on the link. And you can overwrite what’s inside the link. This will announce exactly the same if you have an alt as “Rian’s website” or you have on the image or you have a link and you have an ARIA label on the link. The ARIA label will completely override what’s here inside, so this will not be announced.

So these are two options you have.

The other ones are wrong. These are just the only right ones.

I prefer not using ARIA if I cannot. So, I prefer using the alt text and having the link destination site.

Right.

This was my concern and I hope I made it a bit clear. If you have a screen reader, the links in the CodePen can be in the slide [also below in the description].

Then the other one: be very clear about hover and focus styles. If you tab through a card, you must really see where you are. If you hover over a card, you must really see what’s clickable.

Don’t assume that people will really know what a card is. I have one example, a hover example, that went wrong.

Okay. This is a website we created, our company created a few weeks ago. It’s about a caterpillar that’s only on oak trees and it’s really bad for your health. It gives you rashes. And we had cards like this. We hover over it. You see it becomes a hand and then people can click on it. And people didn’t get it. They didn’t get you could click it even if the pointer became a hand. Because there are two little changes going on and what we did, we did a big button here below: “Bekijk het antwoord.” That means, “Look at the answer.” So,people were saying, “What’s the answer to this question?” and we had to add a big button to make it clear that they had to click on it to watch the answer. So, don’t overestimate how easy it is for people to use a card. Because you’re a designer, you know everything. But, you are so used to all of the interfaces, but, most people need some more help to actually get the interface.

So, don’t let people get lost.

Mallory van Achterberg gave a great talk last month over enlarging and zooming. I really encourage you to check it out. And if you zoom, maybe you can get lost if you are tabbing through a page to get to a focusable element and you cannot see where you are anymore.

So, be predictable in your tab order. This is one from a Dutch website, Volkskrant. If you tab, you tab through a menu. Okay. Then the large featured post gets focus. There’s a blue line around it. And if you tab further, you’ll see that on the far right, the, “More” link gets focused. And then the links below the “News” gets focus. And after that, the news items in the center get focus. So, the order is not predictable. And if you are enlarging the screen, you maybe just get this. While this is done, if you are mobile, then the News items drop below the featured items and below that there are the two posts that were once in the middle. You have to watch this if you play with CSS grid, if you play with grid order. Check if the taborder stays right, that the taborder stays the way it should be if you tab through all of the links in your card.

The last thing I want to address is, “Avoid multiple tabs to the same link.” And I have a few options to do that. If you have a card and you have a featured image, you have a link and you have an excerpt. Most people just hover over the image and see if it’s clickable, so it’s very nice to have the image clickable and also the post title clickable because that’s what people expect to be clickable.

So, you can add just two links. But, then, you have two links to the same page. And if you are using a keyboard, you’ll have to tab two times through each card to get further. And if you have a screen reader, there are two of the same links in your link list. So, that’s a lot of clutter.

So, what can you do? Well, this is what I see a lot and I really hate this. You just put an `<a>` around everything. That’s a really simple solution. Just link the whole lot. Done.

Well, this is really a disadvantage for people who get the links read aloud because the link contains the whole stuff. In this case, the alt of the image, the heading, and also the excerpt. That’s not very clear for your link list. I think this is a really bad practice. So there are two options you can do what I think are very neat. You can have a `<span>` inside your link that covers the card. So you have an image and you have the H3 and then you have the link. And in the link you put a `<span>`. The container you give `position: relative`, hen the `<span>`, you give a position absolute and your let it cover the whole container with width and height 100%, `top` is 0 and `left` is 0. It works like a charm. You have only one link and if you have a keyboard-only link, it’s focused and so, the whole cart is clickable.

Then there’s another one, I found it on the website from Heydon Pickering, “Inclusive Components.” You can do the same by using the `pseudo-element` for the link, so you don’t have to use the `<span>` you just use the `pseudo-element` on the link and you do actually kind of the same: `content’ empty and `position: absolute`, left, top, right, and bottom 0. Very neat. You can even add an extra link to it. If you have a link, for example, in your excerpt, that link you give a `position: relative` and a `z-index` that’s a positive `z-index` and if you hover over that, that’s really a separate link.

Okay. So this is all done with CSS. You can also do it without CSS. And this is also up for debate. So, I would like to know your opinion. But if you have a `tabindex=”-1″` and the `aria-hidden=”true”`, you can completely hide links for a screen reader and for a keyboard users. Then the links are still there, but, they are skipped while tabbing, and they are hidden from the link list for screen readers. So, we have here two links in the same blog post but only one is tabbable and only one pops up in your link list. Which one you prefer is up to you. Just don’t put a link on the whole container, please.

Okay, this is what I wanted to say. There are a lot more things I wanted to address if I had much more time, like: Should I put links on everything? Should I link categories? Should I link authors? Should I put categories in the list items? Should I use many screen reader texts or what should I hide and what should be clickable? But I think these are the main issues, like good heading structure, good link text, and make the order logical. And most of all, dear developers, learn HTML5 deeply. Thank you. So that’s what I wanted to say. If you want to contact me, I’m on @RianRietveld Twitter and my company is Level Level. I’ll stop sharing my screen now.

>> MICHAEL BECK: Okay thank you very much. That was very interesting. I’m going through the chat to see if we had any questions. Talal asks what’s the argument against putting a link around the whole container?

>> RIAN RIETVELD: Because the link text will be huge. The featured image, also, the metadata, the example would be there. Putting it around the container means that everything that’s in the container will be announced to a screen reader user. And that’s really a lot of text sometimes.

>> MICHAEL BECK: Yeah that makes complete sense. All right. I certainly love the advice of learning HTML5 deeply. Everything I see whenever we go through a lot of stuff, just, “Why are you overcomplicating this?” HTML5 is made to do this, why are you adding ARIA labels and all of this other stuff just whenever you can use the native code for it. It boggles my mind. But yeah.

>> RIAN RIETVELD: I think you have to look at your code. And I see a lot of people setting things up in `<div>` and `<span>` and that makes your code really flat, like it has no real meaning. It’s so easy because it looks okay. It works for you. But, for all the technology that really interacts with your site, it’s really, yeah, hard to understand. And, also it doesn’t really work very well. And, if you give structure and meaning, if you look at your card to say, “What’s really the meaning of this? Is this a list?” If you have a bunch of cards, put them in a list. And then, it makes sense because it’s a list of cards. Look really at each element: Should this image be linked or should I do this differently? That is what I wanted to really emphasize. Look at the code and look at the `<div>`. Is this a `<div>` or is this maybe a paragraph? Or is this a heading or maybe it’s not a heading. Is this an image? Does it need an alt text? What kind of alt text do I need here? And do you really consider instead of just bumping out `<div>` and `<span>` to make it work for you visually. Because it also has to work for screen reader users who have to listen to it. And they don’t have a visual overview of how it’s put together.

Yeah, I see a question: “What about article tag for a card container?” Is that a good idea or choose something more subtle? I think, I looked that up on and it’s really my place to go for really specs about HTML5. And if you look there, it’s really for the blog post itself. And if you have a lot of articles below each other, I think you should reserve it through the blog post itself. But in the examples that in the end gives, they use, also, articles for cards.

So, maybe it’s up for debate, but, I don’t think any screen reader actually announces if it’s not code or not. I don’t know really weight it has and if it’s really semantics meaning the adds to it. So, I think read the in the end specs and see if it actually suits your website. There’s not really a wrong or right I think in this case.

There was another question: “Is there any valid use case for the CSS `order` property from an accessibility point of view? For example, the heading with the author visually above it or would you suggest a different solution?” I think that would be a good use case. If you have the heading above, for example, the author above the heading, as long as it’s in the DOM. It’s really, without the CSS, that’s really the DOM is in the right order: first the heading, then the author. And then you can with CSS switch them if it’s not a link. If it’s a link, the order must be just as you see it, but, if it’s not a link, you can change that with CSS so the order visually different. Only not if it’s a link because the link order must be the same as the DOM order, but, for example, if the author isn’t linked or if you want to add extra text, then you can use `order`, I think.

>> MICHAEL BECK: Okay we have another question in the Q&A. They just wanted you to share the CSS code that you showed to make larger content area clickable.

>> RIAN RIETVELD: Yeah, all the codepens.

>> MICHAEL BECK: And then I’ll also have that in the description on the YouTube video as well we’ll have the link. Someone did mention earlier that it’s hard to come up with questions because you covered everything so well already.

>> RIAN RIETVELD: I have some questions!

>> MICHAEL BECK: Well this is new! (Chuckles).

>> RIAN RIETVELD: Well, actually I want to say, “Why is it so unclear to have the post title of alternative text in links?” Because I get so many responses on that, that it’s wrong. I would like to have some feedback out of that. It doesn’t have to be now. But, really I want to discuss about.

>> MICHAEL BECK: Yeah if anybody has any thoughts on that, go ahead and hit up Rian on Twitter, as well. And okay. It looks like we are out of questions. Well, thank you, everyone, for attending. And thank you, Rian for that excellent presentation. Next month we have Doug Scheppers on. What is Doug talking about? I honestly can’t remember what Doug is talking about. Let me take a quick look. He’ll be talking about how to think about the accessible data visualizations to learn how the brain processes data visually and how you can leverage different senses to provide an equivalent experience for people with different disabilities. And that’s going to be on September 4th. Wednesday, September 4th, at 11 a.m. and that will actually be the 12th episode of our first year at technica11y. We started last October. And September will be our 12th episode. So it will be our end of Season One, I guess you could say. So hopefully we’ll see you all next month. Thanks again to Rian for her presentation and to Clare for her captioning. And we’ll see you next month.

Rian Rietveld

About Rian Rietveld

Rian Rietveld is a senior accessibility consultant for the digital agency Level Level. She lives in a pretty little town near The Hague in the Netherlands. When not coding, you can find her working in my garden.

Performance and the Accessibility Tree

Transcript

[Intro music]

>> MICHAEL BECK: Welcome to technica11y, the webinar series dedicated to the technical challenges of making the web accessible. This month our presenter is Eric Bailey, a Boston-based designer and maintainer of the Accessibility Project.

>> MICHAEL BECK: Hello, everyone, and welcome to this July 2019 edition of technica11y. I’m Michael Beck, the operations manager at Tenon and your host and moderator, as usual. Thanks so much for joining us today. Happy 4th of July to our American contingent! Please remember to stay safe this year during any Independence Day festivities you attend; we would like to have you back in August. As noted during the intro we have Eric Bailey with us today. Hello, Eric!

>> ERIC BAILEY: Hey, how is it going!

>> MICHAEL BECK: It’s going quite well! Eric will be talking today about an often overlooked aspect of accessibility and that’s performance. He’ll highlight some opportunities and techniques that designers and developers can use to improve their website or web apps performance by embracing an accessible and inclusive mindset. So, without any further ado take it away Eric.

>> ERIC BAILEY: Thanks, all right. So, let’s set the stage here. This is a talk about performance with performance being the manner in which a mechanism behaves. I was conducting an accessibility audit last year which is the process of performing manual and automated checks to see if a Website can work with assistive technology. The client was a medical education app and it was used to train caregivers. It was built using a single page application framework using Google’s material design library to construct the user interface. And when I learned that, I thought, “Oh, sweet! Google made it. I don’t have to worry as much.”

So, I fire up VoiceOver, which is the screen reader for Mac OS, and I start testing and things are going pretty well. And, then, VoiceOver crashes. I try restarting Safari. I try clearing the cache. I try closing all of the other tabs, try quitting every tab I have. Heck, I even try rebooting! Same result every time. So I asked my boss, Karl, “What’s going on?” And he said, [changing his voice] “Oh, it’s probably problems with the accessibility tree.” That’s my Karl impression. I apologize.

(Chuckles)

And I go, “The what now?”

So, how do you describe an interface? And before, you know, I get more into this, like, what I want to know is, I’m not saying, “Tell me what you see or hear when you turn your computer on.” I’m saying, “How do you speak computer to a computer?” And the way we do this is with the accessibility tree. Fundamentally, the accessibility tree is a collection of objects, all of the little atomic bits that make up a user interface. People who rely on assistive technology use the accessibility tree to navigate and take action on user interfaces. And without a functioning accessibility tree, there is no way to describe the current state of what an interface is, and consequently, no way for some people to be able to use their computer or smartphone or other device. So, suffice to say, the accessibility tree is a really important piece of technology.

So, how do you build one? How do you build an accessibility tree? First, you have to give every object in the interface a name. Names are short identifiers used to describe purpose. Then, you give it role. Roles are predefined values that tell someone what they can expect to do with the interface object. For example, a role of `button` means someone can press it to activate some pre-defined action. Then, we have properties which are the attributes of the object. Examples of this are its `position` in an interface, its `state` or interactions that are allowed. For our button, that could mean a toggled state to indicate it being pressed in. I think a good example here is the play button on a Media Player. And then finally, we have a `description` which can provide further information about the object, if needed. These accessible objects are then programmatically grouped together to form more complicated user interface components.

So, how do you build these components, let’s say, an operating system alert dialog? That’s a pretty commonplace thing for UI. Starting from the top down, we have a menu bar, that’s the anchor that we’ll attach everything to. And then we have a `title` for the menu bar, so we know what it’s all about and what contents we can expect to find. If you’re using a screen reader, titles are really helpful, as it saves you from having to dig around inside the rest of the component to figure out what it’s for. The `title` here being, “Unsaved Changes.”

We might also need to close this dialog window once we learn what it’s for so we include a close button in the menu bar. And then we add the `body` of the dialog, the place where we can place the bulk of the dialog content. In the dialog’s `body`, there’s another `title`, which asks us if we want to save the changes we made to the thing we were working on. And then we add text to the `body`, which will provide more information about what happens if you choose not to save. Then, we add a save button, which will allow us to commit to saving the changes we made. And then, the accompanying cancel button in case we don’t and presto, we have a dialog component! Because these collected objects have accessible names and are therefore present in the accessibility tree, we can speak computer to computer to get what we want. I can programmatically say, go to the dialog. Then its body. And then activate the save button. And it works. How cool is that?

And this might seem a little pedantic, but, please bear with me for a bit here. We do have the dialog component but there’s more to it than just that. Interface components have to have a place to live and that place is an operating system. Operating systems also include components that allow us to navigate to and access the stuff you store in them. It’s also the place we install and run programs. And all the little doodads and widgets and games we can’t live without. And then, it also has the browser, which is rapidly becoming an operating system in its own right.

The browser contains the mechanisms we used to access the web. And the web is sort of like the Wild West in that you can write more or less whatever you want and it will usually work, which is kind of both a blessing and a curse. But, regardless of how you write what you write, you can’t escape the fact that you have to ultimately create HTML. That HTML then has an appearance and behavior augmented by both JavaScript and CSS and, again, there are many ways to go about doing this, but they are the two requisite parts that make up the whole that is a website or a web app.

The HTML markup augmented by both JavaScript and CSS creates the Document Object Model or DOM tree which is the programming interface for websites. Browsers then read the DOM and all of the information contained within it to draw an interface which is then shown to a user, somebody like you. The user can then take actions on the visually rendered interface, which updates the DOM, which in turn updates what is visually rendered and this allows us to make our websites dynamic, which is really cool. So, running in parallel is the accessibility tree, which is sampled from the generated DOM. And I say sampled because the accessibility tree will use specialized heuristics to only surface things it deems necessary. Modern versions of the accessibility tree are also generated after styles are computed as certain CSS properties such as `display` and `pseudo-element` content will actually affect it.

This sampled version of the DOM is then read by various kinds of assistive technology including, but not limited, to screen readers. And there’s two things I would really like to point out here. First, using a visually rendered interface and assistive technology isn’t mutually exclusive. Not all screen reader users are blind. And many people choose to augment their browsing with devices that rely on the accessibility tree. Secondly, the accessibility tree relies on the user interacting with the DOM to update. It’s effectively a read-only technology in that we can’t directly work with it right now.

Another thing you should be aware of is that it’s more of an accessibility forest than an accessibility tree. There are different implementations of the accessibility tree and each depends on what operating system you’re using and what version of said operating system is running. And this is due to the different ways companies such as Apple and Microsoft have built and updated their operating system’s underlying code throughout the years. And just so we’re clear, the DOM can be a part of the accessibility tree but the accessibility tree is larger and not just limited to the contents of your browser. Because of this, the accessibility tree is more brittle. It has more to pay attention to and its technical architecture was developed before this whole Internet thing really took off, meaning that it didn’t anticipate the sheer amount of information we would be throwing at it. Crashing the accessibility tree and, therefore, breaking assistive technology support is bad, yes. But also, a large amount of information present in the DOM means there’s an accompanying large amount of work the accessibility tree needs to do to figure out what’s what and then report on it. Which. Slows. It. Down.

This can create a lack of synchronization between the current state of the page and what is being reported by assistive technology, meaning that a user may not be working with an accurate model of the current screen and may be taking action on interactive components that are no longer present. This can create the confusing experience of activating the wrong control or navigating to a place that a user didn’t intend to.

So, how do we help prevent this? Start with writing semantic HTML, using things like the `button` element for buttons instead of ARIA slapped onto a div helps lessen the amount of guesswork the accessibility tree has to do when it runs its heuristics to slot meaningful content into the description of the current state of things. This serves to both speed up its calculation and makes what it reports on more reliable.

And, speaking of semantic HTML, here is the raw living DOM tree of an actual website. In fact, it’s the registration page for this webinar event! Even a static performance website contains a lot of information a computer has to chew through. And again utilizing semantic HTML helps to reduce the effort it takes to generate the accessibility tree. And, unfortunately, using semantic HTML is kind of a rare thing these days, which is partly why I’m here giving this talk. So thank you, again, to Tenon for keeping your markup straightforward and semantic.

All right. I think you get the gist of it here. Of the code I showed you, five slides worth, we have only covered two-thirds of just one page. And it’s also worth pointing out that this is a relatively short page. And that, again, this is a lot of information to process.

And keeping the DOM tree example in mind, we now have a simple form. It’s a pair of unstyled radio buttons asking you if you want the chicken or the fish as your meal preference. Here is how that form might be translated into the accessibility tree. We have a `fieldset` and within the `fieldset` there’s a `legend`, say, it’s stating meal preference. There are two `input` elements with a `type` of radio as a radio button. One with the `name` of chicken and one with the `name` of fish. Chicken has been checked as I would wish to have the chicken as my meal. And then there’s a `button` with the `name` of save. And you can see here if we use semantic HTML the names, roles and properties are automatically filled in for us without any additional effort and when I was speaking about how semantic HTML slots in, this is a more granular example of what I’m getting at. Here is an even more high fidelity example, sampled again from the Zoom registration page. I’m using Firefox’s Accessibility Inspector to dig into a `TEXT_NODE` and there’s a ton more information exposed here. You’ve got attributes, states, actions, a child element count relations and available actions. All of this information is used by the accessibility tree to help it determine and describe the shape of things.

And here is an even more high fidelity example. This is a raw text dump of the accessibility tree for this same page and this is an example of what the language might look like when we’re speaking machine directly to machine. We don’t speak machine directly though. Before we had Firefox’s Accessibility Inspector, we had to rely on more specialized tools to be the translaters. The Paciello Group’s aViewer and Apple’s Accessibility Inspector are the two go-to resources here, and you’ll still need them if you want to do some really serious digging or inspect things other than websites.

So let’s make the abstract immediate here what’s going on here and why should you care? With my auditing project, I narrowed the projects down to issues with material designs radio inputs and this is how they appear visually. And here is how they appear in code. To make a material design radio input, you need six HTML elements containing nine attributes with a DOM depth of three. You also need 66 CSS selectors containing 141 properties which weighs in at 10k when minified. You also need 2374 lines of JavaScript which weighs in at 30k when minified. All of this will get you a radio input. But you need more than one radio input to use it properly and oftentimes there’s a few options to select from. Sometimes there’s more than just a few options and sometimes there’s even more than that. In the case of my audit, we had a ton of radio inputs being conditionally injected into the page and the point of this being is that this all adds up.

Google’s Lighthouse project, an Open Source tool that analyzes for performance problems recommends the optimal DOM tree has the following: less than 1500 nodes, a max depth of 32 nodes, and no parent node with more than 60 child nodes. What I would like to call attention to is the max depth of 32 nodes bit. This might seem like a lot of wiggle room at first, but take a moment and think about the templates of the websites you’ve worked on. You know, there’s the `frameset`, there’s wrapper divs, landmarks, component wrappers and if you’re doing it right `fieldsets` in your forms and each digs a little bit more inward.

Another part of accessibility auditing is providing a fix to problems you uncover. It’s tough work, but nobody likes to pay people money to tell them all of the things that are wrong but then offer no solutions on how to fix it. We wound up recommending a radio input pattern that utilized three HTML elements. It’s a pattern developed by my friend, Scott, taken from his excellent a11Y_style_forms_controls project. It’s worth saying Scott puts these patterns through their paces and tests them with an incredibly robust set of operating systems browsers and assistive technology combinations, so a nice side benefit is knowing that I can recommend this pattern with confidence. Visually, it was completely indistinguishable from its original version and to compare the two solutions we have a 50% reduction in HTML elements and we cut the DOM depth down by a third. There’s also a 30% reduction in CSS selectors and properties resulting in the CSS payload for this pattern being reduced by 90%. We have also completely removed 30k of JavaScript which is 30k blocking resource being served.

So, we cobbled up a rough prototype and able to create the environment that mimicked the conditions of the site we were auditing only using the new radio input code and now guess what? It worked! VoiceOver didn’t crash! Awesome!

So, why is this our problem? Why should we care about the fragility of other people’s software? Well, prioritizing developer ergonomics without considering the generated HTML can lead to bad things happening and regardless of our setup, we tend to pile even more things onto our base experience, things like ads, and analytics, and social/marketing engagement tools, and development integration utilities. And then, there’s also this Cold War raging between websites and their users. Here is Facebook splitting a single word into 11 DOM elements to avoid ad blockers. And then, this graph is generated from the median values of how 1.3 million websites are generated with JavaScript claiming the majority of the share. This JavaScript majority means it’s much more time spent blocking the browser from performing other actions, including things like interfacing with assistive technologies.

So, when we throw out what the browser gives us for free, we oftentimes don’t realize that there are very real, very important things we sacrifice in doing so. Here is what Marco Zehe, Mozilla’s senior accessibility QA engineer, has to say about this:

“Nibbling away at those milliseconds it takes for information to reach assistive technologies when requested. My current task is to reduce the number of accessible objects we create for HTML:div elements. This is to reduce the size of the accessibility tree. This reduces the amount of data being transferred across process boundaries. Part of what makes Firefox accessibility slower on Windows since Firefox Quantum is the fact that assistive technologies now no longer have direct access to the original accessible tree of the document. A lot of it needs to be fetched across a process boundary, so the amount of data that needs to be fetched actually matters a lot now. Reducing that by filtering out objects we don’t need is a good way to reduce the time it takes for information to reach assistive technologies. This is particularly true in dynamically updating environments like Gmail, Twitter or Mastodon. My current patch slated to land early in the Firefox 67 cycle shaves off about 10 to 20% of the time it takes for certain calls to return.”

Said patch has landed.

And, you know, note that all of this optimization is only for one browser: Firefox. And that there are a lot of browsers out there. It’s also not all about browsers, either. This is a refreshable Braille display, one of the many other kinds of assistive technology that interfaces with the accessibility tree.

So, someone should do something; the battle cry of bystanders everywhere. Let’s unpack this some and figure out what our available options are. For screen readers, the main ones are JAWS and NVDA (both are Windows screen readers), VoiceOver for Mac OS and iOS, and TalkBack for Android. These are the four big screen readers you’re going to be hearing about. And it’s sort of analogous to have Chrome, Safari, Firefox and IE are the main browsers for the web, in that there’s more screen readers out there, but these cover the main use cases you’re most likely going to deal with. And while not all assistive technology are screen readers, if your site works well for them, chances are it will work well for other assistive technology. Of them, all but one have an open issue tracker, but half have closed source code. That means that while we can file issues, we aren’t really empowered to do much more about it on the assistive technology layer. And it’s also completely unrealistic to expect people to submit and follow code issues or pull requests across all of these issue trackers in addition to working a full-time job.

Our only other realistic option here is to keep the DOM trees on our sites nice and shallow and there are actual tangible benefits to doing this. Here is Marco again weighing in on his optimization efforts:

“Reducing the number of milliseconds it takes for a screen reader to start speaking after a key press from about 140 to 100 here, or from 120 to 100 there, doesn’t matter much on a fast machine. On a slow machine, that reduction is from about 230 to 250 down to 200 or 190 [milliseconds].” And let’s talk about what “slow machines” means. If you are disabled and/or underserved, you face significant barriers to entering and staying in the workforce. This means you may have less access to current technology, especially the more expensive higher quality versions of it. Another factor is some people who rely on assistive technology are reluctant to upgrade it for a very justified fear of breaking the way they used to interact with the world. Slow machines may also not mean an ancient computer, either. Inexpensive Android SmartPhones are a common entry point for emerging markets and with Android comes TalkBack. A slow machine might also come from a place you aren’t expecting, by which I mean you might have a state-of-the-art computer and are thusly doing state-of-the-art things on it. This requires a ton of computational resources which makes fast things slow and with less computational resources to go around we may have unintended consequences, possibly recreating a situation similar to our too many radio inputs problem. Think Electron Apps which are desktop programs built using web technologies. So, accessibility auditing isn’t something people normally do out of the goodness of their own heart; it’s typically performed after a lawsuit has been levied against an organization. And let me be clear: when you create inaccessible experiences, you are denying people their civil rights. The Americans With Disabilities Act guarantees that people cannot be discriminated against based on their disability conditions and this extends to both private organizations and the digital space. This is a good thing. It guarantees protections as more and more of the services necessary to living life go online. You need to work with what you have and not what you hope will be. Part of this means understanding that when we want things to be better, we need to understand that these kinds of changes are really technically complicated under the hood and spread across multiple concerns.

On top of that, accessibility fixes are often viewed as unglamorous and deprioritized when compared to other features. And if you don’t believe me, here is the support matrix for the `title` attribute incorporated into the W3C’s HTML spec in 1993. It’s 26 years later and we still have a ton of interoperability problems. I don’t mean to bum you out and I don’t expect you to become accessibility experts. However, as people who are interested in more than just the surface level of things, you are all uniquely empowered to affect positive change. what I ask of you is to at least incorporate basic accessibility testing into your workflow. if anything just check to see if a screen reader crashes. a bad assistive technology experience is better than none at all. Okay. Whoa, the slide background is yellow now! This is what I call a great segue. I’m a designer by trade and part of that job means coming up with alternate strategies for allowing people to accomplish their goals because, sometimes, the most effective solution isn’t necessarily the most obvious one. With that in mind, we’re going to talk about another definition of performance which is the ability to actually accomplish something. All these little surgical tweaks and optimizations don’t mean squat if people don’t understand how to operate the really fast thing you gave them.

Another aspect of dynamically injecting a ton of radio inputs to a page is it adds more things for a peson to think about. This is called cognitive load and it’s a huge problem. it affects our ability to accomplish tasks and, importantly, our ability to accomplish these tasks accurately. Namely, cognitive load inhibits our memory, our problem-solving skills, our attention, our reading comprehension level, our math comprehension level, and, shockingly, our ability to actually understand what we see. It’s such an important problem that NASA developed the Task Load Index, an assessment tool to help quantify it and, importantly, this isn’t warm fuzzy feelings about empathy. This is a serious attempt by a government agency to refine efficiencies and prevent errors. And one of the most interesting things about the existence of this index is that it’s an admission that disability conditions can be conditional. Think about it. When was the last time you were tired, distracted , or sick, or learning a new skill, or heck, when was the last time you were drunk? Cognitive load is an important thing to track for building rockets, sure, but it also translates to other complicated things like making and using software.

One of the things we can do to lessen cognitive load is to lessen what people have to parse at a given moment. For the medical education app, we could have added an additional step into the userflow and asked a high segmenting question. It’s more friction, sure, but it’s being used strategically as a focused choice to help keep the person on track and the cognitive load lower. This would help to filter down the results you get which makes it both easier for the person and browser to parse. The other big picture question we need to ask is if all this work is necessary. The most performant page is the one you never have to use, by which, I mean how can we side step the issues by using other resources and information previously made available to us.

If you’re interested in this sort of thing, the 2018 Design in Tech Report is a must read piece. One of the things that it revealed was that surprisingly very few companies conduct qualitative research which is the practice of asking people how they use a feature and how they feel while they do it. That’s 12% for early-stage startups, 32% for mid-stage startups, and 46% for late-stage startups conducting qualitative user research. You know, I’m not a numbers person, but there does seem to be a trend going on here. Another interesting thing is barely any companies conduct qualitative testing for features after they launch them, so, we are all collectively throwing features into the larger ever-evolving ecosystems that are our products and not checking to see how it will actually affect things.

As consumers, we also need to remember that we’re only seeing those companies that beat the odds. The market is built on top of the corpses of failed businesses who all poured their cash and resources into the wrong things. So the second big ask from this talk is really just repeating the first one. It’s one thing to read about something and believe it to be true. But it’s another thing entirely to put it out into the world without verifying that it works. The web and more importantly the people who use it are too important not to.

So thank you for tuning in and thank you to Michael, Karl, and technica11y for this opportunity the slides and presentations are available on noti.st and my contact information is available on my website [Title: ericwbailey.design]. So, if you have any questions feel free to reach out and thank you again.

>> MICHAEL BECK: All right thank you, Eric, if anybody has any questions they can go ahead and toss those up in the chat, as usual. I literally laughed outloud during the segue moment and people in the office were looking at me. (Chuckles).

>> ERIC BAILEY: It was a calculated bet.

>> MICHAEL BECK: It worked. It paid dividends in full.

>> ERIC BAILEY: Yeah, I didn’t have the benefit of an audience reaction so I sure hoped this worked.

>> MICHAEL BECK: Anyone any questions? Ah, tools that count node depth?

>> ERIC BAILEY: Hm, that’s actually interesting. I think you can query in the console, using JavaScript, but off the top of my head, I’m not sure. Typically, what you’ll want to do when you are thinking about this kind of thing is to work on a per-component basis. That way you don’t have to step through the whole DOM as a way to kind of do remediation work as that’s just a lot of information. I wish I had a better answer for you off the top of my head, but I do believe you can query it using a JavaScript kind of count like array method.

>> MICHAEL BECK: Dennis in the chat just suggested trying Lighthouse for DOM depth and performance auditing.

>> ERIC BAILEY: All right. Ignore me. Listen to Dennis. Thank you, Dennis!

>> MICHAEL BECK: Someone would like you to talk a little bit more about cognitive load and accessibility, which I think that was a great point that you made and I think that’s a really important issue to dive a little deeper in.

>> ERIC BAILEY: Yeah, it’s something I’ve personally been turning my attention to and it’s a big hairy ball of a topic. There’s a lot of different ways to slice it. So, I mean for cognitive load, where I’m thinking about it, is basically I think, there’s a lot of correlation with something having your primary attention and then what lives in your head about how to operate something. So, considering say this interface here for Zoom, there’s things that are similar to other things on a computer that I know how to use, so, like, little buttons and stuff like that. It’s nice they have labels. That helps me understand purpose. But, the more that you start to deviate away from these standards that we have built for ourselves, the more I have to do guesswork and the more guesswork I have to do, the more I can potentially not understand how to operate something, the more frustrated I get in a situation where you’re trying to put a product out into the world for people to use.

I think the average app evaluation time is like two seconds for somebody to figure out if this is for them or not. So that’s closing a tab or deleting an app that they just downloaded. So, I think it’s one of those things that’s very, very important and we kind of tend to overlook in our excitement to jump into looking at the actual code. I don’t know if that answers your question. I believe the W3C’s Task Force has a really good intro on cognitive accessibility as well as WebAIM has a really good initial resource.

I just saw Gordon (his last name is truncated in the chat) and he has a really good point about information architecture, so, I’m going to totally steal his idea. Thank you! Which is like, if you’re designing something, figuring out the big buckets of where things live because when you show up to a website, there’s an implied structure: Home, Services, Products, About Us. And that’s kind of big picture what information architecture is all about, which is where you believe things to be and then where people that will use your website think that things will be. So, user testing is a great way to figure out where people expect stuff to be, because if I go to resources thinking that there will be products there and there aren’t, I just close the tab because I didn’t find what I’m looking for, so, you start to ask questions of where would you put this and then seeing if there’s any trends that bubble up.

This is especially actually really important for both low literacy and low technological literacy as well as foreign language situations where there’s the potential of cultural misunderstandings. So, if you do any work with internationalization that’s also a really big important thing to think about.

>> MICHAEL BECK: Luna asks about any knowledge that you have about Outlook crashing with screen readers?

>> ERIC BAILEY: First of all, I am so sorry! We use Gmail here. I wish I had a better answer for you. I know Outlook has a browser or a web renderer within it which is weirdly Microsoft Word which is something we won’t get into because therein lies the — yeah.

>> MICHAEL BECK: That’s really weird. (Chuckles).

>> ERIC BAILEY: So it may be not rendering the web as the web, it might be using a completely different kind of set of processes to do that. And I’m actually unsure of how the accessibility tree interacts with that. But, I would be happy to check it out because that’s really interesting.

>> MICHAEL BECK: Yeah, that’s a good research topic…

>> ERIC BAILEY: Yeah.

>> MICHAEL BECK: …to go into. Charles Hall has mentioned that there is some good recent research on short-term memory allocation and, to start with I’m probably butchering her name, she’s a Norwegian scientist named Ylva Østby.

>> ERIC BAILEY: Yeah.

>> MICHAEL BECK: If you’re interested in that sort of thing check that out that’s Y-L-V-A and her last name is Ø-S-T-B-Y.

>> ERIC BAILEY: Thank you, Charles.

>> MICHAEL BECK: All right. Do we have anything else from anyone? Nope. All right. Well, thank you very much Eric for that very interesting presentation. It was superb, as far as I’m concerned. Coming up, our next technica11y will be on August 7th, highly anticipated with Rian Rietveld who will be discussing creating an accessible card, as in the construction of the title, the thumbnail, date, the excerpt, the tags, categories, the read more link, the whole shebang. Again that will be on Wednesday, August 7th, 11AM Eastern. Thank you again, Eric, for joining us today and Clare from ACS for the captioning and once again all of you for joining us. And hope you all have a wonderful July. And I will see you next month.

>> ERIC BAILEY: Thank you, everyone, see ya!

Eric Bailey

About Eric Bailey

Eric is a designer at thoughtbot, with a focus on accessible and inclusive design. He’s a member of the A11y Project, an occasional author at CSS-Tricks, and recovering curmudgeon.

Designing and coding for low vision

Transcript

[Intro music]

>> MICHAEL BECK: Welcome to Technica11y. A Webinar Series dedicated to the technical challenges of making the web accessible. This month our presenter is Mallory van Achterberg, senior accessibility consultant at Tenon. >> MICHAEL BECK: Hi, hello, everyone, and welcome to this June 2019 edition of Technica11y. I’m Michael Beck, the operations manager at Tenon and your beloved host and moderator of this incredible Webinar Series that we have going on here.

Seriously, this wealth of knowledge, the good practical knowledge, that we have gathered here is pretty astounding and I do sincerely mean “we.” The questions that you’ve asked of our presenters have only served to flesh out the details and make information more relevant, more actionable and most invaluable of all, invaluable I guess you’d say. So before we get to this month’s topic please give yourselves a round of applause, a pat on the back, or perhaps treat yourself to something extra delicious today. Oh! Speaking of which, “Eid Mubarak!” to any of our Muslim attendees who may be taking a break from their festivities. You really do deserve something delicious today. Quick note for those of you who were expecting Rian Rietveld today as I announced at the end of last month’s webisode, we had to reschedule her and she’ll be presenting in August. This month we have Tenon’s own Mallory van Achterberg with us. She’s in the hot seat. Hello, Mallory!

>> MALLORY: Hello.

>> MICHAEL BECK: Long-time attendees know that Mallory is one of the more vocal members of the peanut gallery, as it were, but this time I’ve turned the tables on her and she’ll be talking about designing and coding for users with low vision and, before I hand the reigns over to her, as a technica11y first, Mallory has made her slide deck available to you, so you can use your own device and whatever assistive technologies at your disposal to follow along instead of just relying solely on the video feed from Zoom. I’ll put that link in the chat box right now for those of us in the live feed and it will be down in the description if you’re watching later on YouTube. So that’s it for me. And take it away, Mallory. >> MALLORY: Okay. I’m going to be talking about designing and coding for low vision. I’m going to be going over specific parts. And I will have practical tips when tips are something people can do anything about. When people think about accessibility on the web, they seem to like to focus on blind users. I’m guessing because, as developers, we’re used to solving problems with code and screen readers are very code sensitive. But they’re are really small number of people, there’s much larger groups of people that we should be concerning ourselves with. But I’m going to focus on the low vision folks. First I’ll go through a group of typical vision issues. It won’t be all of them. But the first and sort of the most popular one would be just acuity. Things are not sharp. This is one of my eye problems. And I can wear glasses for things that are far away. But to make things sharp, the glasses make things very, very tiny. So what I’m more likely to do is to get closer to the thing or zoom in. Another one is cataracts, which can cause both blurriness like we saw before and it can lower contrast and a lot of people don’t notice right away if they have something slow and progressive like cataracts that their vision has deteriorated. This is my only moving slide, I promise. But, with diabetic retinopathy you have blood clots floating around in your eyes while your vision is slowly degrading. With glaucoma, you lose peripheral vision, so you can see things mostly in the center. Whereas with macular degeneration and other things, peripheral vision is all you have and this would be a group who would need to zoom out, for example, rather than zoom in. And colorblindness is not new to anybody and yet we keep forgetting about it as we design things. So there’s various ways people with low vision can deal with it. And I’m going to go through those. They could use a text-to-speech engine. They might use a screen reader, but that really is a very complex piece of software. There are also much simpler text-to-speech engines that usually will highlight where it’s reading or read where the mouse is. But that’s one thing some people can use. What may surprise people is that zooming out can be a thing. I’m showing a slide from a talk by Damien which is a really great talk and in my slides I link to their slides. But if you can find the talk online, it’s really great. In the talk, he (sic: they) explains that most people when they are reading rely on the shape of the words to tell what it is. And if you’re really zoomed in and you can’t see the entire word and can only see one or two words, then you lose that speediness you get by recognizing shapes of words. You can make the fonts larger in your operating system. But, that doesn’t mean that all the applications running on your computer actually are listening to it. I had a heck of a time setting up pass codes because the line heights were apparently very rigid. Most operating systems have a magnification software built in, although the one for Linux kind of has been abandoned and there are third party screen magnification programs. The thing about screen magnification is, it’s as if you have a credit card sized view of the entire screen and you move that view around by moving your mouse. Or, if the application supports it, by keyboard focus. As you tab around, that little magnified viewport will also move with it. But you would be surprised how many people just lower the screen resolution because the application just doesn’t make the fonts large enough. So, if I’m down by 600 by 800, I can actually see some of the text on Dragon’s startup window. Another example is the GIMP (GNU Image Manipulation Program), something ported from Linux. If I actually want to read it, I have to lower my screen resolution, so, if you hear people saying nobody uses 600 x 800 anymore, that’s not entirely true. Most operating systems have a high contrast setting, which is great, but, I’m going to specifically call out Windows high contrast because this tries to really ensure that the minimum contrast is really high, at least 7 to 1, if not higher. It’s not the same as reverse color or inverse video. This is definitely special. So, I always make a special callout for Windows high contrast. If you need really high contrast, Windows has excellent high contrast. And, unlike a plug-in that might be sitting on a browser or an application, this is operating system wide so long as the application listens to it, which not all applications do. And there’s always the good old nose to the screen. This is still a thing. If you want to have the text seem larger without only seeing parts of a word, sticking your face right up against the screen is sometimes the best way to go. So, there are very typical problems that come with low vision, which I think if I show them, my goal is that those watching come across something that they hadn’t thought of and will think about it the next project that they do. So what is magnified scrolling? You can’t do anything about this. If you’re using a screen magnifier, if I want to read a sentence I have to go from left to right and there’s nothing any designer or developer can do about this. Text doesn’t wrap inside magnified viewing because that’s not just how it works. However, for people who are using browser zoom, that is something you can do something about. Here in GitHub, if I want to read this comment I have to scroll from left to right and back again. That’s not cool. Same with Gmail, which I actually can’t use this view. I have to use the plain HTML view which still means I have to scroll but at least then I don’t have two huge sticky things wasting lots of my screen real estate. Don’t do that. So, I’m using GitHub’s code here. And I’m using one of their pre-existing breakpoints. I don’t set my breakpoints in pixels but an example of what you could do is, if the screen is smaller, undo floats and let widths be auto. That wouldn’t work on GitHub alone because there are other things that have widths set on them but also because the Flexbox in the header. Flexbox is something I’m starting to see more and more is causing issues and I’m showing CSS-Tricks on my slide because it’s mostly done pretty well. They are mobile responsive and their Flexbox is really clean, so it’s easy to show in this example: I have a logo, a search control of some sort, and the other control is offscreen and that’s because that whole header area is a Flex container. If we let things wrap, at least I would have access to it. The default for Flex wrap is no wrap. If you have a Flex container in things in a horizontal row, you have to check if you zoom in whether or not those things can wrap if they need to and again, you can use a media query and again, I grabbed one that was already on the CSS-Tricks page. This is just an ugly but functional thing which is fine, but you could also, of course, make it all pretty if you wanted to. Getting lost is very common when you’re zoomed in quite a bit. And it gets worse when excessive white space is used for design reasons. Lots and lots of white space looks clean. So many Websites are using a lot of it. But, then at some point, you run out of landmarks. And I wanted to make a special note of cards that are usually very large clickable areas that have a bunch of text. Now, Rian will be talking in depth about cards on another technica11y, but, I wanted to mention them here because I’ve seen cards that are not done well like this one. This one is from the Event Apart Website which does it well. I can still read this. They darken the text slightly when you mouse over it, but in other places I’ve seen it where everything gets completely dark or the text is replaced with some other text or a picture is loaded on top, and what I want people to keep in mind is that for some people the only view that they have of the thing on the page is the hovered view. There is no default view because you can’t get something into your viewport without either moving the mouse there or moving keyboard focus there. There are ways to get around that with the screen magnification software. You can use something where there’s an unmagnified part to help orient where you are and a magnified part to read. You can have it attach to your mouse which I think I just heard Apple’s recent…they had some big update and they have something like this now, which is nice. Or you can dock part of it. Docking is not great unless you have multiple monitors, in my view. I always tend to do full screen and if I need to orient, I’ll turn off the magnification, figure out where I am, turn it back on, but if you have multiple monitors, this isn’t uncommon to have magnified and unmagnified views on separate monitors. But, it’s not always useful if you don’t have the room to do that. And a big issue is auto focus. Auto focus is just throwing you some place on a page and the screenshot is from GitHub from a couple of years ago. I’ll go back. This is what GitHub looked like and you would auto focus on the “Pick a username” despite the fact that the website has lots and lots of links and lots of buttons and lots things you can do they assumed everyone who came to GitHub.com doesn’t have an account and if I moved my mouse down I would see the “Your email address.” And this is not cool. They had a label. It was technically accessible for a screen reader but the label was hidden and they relied on placeholders which vanished when you were auto focused on something. That’s not cool.

Be very careful with auto focus. The site should be doing one thing and one thing at all. Then you can use auto focus and it can be useful but if there are multiple things people can do, no, don’t do it. Another issue we see a lot is, I’m showing an example from WordPress. If you’re on the backend of WordPress, there’s a media library where you can choose an image and next to where the images are there’s attachment details, which has a form. If the right side was scrolled down a bit you would see form fields. But, once you’re zoomed in a bit, the form fields visually vanish, but they’re still there. They’re just being covered up. All this stuff here is very sticky, the top part is sticky, the bottom part is sticky, everything is absolutely positioned. So my rule is if I can’t see it, don’t let me tab to it. That’s bad. It’s very common for a lot of websites to try to show a subtle response to people. A growler that comes up from a bottom or an alert in the upper left hand corner or in this case, on eCommerce, it’s very common to have a shopping cart in the upper right-hand corner. And so, if I order something and I put it in my cart, this will change, which is good. But when I’m zoomed in or if I’m just a person who has a cognitive issue where I need to work very hard to focus on my task or whatever, I may only see this. And I’m not going to necessarily see changes that are on the upper right or upper left or in the bottom. So one thing you can do, you say, I have three of these I want to order, I click my order button (sorry it’s in Dutch) that a couple of things happen in this example. First, the button becomes disabled so that I can’t click it again to accidentally order six of the items. But because disabled buttons can’t hold focus, we don’t want to lose our focus, so JavaScript is carefully putting it back on the previous input where I can change the number to reactivate the button and underneath it says, in Dutch, that it’s in my shopping cart. That’s local feedback in multiple ways. That’s very cool. Try to think of adding local feedback. This is something designers think of first. An example of screwing it up is Trello. Trello is a good example of a lot of things being are screwed up but one is, if you have an error at the top of the page, I’m not going to see it. Don’t do that. There’s another trend that’s been going on the web which is showing keyboard focus for keyboarders and hiding it for mouse users. Now, earlier I said getting lost is really common and one of the things I do when I’m getting lost when I’m using screen magnification is I’ll switch to keyboard and I’ll start tabbing especially if I know there’s a button or link I want to get to, but I can’t find it visually by waving my mouse around; I’ll tab. And what I’m showing here is a Website where I have tabbed to a button and we can see it’s not very high contrast but there is a focus outlined. And usually what I do is, I tab to something and then I explore from that point. This is my landmark. But if I move my mouse, what this site is running, the moment it detects a mouse move it removes the keyboard focus and that’s not cool. So, the particular Website I was showing uses something called whatinput and by default, apparently, if you do a mouse move, it will do its thing. Now, you can set it up that it listens only for a mouse down, but the attribute that whatinput uses by default is if it sees a mouse move, it will change the attribute to mouse from keyboard. And so if you’re using something like this, be sure to, if you have to do this at all, be sure to listen for an actual click rather than just the mouse got bumped or the mouse got moved. Sticky headers. I love sticky headers. I hate sticky headers. Sticky headers are probably the worst thing I run into on the web. Don’t do them. Here is an example from Gutenberg where there are stacked sticky headers. The name of the article that we’re editing is on top and underneath is the section that we have opened where you could choose between block or document settings and all I have is a tiny little scrollable area on the bottom. Don’t stack stickies.

Cookies are often sticky and Trello, at least, makes them sort of mobile responsive. It squishes but because it’s absolutely positioned and stuck to the bottom, I can’t see the top and I can’t scroll up any higher. Even more common is the button to close the cookie warning or to accept the cookies is off to the right, but, because it’s position fixed, I can’t scroll to the right because you can’t scroll fixed position things. LinkedIn is a terrible example of this. Don’t make your cookies sticky. It’s very popular to have a drop-down menu stuck to a sticky header, meaning if you open up the menu, you can’t scroll down to reach the bottom of the menu. Don’t do that. There’s a mobile version of what I showed was Twitter. This is a mobile Twitter. But, while the mobile version looks actually pretty good on the portrait mode of a phone, I’m going to get a mobile view if I’m zoomed in on a desktop and the difference is a desktop is going to look more like a landscape orientation than a portrait and now the height matters. You get huge things covering up text. Don’t do that. The menu is better, though. I have a large scrollable area. So, the menu has been fixed. It’s still stuck to the left, but it’s been fixed by giving me a larger scrollable area. Another example is T-Mobile which has a drop-down menu of like 40 items. It’s huge. But they are mobile responsive so I can zoom in, right? But when I do there’s a big empty sticky thing on the top and I can only see a couple of items at a time and additionally they have put title attributes on the links with nothing but a smaller version of the text that’s in the body of the link so it gets in my way and makes them more unreadable. Don’t do that. You can test for a height and I have some example code where I’m using a max height of 10em but whether you’re going to use a min height or max height or 10em or something else, it’s going to depend on how big your sticky is. Does content inside it wrap as people zoom in? You have to check it yourself on a browser to find out what numbers work best for you. That way, if the designer or somebody else insists that something is sticky, it’s not sticky once people start moving in and the heights of their viewpoint is limited. Tool tips and popups have issues. Most designers and developers do it right with drop-down menus, where we’re used to hovering over a menu item a drop-down appears and the mouse can go over the new drop-down that’s appeared and it stays on the screen, but sometimes people forget to do that with tool tips. An example of where it’s not been done is JIRA. I moused over a button. And it has this big tooltip that shows up. But I can’t read it because to move back and forth to see all of it I have to move my mouse back and forth which means my mouse is no longer on the button, which means it’s vanishes it’s unreadable. So, the tooltip itself should stay at my mouse moves over it. It can also be the other way around, where it does stay on mouseover. I’m showing a screenshot on Twitter if you accidentally mouse over say, a username, you get a whole huge bio, which is good if I want to read it but it’s bad if I want it to go away. I should be able to close this without having to carefully navigate my mouse around it and out of the edges. For example, by hitting the escape key or you could make it that wherever my mouse is if it’s not on a link that clicking there could maybe make it go away. For this reason, I’m not a huge fan of CSS tooltips because it’s difficult to have the closing with something else without moving the focus or the mouse; it’s generally Java script. I have seen a complex CSS solution for this but it was a very complex CSS solution. Title attributes in general. You can’t do those kinds of things like making it hoverable or making it vanish because it’s generated by the browser so, by adding a title attribute, this popup just shows up and the developer has no control over it. I’m showing a screenshot from WordPress.org which, this has been fixed. This was an issue that they had in their tracker and somebody was arguing that, “Well, the title attributes were nice, they were just extras and they were just injecting a bit of fun into the page,” but I showed with this screenshot that I can’t read enough of it to tell if it’s important. Do I need to read this? I can’t. Because as soon as my mouse moves to the right I’m not hovering on plug-ins and it vanishes. And some people like putting title attributes on containers, which is awful, because everywhere your mouse goes, this stupid little title tooltip shows up and it covers things making stuff hard to read and depending on the browser, it may or may not vanish after a certain pert of time. Avoid title attributes. Really think twice if you think you need them. Windows high contrast is one of my favorite topics. I’m showing on example of sort of a custom form styling page. This is old. This was developed by one of the Twitter guys. And this is a styled select drop-down and it’s fairly accessible. It uses an actual select with actual options. It does everything a select does but it looks funky. In Windows high contrast, it looks like nothing. You can’t tell what it is. Be careful of styling custom form controls. There are two things I can always tell people to do that should just work without having to use special high contrast media queries or anything. One is you can always put a transparent border around the element itself. Then, people can see where the hit area is of the thing. And you can use a transparent outline on focus to show, “this is what it looks like focused,” because the original uses a box shadow. I didn’t take a screenshot of it but box shadows don’t show up in Windows high contrast for good reason. Here we can see what the thing is and we can see that it is focused. But, we’re still missing the arrow. And for me to know that this is a drop-down, I have to see that arrow. That arrow is a very important visual cue for me, but because it’s a CSS technique arrow that we’ve been using for years where it’s two transparent borders plus a visible border, we should use something else like SVGs. But be careful with SVGs. It’s very common for programs that people use to make SVGs to put in an inline fill or stroke color in the actual SVG code. Don’t do that.

Because you can’t guarantee that the contrast is good. What I typically tell people to do if the SVG has just one color, whether it’s stroke or fill, is to set the color you want on a parent element as a color property. And then have the SVG have its fill or it could be a stroke set to current color. Because what that does is as the high contrast theme changes text color, the SVG will come along with it and it will ensure the contrast is as high as it is for the text. Now, you might have an SVG with more color, in which case this trick won’t work. I say for those people to give their SVGs a background color. Normally, it’s transparent. If I set a background color to your SVGs that’s the same color as the webpage, then only high contrast users will even see there’s a background but that will ensure that the contrast is high enough and that the SVGs are visible. And States. This is a big one. People like to use color alone to denote states. I’m showing a log-in form with a disabled submit button, which I’m not particularly a fan of. But my high contrast theme here uses green to denote that things are disabled. So this person, made a button, they put in disabled and it works. But custom buttons are all the rage and here the developer attempted to do everything right. They gave it a role of button. They gave it a negative tabindex and set `aria-disabled=true` but aria-disabled is a thing for screen readers. It doesn’t show up for high contrast because the operating system of Windows doesn’t know anything about ARIA and it never will. But opacity is something that works. This has been my go-to suggestion for clients who say, “How do we show that our custom element is disabled?” You could lower the opacity, because it will look like this, which I think it works a lot. But what I want people to think about is, there’s lots of states that you need to be aware of. Use outline for focus states, but it’s very common for an error state to only change the border color of an input to red. Make sure that instead, there’s also a small icon, an SVG icon, and that the error message is close by and maybe the error message even says something about error. If you have a bunch of buttons and one of them is `aria-pressed`, you have to be careful that that pressed state won’t show up or if you make a custom drop-down where the currently selected item in the drop-down has a different background color that doesn’t show up in high contrast in addition to the background color, think of something else, such as perhaps that’s the only bold text option. Low contrast is something people hear about a lot. They are constantly hearing about contrast on Websites is too low. No matter how often you hear it, it’s just still a thing. It’s something designers really like because it looks professional or something. I have a link on my slides going to a discussion about the algorithm that is used for the WCAG luminosity contrast ratio because sometimes something will technically pass some color combination and everybody looking at it says, “But that’s not readable!” If we switch to something else that may help stop those false positives from popping up so much, but, if that comes, it’s going to be in the future. But, it’s a very long interesting thread, if you’re interested in that algorithm and where it comes from and what it might be replaced with, it’s a really good read. There is a new trend I’ve been seeing on several websites. The text has plenty of contrast. But the links are denoted with something that’s got practically no contrast such as yellow on white. Don’t do that. Egghead.io uses blue on white. Now here, from the text, we have the word, “Links,” above what are clearly links. This happens to be a page about Marcy Sutton. It’s got what are clearly her Twitter, her website, her GitHub, but how would you know the word transcript was a link? It looks like a heading. Don’t do that. Luckily in Windows high contrast, if you marked it up as a link, it will look like a link regardless of how badly it was styled. But, that doesn’t mean set everything to black on white or white on black. Very high contrast is not easy to read. It gets in the way of people with reading disabilities. It can be a problem for people with dyslexia. It can make letters look like they are jumping. I have an example of a designer I know who has low vision and she needs very, very, very low contrast to read stuff. So her own Website wouldn’t pass the WCAG minimum but this allows her to read it. I do have a trick for people who want to really quickly throw on a low contrast widget. This is not a good thing to do. But, it can work. You can throw on an overlay and then have `pointer-events` set to none so that you can still click stuff. But most Websites that allow people to log in you can actually dedicate time to making a lower contrast theme, if you want. Some of the reading plug-ins will lower contrast. And I’ve seen it on a few magazines, online magazines, that expect people to spend a lot of time reading but it’s more common to find a high contrast plug-in than to find a low contrast plug-in. And lastly colorblindness is something we know about. We hear about it. And we keep forgetting it. Because stuff like this keeps happening. I don’t know how many hundreds of people were involved in setting up a big American football game but nobody noticed the problem with red jerseys versus green jerseys on a green grass field until after it was on television where people call in saying I can’t tell who is on what team. Or, for developers showing if a build is passing or failing. Using only color instead of additionally a symbol, an icon, or some text is a bad idea and we keep still seeing color alone to be showing some information. Don’t do that. Here is an example of a switch I found. They are clearly trying to imitate Apple’s little checkboxes that look like switches. But first of all, if I can’t see the colors, which here they do have green for when it’s on, and there is a directional difference, but I can’t remember which direction is the checked direction because I’m terrible at that and I don’t have any Apple devices. And if there was something else like a check box or something, some check mark that let me know, that would be better but this was pretty bad. I couldn’t look at it and just tell is it already selected or is it not selected. And in Windows high contrast, it’s actually completely invisible, except in these screenshots, you can see a border around the track because I’m focused on it with keyboard. Otherwise, it was completely invisible. Once you decide you want to make a custom control, you now get the responsibility of ensuring that it is as visible as the default native control. Don’t do that. So, what should we do? Long list. I don’t think people are going to remember all of these things. But I do hope that some of these things are in mind. Do mobile responsive, but keep in might that height can be just as important as width because almost all media queries I see are based on width of the viewport, but height is also good and you can test with browser zoom. If you use Flexbox, check the containers by zooming in. At some point, something might go off screen. Let the stuff wrap. Designers, when you’re designing the general page look, use visual landmarks. Use consistency in things like alignments, distance between headings and stuff that they head and use white space. It’s very important, but don’t use huge crazy amounts of it, please. Don’t use auto focus unless the page has one dedicated goal. Like, if there’s also a footer full of links, that’s fine. But a log-in page can have auto focus. But a page that happens to have multiple forms, no. Don’t let me tab on stuff I can’t see. Make feedback local. So that if it’s on the edge, I didn’t miss it. Think twice and then think a third time before removing keyboard focus styles. Kill all stickies, please, for the love of God, kill all stickies! Make sure tooltips or anything that shows up on hover is hoverable and dismissible. Keep Windows high contrast in mind. Use decent contrast. Stop forgetting about colorblindness and just test everything. Almost everything I’ve shown, with the exception of stuff viewed through a third party expensive screen magnification program, is stuff that anybody, developer or designer without accessibility knowledge, can check for, so I would love everyone to try zooming in, check the stuff, make sure it still works.

And that’s my talk. >> MICHAEL BECK: All right, thank you, Mallory. Excuse me. It seems like I’ve got a frog in my throat now. Anyone have any questions? Just go ahead and throw that up in the chat box if you do. Nope? Okay.

>> MALLORY: That means everyone fell asleep.

>> MICHAEL BECK: Here we go. Doug asks if you have any good example of SVGs? (Chuckles).

>> MALLORY: As far as SVGs that look good or…? I mean mostly what happens is when I’m testing a page or viewing a page when I turn on high contrast, a lot of people have dark colored SVGs, dark gray or black on a white webpage and they look fine, and when I switch to high contrast, I never use the white, there is a white contrast theme, but whenever it’s dark, I have dark gray symbols on a black page and they are invisible. They are just gone. Most of the time I’ll check to see is there an inline color actually in the SVG or sometimes somebody will actually set the fill in the CSS instead of telling it to inherit from the current color. It’s almost always the problem when I run into it.

>> MICHAEL BECK: He specifically means a URL for an icon for low vision. A URL of an icon for low vision. >> MALLORY: No. I’ve seen people use media queries to switch their icons, which I don’t do because I think it’s a lot of work. But, I have not looked specifically for low vision icons, although that would be a good thing to look at is, if an icon has a lot of detail, it’s not unlikely that bits of the details might not be visible, in which case, if you have an icon that looks like a circle and another icon that’s a circle with a little tail, that might look exactly the same. And having more room, there’s a name for that thing that letters have, the gaps in the letters like the circle inside the letter A. The same thing holds for symbols. It has to be large enough that people can discern what that thing is. But I don’t have a URL. I never look for special low vision icons. I’m sure somebody has made some. Microsoft probably has some.

>> MICHAEL BECK: Yeah that’s a good point. Isabella asks, “I work for an agency that focuses on visual design. How can I work with them to ensure they don’t feel like their designs are being compromised, yet still be accessible?” She feels like when she says things like, “Don’t do parallax. Don’t do scrolljacking. Don’t do stickies,” she feels like she is killing their creativity and she wants to find options to work with them.

>> MALLORY: Yeah that’s difficult.

>> MICHAEL BECK: Any buzzwords that you think might help? >> MALLORY: Actually, when I worked with designers at Pearson, a lot of them asked, “Why?” or “How come?” And they all wanted stuff to be accessible. I never had to argue with anyone at Pearson to make stuff accessible, which was really, really great. I loved that. I never had to fight about it. What I could do is show people this is what my experience looks like. It’s a little difficult with ZoomText for example. It sits on top of your GPU and you can’t use something like Zoom or Google Hangouts and show the magnified view but I could use screenshots and I could say this is what I have. This is what your design looks like on my end. And I am a fan of seeing how much of the design you can keep and only adjusting it if certain things happen. For example, having sticky crap but once the viewport height starts getting too low, removing it, because at that point the page doesn’t look like the design anyway. Or for the SVGs people want a certain color. You can style it with a certain color, but if you do it in a certain way switching to high contrast theme, I get my own colors well. At that point, your design doesn’t look anything like what you thought of anyway, so I will try often to work with the designers to say, “What do you think are the options?” Some designers really thrive on having constraints and others don’t, but if they do, they usually come up with stuff: “Can I do it this way?” or “Can I do it this way?” If you’re lucky enough to have a direct dialogue with designers, let them show up with a bunch of crap, show them what the problem looks like, let them think it through and chances are they will come up with something where you can (say), “Do something like that and we can do this and we can do that.” Sometimes it’s, “Okay, let’s add a control to the page,” or “Make it a setting if somebody is logged in,” that has a different design but the default is still what they were originaly going for. I’m a huge fan of seeing visible text labels of indecipherable hieroglyphics on buttons. Designers love things on buttons. I hate it; I don’t know what they mean. If there was an option for me to click a check box that says, “Just show the visual labels,” like they have on Gmail. On Gmail, that’s one of the options if you’re using the CSS version, the fancy version, you can say, “Hey, I only care about icons because I’m not a good reader,” or, “I want the text with the icons.” It’s a setting. The original design was probably just with the hieroglyphics, but, with an option you can let people change it to yeah but I need the text or the other way around. Someone asked, I can see now what tools to use for zoom in a browser. Control-Plus and Control-Minus works with every browser I know of and often works with PDF viewers, as well. I once found a website for a blood bank that, it looked like it had a text enlarge widgets. It had a small A, a middle A, and big A, but when you clicked it, it was actually a link to a webpage that told you how to enlarge and shrink your text with your browser. It was brilliant. They don’t have it anymore, but I loved that, because people in my country are used to those little widgets for text englarge that you see on websites.

>> MICHAEL BECK: That is quite brilliant.

>> MALLORY: I wish they had kept it. I wish they had kept it. Because it was amazing, because now people, they go to click it, that means it’s the people who need that, they are clicking it and they get told, “Hey you can make all websites bigger text. Wow!”

>> MICHAEL BECK: It’s almost like you have to trick people into learning.

>> MALLORY: Yeah, nothing wrong with that.

>> MICHAEL BECK: Nothing wrong with that, at all. >> MALLORY: I wish I had showed scrolljacking, actually, because I run into pages that do that and when it’s done with Javascript, the problem is usually if there’s text anywhere near the bottom of the quote-unqoute slide they are showing, I can’t read it because it’s offscreen and I can’t scroll down. When I try to scroll, it’s gone, so, I only see a little bit of text. But, I know the CSS working group is working on making that a CSS property. I don’t know if it’s going to make it for CSS 4 as a module, but I know they are busy working on it and one of the things it would have is the browser would kind of automatically negate that scrolljacking functionality if somebody zoomed in, or it would do things to ensure that if the contents of the slide that have go outside of the viewport, that it would let you scroll down to the bottom of that slide before jumping you to the next one, which I’m looking forward to. When I first heard of it, I was like, “No we can’t have scrolljacking in CSS!” but, after I saw how it worked I was like, “Oh, this is great! This will be better.” It’s sort of like when they added placeholder to HTML 5, because most browsers still show the placeholder even after you focus nowadays, it’s better than the old JavaScript one where it would always vanish the moment you focused on it.

>> MICHAEL BECK: All righty. >> MALLORY: All of the slides, it’s just one big HTML page. If you went to the URL, you can just copy, it’s a folder. It has an HTML page, a CSS file, a JavaScript file, and a bunch of images, but we are working on sitting it on Dropbox in a way that you just want to grab the whole folder and download it. Michael is working on that.

>> MICHAEL BECK: Yep. (Chuckles).

>> MALLORY: Good. We’ll post that somewhere. >> MICHAEL BECK: Yeah, James had mentioned you can try to sell it as a challenge to the designers which you kind of basically said that in…

>> MALLORY: It can. It depends. It depends the designer. Some designers are…they like pushing the envelope, trying new things and they work better with constraints. There are other people who, that doesn’t work for them. They have certain things they want or certain things that a CEO or somebody or a client said they really wanted. And then it starts getting into hacks and shoehorning, so somebody gets what they want but somehow it can be made to work for somebody else’s needs. But, I think if more designers could see how stuff looks to those of us who have to adjust it and they see us struggling, or I believe it’s Basecamp, 37Signals, some company like that. Their rule was anything that anybody built they were forced to go into a room and watch users use it. I think every company should do that and enforce it. I don’t care if it’s remote video. You get to watch somebody go, “Where do I go next?! What does this thing do?!”

>> MICHAEL BECK: That is a great policy. >> MALLORY: Yes.

>> MICHAEL BECK: I mean, even just having someone, a designer do that once or twice is going to have an impression on them. >> MALLORY van ACHTERBERG: Right. It might get them thinking.

>> MICHAEL BECK: Exactly. Making them do it all the time is going to really get them thinking, though.

>> MALLORY van ACHTERBERG: Yeah, and somebody says something about calls to action. So with icons on buttons, I call them hieroglyphics because a lot of times I can’t tell. I’ve started to guess that the spiky circle is settings, but there’s a lot of them I just don’t know. I have another talk I gave about icons where I showed some quote-unqoute icons everybody knows what they mean. But, I found lots of instances of them meaning different things. So, again, the idea of, if you could then add a control where maybe the default was an icon, but there’s some way for a user who doesn’t understand it to go find the text. I’m a developer, so I right click on stuff. I inspect the element and try to see if there’s a class name or something hidden or maybe hidden stuff for screen reader users so I can guess what the thing does before I click it, because I don’t trust clicking stuff. But you can build that in, a check box or setting or something, where the default is still the general wish of the designers, this, because that is a good reason of icons make things clear and compact and lots and lots of text is pretty much the opposite of what you want for people who have trouble reading, for example. People with low literacy, people with dyslexia, often want less text. They want so minimum amount necessary to convey the meaning and icons are really great for that. But, there’s the other way around where, “Yeah, I can’t recognize what your icon means.” So, making the page as flexible as possible for people, that’s a sort of general thing in accessibility anyway. The user needs to be able to choose how they consume the content, how they interact with the thing, and the more control they have, within reason, is generally better, especially so long as it’s not really difficult to figure out how to get that control. A lot of the tools I showed, there’s a lot of people when their vision degrades all they do is stick their nose closer to the screen. They’ve never heard of a screen reader. They’ve never heard of screen magnification. They don’t know anybody that does that, the eye doctors don’t do anything about it, they never tell their patients, “Oh you could use this.”

>> MICHAEL BECK: Yeah, or at best they will have one of those giant magnifying glass overlays that go over the monitor.

>> MALLORY: Yeah, that works and you do what you do. People will do what they do and as your vision goes down…we are visual creatures and we will use every last bit of our vision even when it gets to the point where, to be honest, we would have been faster, happier, and more efficient if we just switched over to a screen reader. But if you have so much of your brain dedicated to visual processing, yeah, people are going to use every last little bit of vision. That’s what we do; we try to strain to see our little bits.

>> MICHAEL BECK: My dear mother only got reading glasses when her arms weren’t long enough for her to read something. >> MALLORY: That’s common.

>> MICHAEL BECK: Exactly. It’s very common. It goes exactly to your point that we’re stretching our vision to the limit. Even though we have all of this available technology to us. This old technology even, like reading glasses of all things.

>> MALLORY: Yeah.

>> MICHAEL BECK: But, yeah, the more people know about the tools they can use on their computer, the better.

>> MALLORY: Yeah.

>> MICHAEL BECK: There was one question in the actual Q&A thing. An anonymous attendee wanted to know more about stickies in regards to main navigation: one of your favorite topics.

>> MALLORY: Yeah stickies are my favorite topic. There’s even a GitHub issue mentioned by Wayne Dick, who is on the Low Vision Task Force at the W3C, who helped add some of the new WCAG 2.1 Success Criteria that’s focused on reflow. And he mentioned, “Boy, our How to Meet (the Success Critera) page should say something about stickies,” and somebody else, I think it was Jake Abma, came up with an example that either will be, or maybe already is, on either the Understanding page or the How to Meet the Success Criteria page. There’s been more discussion about it, when sticky things start eating up so much screen real estate. The guidelines will never be hard and set, though, because there’s too many possible combinations and the WCAG tries to be very technologically agnostic and doesn’t want to set anything too hard. A rule of thumb is like, if something sticky takes up more than a quarter of the visual viewport in a zoomed in browser, for instance, then that’s starting to get to be too much. But, some people are okay with something taking half the room. I don’t like it, but there are other people saying, “That would be okay blah blah blah.” The reason people make stuff sticky is that they want something to be available for mouse users without having to do a whole lot of movement. For example, if you’re a mouse user with limited mobility, where using a mouse is difficult but you do it or use a head mouse, having stuff at a close distance is an accessibility improvement, but for low vision person zoomed in, it’s a pain in the ass. And that’s why I like the idea of, “if the viewport has certainly smallness to it, then maybe we’ll let stuff just scroll by.” So it doesn’t remove it from the page, but it becomes position static, if it’s at the top of the page, that’s where it is and I scroll away from it. Or if it’s on the left side of the page, I scroll away from it. Or if it’s at the bottom, I only see it once I get to the bottom, something like that.

With cookies, I almost want to tell people, always put your cookie warnings at the top of the page but also the first thing in the DOM order, so my first tab goes to the stuff for closing it. Because if it’s at the bottom in the source code, I can’t get to it very quickly on the keyboard unless you automatically move focus to it. I’m of differing views on whether I like auto focus on cookie warnings but some websites do it because they stick the cookie warning as the last item on the source and then you have to tab through the whole webpage to get to it, so they do that.

>> MICHAEL BECK: Charles just asked for a little clarification on stickies. Do you mean the CSS feature of position sticky or position fixed or something else?

>> MALLORY: It’s both. Position fixed is almost worse because you can’t scroll from side to side, for example. If you go to LinkedIn, I believe it’s position fixed at the top of the screen and the thing has a width and you can’t scroll to the right. Position sticky is a little different in that the idea is something starts off not with being fixed but once you scroll away it switches to fixed. I mean both of them because the end result is, I have something in my viewport that I can’t get rid of and if it gives you the same effect of you stick Post-It notes covering part of your monitor and can’t see the rest of your page…if that’s the end effect, it will get rid of it. Those techniques are slightly different from each other but the end result is what I care about and usually the same type of media query works for both.

>> MICHAEL BECK: What would you say is a good alternative to stickies or position fixed?

>> MALLORY: I guess you could ask why you’re fixing stuff. For example, I see social media buttons are sticky on a lot of article websites, news websites. Because to them, they may have some kind of an earning thing, money earning thing, with getting people to click on those and share stuff. Whereas I always have to go into my developer mode and display and delete the things from the DOM so that I can read the text that’s underneath them. And my thing is, if something has to be sticky when people are zoomed out, I just don’t want it to be sticky. Like position it with CSS in the place where it’s supposed to sit normally, but if I can scroll away from it or if it can’t cover the other text, that’s my main thing. It’s not really a replacement because the whole point of sticky is to act like a Post-It note stuck to a monitor and it depends on your reason for doing that. A lot of news sites do it because they want you to always see the name of the site they are on. You could argue that could have a cognitive benefit. And when you’re zoomed out some of them are quite small they don’t look like a big problem because, what is it, the Wall Street Journal or somebody? Some of those sites, they have this real thin little header at the top that doesn’t look like a big deal. But, if you zoom into 400% and it’s suddenly covering half your screen, you know, that’s not cool. Don’t do that. >> MICHAEL BECK: All righty. Well, we are coming to the end of our hour. And we seem to be dying out of questions. Thank you, Mallory, for not only that informative but very entertaining talk. I still love the slides that say, “No.” (Chuckles)

I have seen it in the Dutch version and, “No,” doesn’t seem to carry the weight that, “Niet!” does.

>> MALLORY: “Niet doen!” Yeah!

>> MICHAEL BECK: It just has this gravitas to it for some reason which you really can’t get more clearer than, “No, not do it!” Anywho, next month we’ll have Eric Bailey on, accessibility advocate and inclusive designer at thoughtbot. He’ll be on to discuss the intersection of performance in accessibility, highlighting the opportunities and techniques to improve website and web app performance by improving an accessible and inclusive mindset. I’m sure we have all seen instances where unnecessarily long and complex code that’s in there for God only knows what purpose is put in the production. And it affects not only the accessibility of the product but also the performance. But I know Mallory knows what I’m talking about. That will be on Wednesday, July 3rd at 11 a.m.. Again, Eric Bailey talking about the intersection of performance accessibility. Thanks again to Mallory and thank you all again for your attendance, your questions, your retweets, and general support of Technica11y. I really do enjoy seeing the numbers of the participants go up with each passing month and we have you to thank about that for spreading the word. thanks to Clare from ACS Captions and I’ll see you all next month.

Mallory van Achterberg

About Mallory van Achterberg

Mallory van Achterberg is a senior accessibility consultant at Tenon and lives in the Netherlands. She’s been busy with digital accessibility for over 10 years, loves scotch, and has been trying to paint her kitchen for the last five years.

Conducting Accessibility User Research: What’s Really Needed?

Transcript

[Intro music]

>> MICHAEL BECK: Welcome to technica11y, the webinar series dedicated to the technical challenges of making the web accessible. This month, our presenter is Michele Williams, Senior UX Researcher for Accessibility at Pearson’s Higher Education Division.

[Music]

>> MICHAEL BECK: Hi, everybody! Welcome to this May edition of Technica11y. I’m Michael Beck, the Operations Manager at Tenon. It’s May Day! The fires of Beltane have been lit and summer is fast approaching, for those in the Northern Hemisphere, at least! Today, we have the our very own May Queen in the form of Michele Williams, the senior user experience researcher at Pearson. Good morning, Michele!

>> MICHELE WILLIAMS: Good morning, how are you?

>> MICHAEL BECK: I’m doing well. Michele is going to be discussing something we have yet to delve into during our sojourns on the seas of accessiblity, and that’s effective usability research. Lots of times user experience research is performed at the front and back end of the cycle and, much like having accessibility in mind while developing accessible content, keeping the user experience in mind is really something that should be a part of every stage as we go through the cycle. So, as always, please add any questions to the chat box in Zoom and we’ll get to them at the end. And, without further ado, take it away Michele.

>> MICHELE WILLIAMS: Awesome, thank you, Michael! Good morning, afternoon, evening to everyone that’s joined and, “Hi!” to YouTubers later on. Thank you for having me and I’m really excited about this topic. The title of the presentation again is, “Conducting Accessibility User Research: What’s Really Needed?” I’m Michele Williams, I’m a senior UX Researcher focused on accessibility within Pearson’s Higher Ed but have done a lot of user experience type jobs and schooling all along the way. So, I’ll be pulling from a lot of those experience today as we walk through this. And just to go ahead and dive right in, I know this is a topic that’s been proliferating more, which is great. We do want to make sure that we are inclusive in our research on our products, our technology products, as much as possible. But we want to make sure that we’re doing it right. So, let’s see if I can get my slides to advance. Perfect. Really simple: “What’s really needed?” I’ll break this down into three main sections: “Knowing the Basics,” “Accessible Artifacts,” and “Accessible testing.” And we’re just going to get right to it.

So, “Knowing the Basics.” Basically, first and foremost, you have to understand disability. Now, the caveat for this presentation is I’m mostly focused on UX professionals or I’m assuming that you work with UX professionals, this is not going to be a talk where you can take this and go off without that baseline understanding of human-computer interaction and user experience. But, assuming you have those fundamentals, it’s still important to understand the diversity and manifestations of disability and what it will look like with the participants that you’re interacting with. There’s no getting around that. One thing that came to mind as I was putting together the presentation, I thought about the equivalent scenario of, say, there’s a community activist who wants to get feedback on a building.

They are revitalizing a building, they want diverse voices because this will be a communal space. They go to meet someone outside of that building who is in a wheelchair. They are like, “Okay, come on in! We want to make this an interactive talk,” and the person in the wheelchair says, “Okay, where is my entrance?” And let’s say that community activist kind of, their face drops because they realize the only way into that building is through the stairs. So, that could be the equivalent of what happens with our user research. We don’t just want to dive in because we may be diving in in a way that’s not going to allow the participants to be involved because something is not necessarily accessible to them.

So understanding disability and then also next understanding the laws and standards are going to be important, as well. You don’t have to become an expert, but again, you have to understand what it means for something to be or not be accessible. And I’ve broken this down because I understand that people might be using technology or building technologies all across the spectrum. So, web and applications that’s going to be, at least for the U.S., something called Section 508. Also the international guidelines, the Web Content Accessibility Guidelines (WCAG). Or hardware may again be Section 508 or the Americans With Disabilities Act. For somewhat voice telecommunication based, again Section 508 will have standards in there for you, but also the 21st Century Communications and Video Accessibility Act, the CVAA. So understanding the laws that are applicable to your country, applicable to what you’re building, applicable to the population you’re interested in interacting with, just having some understanding or even going out and getting training on those acts, on those laws, on those guidelines will be beneficial to you.

Also, getting immersed and I’m going to step through this one only because one great resource that I find that people may not be necessarily aware of, again, this is somewhat in the States but it’s likely applicable in other countries, as well, are Assistive Technology Centers. These are Government sponsored statewide centers focused on matching clients to assistive technology. Usually a state will have several in key locales throughout the state. And it is a service where people who have been diagnosed with a disability or are progressing, maybe they have a deteriorating condition, can come to these Assistive Technology Centers where they literally have all kinds of the latest and greatest hardware, software, and all in between, in the facility for the user to try out. They speak with an assistive technology professional and they match them and actually loan them assistive technology to try out before they go and buy it, which usually is an expense.

So, those centers are great places with very friendly people. usually with disabilities themselves. who want to be advocates and will allow you to spend a half a day. a couple of hours. or even a whole day. or come out to your facility and give a talk to explain to you what assistive technology is, how it’s used, who it helps, and it’s really educational, as well. And just fun! I like going and just learning the latest and greatest AT. So, that’s one resource, as well, for getting immersed. As well as disability organizations, we know that there are disability-specific national and local chapters of organizations but also check your local library; there may be accessibility meetups there. Literally, meetup.com sometimes has accessibility meetups and then there are again disability specific email lists and groups that may be publicly available that you could join or tap into to start to get immersed and understand the communities. And then lastly, industry professionals.

So, getting your training, getting your resources that happens through some sort of mechanism. And those industry professionals, whether they have a disability or not, are still going to be a valuable resource to help get you onboarded into again the populations or the general spectrum of disability that you may need. So, for example, orientation and mobility specialists. That is going to be the group that helps to kind of train on how to navigate the world accordingly, if you don’t have vision.

Assistive Technology Specialists, like we talked about at the Accessibility Centers. Rehabilitation Specialists. Whatever those key stakeholders are, they may be willing to sit down with you and have some communication to explain, again, the depth and breadth of disability.

And then, lastly, understand the current state of where your project is. So, for related work, if we go back to research that has been done prior, too, make sure you seek out any specific accessibility focused publications in that area.

So, for the ACM, the Association for Computing Machinery, they have a Special Interest Group on accessibility called Access. So you would want to not just look at Chi papers or CSCW papers, but Access papers, as well. For higher education, there’s AHEAD. They have a conference called Higher Ground. So, specific accessibility related publications, journals, conferences, you’ll want to seek that out and learn from related work. Also, understand the competition if you’re making a product that has a similar or competitor product to it then you’ll want to go ahead and evaluate it for its accessibility and understand, maybe even use that, in some of your early evaluations with users. And then, finally, what’s your baseline? Particularly if you’re revamping something that’s already in production, go ahead and get an accessibility consulting firm to come in and give you a formal audit of your product.

So, that will help you to understand what’s maybe an issue and why and how you go about fixing it so that you have that baseline understanding. If we go back to my example of the person who is brought to the building, if that community advocate understood ADA or it had someone explain ADA to them, they would have already known that that space was not going to be conducive for having a person in a wheelchair and meet them there. They could have then altered how they wanted to meet up with that person.

So hopefully that’s kind of making sense there.

The long be and short of that is this, the user testing is not an audit. You are responsible for testing accessibility. Your participants are testing usability. And that seems kind of obvious but actually it happens a lot that people think I’m, for instance, bringing in participants to test the accessibility of our system: that’s not true. I’m bringing in participants because our systems are accessible and now we’re trying to make sure that those systems are user friendly, understandable, all the other attributes that we’re using are bringing users in for who don’t have disabilities. So that’s why it’s going to be key again to understand accessibility, understand your baseline with an audit, and then proceed from there.

So, “Accessible Artifacts.” I’ll call them artifacts because I know people are working in different technology spaces, but ultimately, you’re user testing something, some thing, some object. And to borrow a little bit from the diagram that’s sort of a similar user experience diagram from Jessie Garrett, the Elements of User Experience, he has an arrow in his diagram of abstract to concrete, representing the project phases. So, we know that project phases, outside of UX just in general, even when putting together podcast presentations, they move from abstract to concrete, so from high level ideas all the way to finished product. And in between, those artifacts look the same, so you have something that’s just a high level idea. Maybe you move to sketches, then prototypes, and finally your final product, as you’re moving along that spectrum of the project phases.

So, the key question is, “What’s needed to conduct successful inclusive research with these artifacts?” As Michael introduced in the beginning, a lot of times research tends to happen at the beginning and the end, so when you have high-level ideas and when you have a finished product. But we can also do research all along the way with users with disabilities the way that we do users without disabilities.

So, some considerations for your testing artifact, just to keep top of mind as you’re going about to use your artifact, does it require clear, usable vision? Sharp hearing? The ability to talk, the ability to walk, the ability to stay focused or just in general staying focused? Grasping objects?

If your artifact requires these things, you’re going to need to start to pivot because hopefully you’re seeing that what you want is to make sure that your artifact can be used by a diverse population which means it can’t be a requirement to have certain physical abilities.

Now, in the ideas phase, again, that’s just high level. You have a scope or project in mind. You want to validate the idea. That’s going to be more concerned with the method of research rather than the artifact itself; there is no artifact at that time. So we’re going to revisit that one in the next section.

But, once you start to get to the sketching part, it’s important to keep in mind to go beyond, and I put in quotes, “paper.” Meaning something that’s either actually paper based or the equivalent of something that’s just very visual based, because again, you’re going to leave out certain populations when you do that.

So, in the columns on this slide, the first being web and application, instead of going maybe paper based, try to leverage accessible technologies like Microsoft Office to increase compatibility with assistive technology. If you go a little more digital and a little more digital and accessible, then someone who uses assistive technology, for instance, is going to be more able to participate.

“Hardware.” If you’re building something, use inexpensive three dimensional objects that users can both see and more easily manipulate, like Play-Doh, styrofoam blocks, 3D prints. Again, you may still be sketching as a designer or someone who is creating this, or your design teams may be doing that, but in terms of what you’re presenting to users, it’s okay to go ahead and try to get those molds a little more feasible to use so everybody has an opportunity to participate, so if somebody doesn’t see paper or paper would be difficult for them to manipulate, you can still give them the opportunity to independently give you feedback in another way.

And for voice-based systems, the only thing that really came to mind, there’s so much text-to-speech technology out there just keep in mind those technologies and being able to leverage those while you’re, again, going about your sketching. As well as, again, leveraging any comparable products that you could use or anything that is existing and accessible that you could start to bring in to get that feedback at that sketch phase as well as maybe cognitive walk throughs and talking through the idea, as well.

Then, as we move to prototypes, we’re getting a little closer to the real thing, so we’re making more realistic artifacts. Well, for web and applications, you’re really going to want to start to create throwaway code, meaning code you’re okay with throwing away if it doesn’t work, but code nonetheless. Because we need to be careful of tools that call themselves prototyping tools, they are not going to yield accessible products, meaning they may yield something that most users can use, but once you start to introduce that, someone needs to use just a keyboard to navigate or their voice to navigate, just a screen reader or some other assistive technology to really bring in some of the information like on the web, then those things are going to start to break down pretty quickly. Essentially, some of the prototyping tools create the equivalent of a paper prototype. You want to be careful saying, “We’ll use this.” Really investigate what you’ll use. The way that we sloved this at Pearson is to create a prototyping team. I know it’s not always feasible, but I recommend it if you can. Also, for hardware, you’re going to want to go to the closest equivalent. GoPro cameras, tablets for computer monitors, if you’re making something like, for kiosks, get to as close as equivalent hardware that’s okay for your population to use, and, lastly, for voice, again, leveraging, maybe creating, those realistic voices and also the existing accessible telecommunication devices, SmartPhones or, again, mobile devices that will help you to get your feedback on a prototype.

Now, I’m going to take a moment here and actually really delve into one research method known as the “Wizard of Oz.” So we’re not going to talk about the movie, moreso the research method. The Wizard of Oz, as I call it, is a “fake it until you make it” testing method. So, it’s a method in which the users think they are using a real system, but the researchers are creating that illusion. This is a really powerful method in general, but also for creating accessible technology, where we know that there’s a lot more consideration sometimes that needs to be put in, particularly if teams aren’t 100% familiar with what to look out for. Before you, again, start digging really deep into coding and all of those or manufacturing, Wizard of Oz can really save you a lot. Now, it takes a lot of planning and a lot of detail to run, but it can be worth it, particularly if you’re going to run it multiple times; the setup and scripting time may be worth it.

I have two examples times that I’ve run this it that actually aren’t related to accessibility research but to explain more about Wizard of Oz and how it works. The first is back at a previous job, I was a voice user and interface designer for what’s called an IVR, interactive voice response. Basically, the telephone systems where you talk to a computer instead of a person. I know, I’m sorry. But I worked on those early in my career and we used Wizard of Oz a lot to test our script. Now, this was back in the day when people, first of all, worked in an office and, second of all, had a landline desk phone. Those things may be becoming more and more obsolete but leveraging that desk phone, all we did was had the user dial a program number. We’ll save you from keep dialing 1-800 whatever; just hit this button. That rang to someone’s desk phone and the designer acted out the script. So, we would put on our best voice talent voice and pretend we were the system that the user was navigating through. By doing that, we were able to get interface validation before all of the big production of getting the actual voice talent to record all of that and do all of the development. So, in the background the designer had a spreadsheet, either in Word or Excel, whatever their preference was, of what they should be saying based on the user’s responses and then, of course, if there was something went wrong or if the user used a touch pad and we weren’t able to detect what they pressed on the phone versus spoke, then we had a failsafe of, “There’s an error,” and then you hang up. So, a useful technique, particularly for voice based interaction. And similarly, I believe this is known, that Pearson is coming out with an Alexa skill and one of the things we were planning to do and we didn’t quite run it but I knew it was going to work was test out our Alexa skill with users. At the time, what we wanted to test not only was the path, which I helped write because I was a VUI designer, but, we tested the path but also what users would expect to say. So, when you’re designing something you have to design what’s called the grammar: the response that the user will say. And for the Alexa apps and some of these home assistant apps, they wanted to be smart where you don’t have to think so much about the command; it just knows what naturally you would want to say. We were still struggling to know what users would want to say. Also, with Alexa, there are some global commands and we didn’t want a user to accidentally say one of those global commands and come out of the app that we had built up and say, into the Music or some other app, on the actual device. So, my suggestion: there’s a lot of speakers that look like Amazon devices. Let’s just have them talk to the speakers. Now, it wouldn’t have the little blue ring, but you can kind of play it up, like, maybe the light is broken or something like that, if they really understood what the Alexa devices look like. But, in the meantime, we would have the developer in the room, because our researcher and developer could be in the lab, and the developer looks like someone who was taking notes, but they could play the files really. So there was a simulator for Alexa, so you could record all the phrases that Alexa was supposed to be able to say and have them, again, in a spreadsheet and have it connected to the Bluetooth and then you would just play the appropriate file based on what the user said so with that we could determine what users wanted to be able to say and get our grammar and keep the study under control by preventing deviations.

So, those are just two real world examples. I also did a really complex one related to accessibility testing, but it was so complex I don’t remember all of the setup, but it had to do with simulating a navigation device and we had a combination of microphones and GoPro cameras and we used an AAC alternative and augmentative communication device for text-to-speech. It was really complex, so you can get really detailed in how you go about doing Wizard of Oz, but I just wanted to make a note of that and kind of detail a little bit to say that.

But, then lastly, once you get to the final, the real full product, it has to be comlpliant with whatever the appropriate standards and laws would be for your technology. The long and short of it: that product needs to be baseline accessible, meaning it meets the baseline standards. Going back to what we talked about in the first section, so, if your system is not accessible, you need to work with other methods and work with your auditors and contractors until you can get to that point because we want to be cautious about bringing in users to test what is essentially a broken system. If it’s not accessible, it’s broken. You can have consultants with disabilities work with you on how to fix a system you’re working with or make an update, but that’s different than user research, even though that person may have a disability and may be a user of, say that assistive technology, their expertise is going to be so far out that that’s not going to be a reality of a user that you would typically bring in. You still need to bring in users that don’t have that kind of knowledge to test your system for the requisite usability standards.

The long and short of that: what the user is testing needs to be accessible. That again seems very basic, but that actually happens a lot with me, as well where people are asking me, “We really need to do user research,” and I’m like, “Yes we really do! Give me something I can research with,” and then we kind of have to have a discussion after that.

So, the last section does have a lot in it. I may bounce around a little bit just for time but, again, it’s about accessible testing. So, the first and foremost being the research methods. Most research methods, you’re just going to run without special caveats, but I went through a list to point out just a few things. I’m just going to bounce through this somewhat quickly.

These aren’t in any particular order other than alphabetical. So, one that came to mind is Biometric Testing, which is gaining some traction. So, eyeytracking or other emotion based testing. Some users just won’t be able to do that. They won’t feel comfortable with the instrumentation. They won’t be able to sit in the way you need them to. They don’t use their eyes to navigate the computer. So, you’re have to come up with equivalents. I don’t have a good answer for that just yet. I haven’t sat down and thought about it entirely other than to say you just need to be equally as thorough for that if you’re going to use biometric testing and you’re going to have to have triangulation of your data, not just biometric testing, if doing inclusive testing. For card sort and tree testing, just make sure it’s an accessible tool or leverage accessible drag and drop to do that. That will be a theme: the tools, just like artifacts you’re using, need to be accessible. When I say accessible, it’s WCAG compliant if it’s on the web.

Diary Study. I love diary studies. Just have multiple means of collection. So, there are a lot of tools out there that do diary collection. Unfortunately, most of those tools won’t be accessible to all populations, so just be creative. They can use email, voicemail. They can send you or upload videos. They can do Word documents. And, just a note, blind people can and do take photos, so blind people can do diary studies, as well, so, that’s just a note to put in there.

First Click Test. Again, you’ll want an accessible webpage, not just an image of a page, and also you’re going to want to detect keyboard events as well as mouse clicks from assistive technology, such as a voice dictation software. So, again, the key is be careful of the tools you’re using. Just a caveat, again, some of this may be foreign. This is mostly for UX nerds on the call, so they will know what I mean by these different research methods.

For Focus Groups, you want to make sure everyone has opportunity to participate. Understand if there’s a need to have alternative communication styles represented and also consider an alternative to just a live or remote focus group presentation. Maybe use a chat room or group forum where people can still bounce off ideas but it’s more passive than active and asynchronous.

With Observations, know that if you’re doing an observation in person, like you’re following a person along in their daily life, just notice you’ll probably look like an aide. People are going assume you’re some sort of aide to that person; it happens. So, with that, you may want to consider instrumenting the participant with a video. have them carry a GoPro camera around, or do video on their phone as opposed to being present if the idea that you’re going to be seen by others may impact your data collection.

Participatory Design (Code Design, also). That’s when users are creating artifacts. You may have to create the artifact on behalf of your participant if they can’t physically do that themselves or just to save time. But, if you have to do that, then make sure you’re getting explicit confirmation from that user that you are representing that artifact correctly, you’re representing their idea correctly, and maybe even consider leaving that artifact with that participant or with that group so that they can reflect on it and maybe even have a follow-up interview afterwards. I tend to do that with a lot of research. I’ll do a follow-up afterwards after people have time to think about what you asked them, particularly in foundational research.

Online Surveys. Again, an accessible compliant tool. You’ll also want to minimize the use of really complex question types. Try to keep it basic and easy to enter and also carefully word your demographic questions. Keep in mind that not everybody are identifies as having a disability. So to ask someone, “What’s your disability?” may not be appropriate. Particularly, I think about the deaf community. They are not hearing impaired. They are deaf. So, be careful how you word questions like that as you’re doing your demographic collection.

And then, finally, Usability Testing, probably our most famous kind of testing in the UX world. For usability testing, one thing to keep in mind is that participants don’t want to look helpless. What I mean by that is if a person is struggling to use your system, there may be a tendency to really want to push and figure it out because the person doesn’t want to feel like they can’t, when really you need to just keep reassuring them that, “We know that and that’s absolutely true. Our system is the one that’s giving you issue, not the fact that you don’t know how to use it or you don’t know how to use your assistive technology.” So, just be mindful of the fact that if someone starts to struggle; there’s kind of an additional layer to how that may manifest.

In terms of unmoderated usability testing, I know that that’s, you know, a thing. It makes sense for some testing methods like surveys, but generally, I don’t do unmoderated and really try to make sure I’m present either remotely or in person. Because research is also educational.

So being able to have conversations around what a person is doing, why they are trying certain strategies, that information is useful beyond that specific research and can be educational to the team. Also, keeping in mind the measures of success, so like time on task is a big measure for usability studies. That may not be applicable if you have a diverse population. That may only be applicable if you have an exclusive population because, again, if someone is, say, using a joystick, they will naturally take longer to do a task, so that time on task measure may be skewed.

Same for System Usability Scales and Ease of Use metrics. You may need to separate those out, as well, because a system may be easier to use by one population but not by another. Like, maybe the blind users have a lot of difficulty, but mobility impaired users do not.

So, a synopsis of research methods can be found on the website. I have a link in the presentation there in Zoom and the presentation will be made available on SlideShare. I’ll talk about that a little bit after but some of these links that are present you’ll have access to.

Lastly, a few notes in terms of research methods about communication.

So, use interpreters if needed. Like right now, we have a captioner on our call today. So, determine if you need sign language interpreters. And if so, does that person or the people that you’re bringing on, do they have recommendations for who they want to use? And also offer to pay for that service for them.

And if someone has a speech impairment, determine if there’s a caregiver who can maybe help relay the messages on behalf of that person so that you can understand the interaction. But also be prepared to type. I recently did this as well. I had a participant who was hearing impaired. She could speak to me but I typed my questions.

So you’ll want to just be prepared for that. And also understand that overall, your protocol is probably going to take more time in general because of these just extra bits, communication, using assistive technology, having to just level set. So, keep those things in mind as you’re getting ready to conduct your research.

So, wrapping up here on a few more topics, recruiting is a big one. I don’t have a whole lot to say there other than there’s generally two ways to do it. One is relationship building. That happens over time. Those same resources from the earlier slide where you learned accessibility, the same resources you can use to get to know people that can participate in your studies.

The downside to that is you may limit your pool of participants. So, it may be that only certain personality types or only certain kind of people are involved in those kind of organizations. So you may want to be careful about whether or not you’re really getting a diverse look at a certain population by using some of those communities that are available. But, nonetheless, those communities are available to you. And you’ll want to look again locally as well as nationally and start to get involved. It’s a snowball effect. But you can do it.

The other way is to use a recruiting firm and that’s sort of the thing that I’ve taken. Because I’m not looking at one particular population. I need diversity all the time. But also, the downside to relationship building is we don’t like what we call “career participants.” We don’t like to use participants over and over. So, it feels difficult to build a relationship with an organization and then say, “Okay, great, I used you one time,” or, “I used these set of people one time and I really can’t use them again.” So it makes more sense to use a recruiting firm because they have a group of participants at the ready who are being used by different companies but for me it allows me to get unique participants. And the one that I’ve used most frequently, so far, is Knowbility. They have a database called Access Works and they have been really beneficial toward me in finding unique participants but the downside to that is they may not have a specific demographic I’m looking for because there’s more breadth than depth.

There’s a reality to recruiting, though, too. Minority group, I just call them Minority Group Implications. One, we talked about that people may just not be signed up for organizations. So, national XYZ organization does not encompass every single person with every single disability. So, you still may want to try reaching out to key stakeholders, but that takes more time, so reaching out to industry professionals, who can then reach out to people with disabilities, that extra layer takes more time. But, also, people are still breaking boundaries and barriers. I had the example of Haben Girma. People are still being the first to do something. So, if your product has a specific person population of user, it may be that the person with a disability has not yet risen to that level and that’s the reality of it, so you want to be mindful of that, as well. There may actually just be a small amount of people that you can recruit from. But, still try to recruit and to overcome that, use appropriate proxies.

So, I have a paper later on, I have a related works section later on, one proxy that may be good for you is older adults. So, older adults might make a great proxy for your studies in terms of having a disability, as well as being available, and giving you similar feedback to what you may be looking for. And it may be easier to recruit.

Also, maybe you’re not going to meet all of your research criteria. So, in my case I work with higher ed products, well, technically anyone can go back to school at any time and depending on the product, I sometimes have to make the decision that this is not going to be someone who is currently enrolled in college. It’s just going to be someone who can understand a college level product. And that way I can have a larger pool of people to recruit from.

So, I know recruiting is a thing. Keep working at it, you can do it.

In the Logistics, just for time sake, I’m not going to go into too much detail here. I have it in the slides. The thing, again, to keep in mind is accessible at every touch point. From the consent form, the location, communicating that location, or the tool you’re going to use, I recommend Zoom, the system that we’re using right now, as a remote testing as opposed to some of the other testing tools.

Everything along the way needs to be accessible, and if you’re not sure, ask your participants. But, I also have, not only in my slides, but I have a link to another presentation from UXPA Boston, where there was a phenomenal detail about facilitating and going into that. So, I’m sorry if you joined to hear about those logistics, please ask questions, but I am just going to for time, kind of skip through that. The meeting place, the consent forms, again, the paperwork, even the payment system, make sure all of those things meet accessibility. Because, again, otherwise you’re going to leave out a participant.

Then finally with analysis and reporting, again, just very quickly, make sure you do your analysis in a way that you understand how to interpret. So, this goes all the way back to the beginning. You have to understand accessibility in order to understand how to interpret your results. And then, in terms of the reporting of that, make sure you include everyone. Everyone on your team needs to understand accessibility and your first person interactions with users are really going to be important for educating your stakeholders all throughout the company.

So, share out as much as possible. Create great videos. Use those videos to explain the guidelines that you’re asking your teams to adhere to. Really get down into what, really leverage what research really can be used for, but, also, make sure that your analysis is keeping in mind how your participants use the computer and then how that manifests into your findings.

Now, we may have time to go back a little bit but, the long and short of it is, accessibility user testing need accessible tests. The protocol and facilitation details, those are going to make or break the data collection. So, I have closing thoughts, but, I just went through that, just wanted to point out again related work. So, whether it’s some of the papers I’ve been involved in which will be listed on LinkedIn, which my page is public, so under publications on my LinkedIn, there’s some papers that may be relevant in terms of foundational research examples, methods on participatory design, recruiting, and then also a paper that I did here at Pearson on, “How do I know you know accessibility?” So, I did that with Mallory Van Achterrberg, so understanding what it means to know accessibility, but also the papers I mentioned earlier on user research and what you need to know from the UXPA presentation. Also using older adults as a proxy and this paper on large user pool for accessibility research and then, lastly, the Knowbility Access Work link in case you want to use them for recruiting. I just want to be sure I left time for questions before I went back to sections I didn’t delve into. So, Michael ,I’m ready for that.

>> MICHAEL BECK: Okay, before we actually get to any questions, I just want to make a note that I’ll have the links for all of those papers in the YouTube description once the video is up. And hopefully a link to the slides, as well.

>> MICHELE WILLIAMS: Yes.

>> MICHAEL BECK: Perfect. The first question that we actually had was while you were talking about MS Office: how do you utilize that in user testing in particular?

>> MICHELE WILLIAMS: So, I’ve never necessarily needed to do that. But, the way that I would envision it is, if you’re mocking up your designs, then instead of mocking it up in some of the other tools that may be available, one that comes to mind is InVision, mock it up in a Microsoft Office product, because that will give you some accessibility markup. So, headings, links, bulleted lists, those kind of artifacts, particularly if you’re talking about web or applications, that kind of markup will be available to you through Microsoft Office or a product like that. That’s not going to be available in some other tools. So, even if the person is understanding that they are not going through a real actual page, they can still navigate through more in the way that they typically would, like especially if they are using assistive technology or using the keyboard to navigate. So that’s what I meant by that. And hopefully that answers that question.

>> MICHAEL BECK: Okay. That makes perfect sense to me. Kind of that infrastructure is already there.

>> MICHELE WILLIAMS: Right. Leverage the infrastructure rather than start it from scratch or not having it at all.

>> MICHAEL BECK: No need to remake the wheel. What are the challenges of doing research in a user’s environment? I guess that would be more like instead of doing it remotely, going to a user’s…

>> MICHELE WILLIAMS: I do talk about that. So, physical spaces. So, there’s research that can happen in a lab and then there’s research that can happen in public and sometimes in the home or in their physical, in their environment. For that, I would say it’s actually not so much a challenge as it is boundary setting. So, you just want to make sure that you have the proper relationship with that person, that they are comfortable with you being in their space and in their environment. Then, particularly if it’s their home or something kind of intimate, you just have an understanding of what the boundaries are, like you’re staying in communal spaces, like their den or living room or kitchen, and not their bedroom unless you really absolutely need to be there. But I do find that kind of research, particularly if it’s foundational, and particularly if it has to do with the type of product that you’re making, is important to do. And usually users, particularly if you have that understanding, you have your proper consent form, and you have talked beforehand, they are very comfortable opening their home to you because they want to get that information out and it is important for them to convey maybe the scenarios that are important to highlight by being at home.

>> MICHAEL BECK: Okay. It sounds like a lot of the way to make this successful is to do a lot of groundwork beforehand, before you even get, obviously groundwork with the actual protocols themselves, but with the person themselves. Get to know them before you start working with them as a tester of something.

>> MICHELE WILLIAMS: Right. So, let me go through the logistics since we have some time. I just wanted to make sure that I wasn’t going to be right up on the end. So, I’m going to double back to the logistics part and talk about the planning stages because that’s absolutely correct. With any research, but particularly with accessibility research, it’s all about the planning. And walking you through from start to finish and considering the details of it as you walk through.

I mentioned at high level, but starting with even the consent form, a lot of times I’ve seen them as read only documents because they have a special footer or not marked up correctly and then they require a signature to do that, a physical signature. We can’t have any of that. So, we need to make sure we can either use email or verbal consent and it doesn’t require a physical signature. We need to ensure it’s readable by assistive technology, that the wording is not too legal or hard to understand. There’s a WCAG guideline about the reading level of documents. And we need to ensure that participants can give their own consent and it doesn’t need to also involve a guardian or caregiver.

The payment system on the backend. I’ve seen a lot of gift card systems, “Oh, yeah, log into this gift card system.” Is that gift card system accessible? And then also don’t compensate in payments that the participant can’t use. Just something, make sure it’s logical, something high level or cash.

And then, also: technical checks. Particularly if you’re doing remote testing, which I do often. I use Zoom. I have the user come on a couple of days beforehand we do a 15 minute technical check and that’s where I also begin to understand if there’s any communication needs that are going to be important to know before we start. So, I’ll understand if I need to type versus can speak. Can I see your computer. Can I hear your computer. All of that happens prior to.

And then, if they are coming into a lab, then you’re going to want to be careful about equipment needs. Are they bringing their own equipment? Or are you providing that? I recommend they bring their own, but, sometimes it’s not feasible, and if it really isn’t feasible to have what they need in the lab, then you have to go to where they are. Or if they can’t travel, then you need to go where they are. And then going back to physical spaces, if you’re meeting in a lab, making sure you’re giving street to door directions, making sure the space is ADA compliant and transit friendly, or you’re providing compensation for transportation to your space. Communicating the exact meeting point and making sure the space won’t cause any participant anxiety. What I mean by that is, is it quiet enough, is it easy to traverse and is the space itself comforting or does it feel like you’re being tested? Work with your participants on that. Explain the space. Explain the study. And let them tell you what they are comfortable with and what they are not comfortable with. And then again meeting in public, make sure that public space is agreeable and conducive to research. Make sure you know your boundaries or even compromise on a meeting space that the person generally frequents. If they are a frequenter of a library meetup, then meet at that library space as well. Things like that.

>> MICHAEL BECK: That leads to a question from Sandra: how do you learn to adapt and understand the speech from someone who talks or sounds differently than you’re used to.

>> MICHELE WILLIAMS: That’s just a skill that’s learned over time, I find. Because I really don’t know how I do that. But, most of the time, I am successful in doing that. But if you’re not, that’s fine. Just make sure that person aware and come up with a way to get that interpretation. So, again, they may have a close family member or a caregiver who wouldn’t mind sitting in on the study with you. And that person can interpret and make sure that that’s just something that you guys are going to do and know that from the beginning. Or you may have to do something that is more text based rather than live conversation. If you think that you’re going to just have too much difficulty communicating, then you may need to alter your research method to get that data a different kind of way.

>> MICHAEL BECK: That would be where that quick 15 minute Zoom a few days before would definitely be a big payoff for you. You would know almost right away.

>> MICHELE WILLIAMS: Yes and do that if you’re going to meet in person, too, so meet up with that person before you travel and meet in that space. Go ahead and understand all of that ahead of time.

>> MICHAEL BECK: Okay. What are the advantages of testing on a user’s own equipment as opposed to something you would provide?

>> MICHELE WILLIAMS: Every assistive technology, just like every other technology, has settings. So, first and foremost, is that that person is going to be comfortable with the keyboard layout? If they are using a device, there’s different keyboard layouts, sometimes you have the extra number pad off to the side or things like that. So, they will be used to the keys on their keyboard and how those feel and how they interact and they will have their own if that’s applicable to them and then they will have their own settings on the device. Also, there’s different assistive technologies. So, if we talk about screen readers, there’s three popular screen readers: there’s VoiceOver on the Mac, there’s JAWS, and then there’s NVDA. You may not have a license to the one they primarily use and that may throw off your testing, as well.

So it’s going to be important that you want the user as comfortable as possible and using your product in the way that they would typically use it. You don’t want to introduce artificial conditions by forcing them to use an assistive technology that they don’t generally use or in a way they don’t generally use it. There’s so many settings. Even if we talk about the height of something that’s attached to someone’s wheelchair or the other ergonomic considerations on some physical devices. I don’t think that anyone would be able to accommodate all of those different considerations in their lab, particularly not in any kind of reasonable amount of time. So, it usually is better if the person can bring that with them, to just bring that with them. You really shouldn’t be doing testing that requires a certain type of assistive technology to be used. If you’re designing to the standards, the point of those standards is that they can then work with any user’s assistive technology in those requisite settings that they have.

>> MICHAEL BECK: Okay. Well, we’re nearing the end. Unless anyone has any final quick questions.

>> MICHELE WILLIAMS: I just want to make sure…I know I went through… Just making sure again you understand, it’s an ecosystem. So your designers and developers need to know how to build accessible systems, the researchers need to know how to facilitate the research and interpret the findings. Your testers need to know how to test for accessibility and how people use assistive technology. Product managers need to prioritize accessibility and get it into the project. So, making sure it really does take a village to do this. But you can do it and you should do it.

>> MICHAEL BECK: It’s holistic. And it’s very odd hearing you say, “Oh, it’s computers! It’s holistic,” but accessibility is holistic computing. It’s making sure everybody is involved, not just the users, but from the get go, from the backend, from the frontend, making sure everybody knows what everyone else is doing and making sure everyone is doing it together and all of the pieces fit and that’s the definition of being holistic: making sure everything is fitting together. So holistic computing. Interesting.

All right. Well, thank you Michele again for that excellent and thought provoking presentation. Somebody else mentioned before it was very thorough.

>> MICHELE WILLIAMS: Oh good.

>> MICHAEL BECK: I agree, that was great.

>> MICHELE WILLIAMS: I hope so.

>> MICHAEL BECK: And thank everyone who joined us today.

>> MICHELE WILLIAMS: Thank you everyone.

>> MICHAEL BECK: Next month we’ll have Tenon’s own Mallory van Achterberg on to discuss designing and coding for low vision. That will be on Wednesday June 5th at 11 a.m. So thanks again, Michele and to all of you. And we will see you all next month.

Michele Williams

About Michele Williams

Michele A. Williams, PhD, is Senior UX Researcher – Accessibility for Pearson’s Higher Education Division. Sparked by exposure to accessibility during her Software Engineering Master’s program, Michele more formally learned to apply laws and standards such as WCAG while working as an Accessibility Analyst, then later learned to apply User-Centered Design principles towards creating accessible technology while completing a Human-Centered Computing (or HCI) doctorate. Her UX research with participants with disabilities is primarily found in the ACM Digital Library, and she guest lectures on accessibility and usability topics at universities, research labs, and accessibility community meetings throughout the US and abroad.

Dark Adventures in Mobile Accessibility

Transcript

[Intro music]

>> MICHAEL BECK: Welcome to technica11y, the webinar series dedicated to the technical challenges of making the web accessible. [Music].

>> MICHAEL BECK: This month our presenter is Shell Little, the Mobile Accessibility Lead at Wells Fargo DS4B.

So hello everybody and welcome to this edition of technica11y. I’m your host Michael Beck, the Operations Manager here at Tenon. I hope everyone who attended CSUN is fully recovered. I know it took me a couple of weeks to get back in the saddle, so to speak, but it was wonderful to meet many of you out there and I look forward to meeting more next time. It was my first CSUN and it was quite a bit overwhelming at times, but I still had a blast and learned quite a bit. Speaking of which, you can catch Tenon’s own Karl Groves and Job van Achterberg at AccessU in Austin on May 15th through the 17th and at the Accessibility Camp Toronto on May 18th. As noted at the beginning, this month we have Shell Little from Wells Fargo DS4B with us. Good morning, Shell!

>> SHELL LITTLE: Good morning!

>> MICHAEL BECK: Shell is going to be delving into something we haven’t explored yet on technica11y and that’s mobile accessibility. As I’m sure most of you know, even an operations guy like me, the mobile space is difficult to work in. There are things that…ahem…”technically” pass WCAG but are really bad experience for users with a variety of disabilities. And so to avoid more bad puns from me take it away, Shell.

>> SHELL LITTLE: Thanks Michael. Let me share my screen real quick…fantastic!

>> MICHAEL BECK: Oh, a reminder to everybody, sorry, if you have any questions, please throw them in the chat or the Q&A thing in Zoom and we’ll get to them at the end. So, take it away!

>> SHELL LITTLE: Awesome, thank you. So thanks, Michael, for that introduction. So today we’re going to be talking about mobile accessibility. So the title of my talk is “Dark Adventures in Mobile Accessibility,” because, as Michael mentioned, mobile is a tricky space to work in, so, if you are excited to hear about mobile stuff then you’re in the right place.

So real quick before we get into introductions, I’m going to go through my roadmap for the day.

So start off with an Intro. Going to move into the section called “Why?”

Why is it so hard? Why is mobile accessibility this dark scary thing? From there, we’ll talk about the WCAG criterion, especially a focus on the 2.1 update. Then, the large bulk of my talk is going to be just practical examples, things I’ve seen in the wild, things I’ve read about, things that kind of drive me crazy. So that will be kind of fun to go through, and then we’ll wrap it up with a conclusion and hopefully I’ll have enough time for some questions at the end. As Michael said, if you have any questions, feel free to drop them in the Zoom.

So a little bit about me. My name is Shell Little. My gender pronouns are she and her and you can find me on Twitter @ShellELittle. That’s where you’ll find me and get a hold of me the easiest because my email is a black hole! So I’ll save everybody the time, feel free to follow me, ping me, or tweet at me. I enjoy interacting with people when it comes to my talks on Twitter so if you are a Twitter human feel free to jump on there and make some comments and I’ll get back to you after my talk is done. I work for Wells Fargo DS4B, so I work for Wells Fargo Wholesale: business to business, bank to bank kind of thing. If you bank with Wells Fargo personally, you probably do not and will not ever see the software that I work on. So I work on the accessible user experience team. My team lead is Gerard Cohen who was on technica11y a couple of months ago himself. So, myself, I’m the mobile and inclusive design lead for our team. I’ve been with Wells for a couple of years now and really got thrown into my mobile position but leaned into it and I really love it, even though it’s hair pulling at times! I’m living in Seattle and partnered and all my children have tails and I’m very happy about that! (Chuckles)

>> SHELL LITTLE: As a side note, I’m a video game enthusiast, so if you had a chance to see the stuff I had from the GAConf, it’s really fun.

So, moving on. When it comes to mobile. there’s this kind of misconception that I’ve heard in the wild and I’ve read about online about the work around of, “Oh, it doesn’t work on our app but it’s fine because it works on the web!” So I just want to set the record straight and say the work around of, “It’s accessible on desktop,” does not cut it anymore.

We have long since passed that time where we are able to say, “Oh, just go to your computer.” Just the way that technology has evolved, the way people are accessing the web, the way people are interacting with your services, it’s time to no longer use that scapegoat. It’s kind of…it was rapid and fast with the way that technology is moving, but if we can all lean in and embrace that I think the world will appreciate it, especially people in the mobile space.

So why, “Dark Adventures?” Why this kind of spooky scary analogy? For me, I think of dark adventures and lawlessness and almost kind of dark waters because a lot of times, there are questions that I have in mobile or people have in mobile and there are no answers. There are no standards for certain things where I have a big question and I have nobody to answer those for me. There’s no standard for it. There’s no best practice. And it’s kind of exciting but also kind of scary at the same time just because we’ve got unchartered territory.

So just in general, we’re talking about dark adventures more just about the fact that we’re wading past the standards, you know the safe zone. You know, how I think about it, when you’re encompassed in these standards, you’re in this safe zone where you have tons of literature, tons of people doing it, people are talking about it online, you can read up on articles. You can have a service like Tenon come in and help, but, when you’re in this mobile space, it’s a lot harder to find those resources.

So, let’s jump into our first section: “Why is mobile accessibility so hard?”

There’s plenty of reasons why mobile accessibility is really hard, but for me I kind of broke it down into three major points. First of all, mobile isn’t simple. And that’s the dang truth there.

HTML does not equal native code. They are different spaces, different beasts. And the WCAG standards and mobile kind [of standards] have a interesting interaction with one another.

So what even is mobile? When you think about mobile, we think about cell phones typically. But do we think about tablets? Are we thinking about certain kinds of laptops these days? What really is mobile?

So, the W3C defines mobile as two different categories and I mostly agree. So we have got native applications, which a native application runs as a software application, uses the device’s built-in features such as cameras, microphones, location, et cetera. You would locate those applications off of Google Play or the iOS App Store versus something that’s a Web App which runs in a browser and has a common codebase across multiple platforms. And that does get messy because we have different ways to access these things and they have different features and blah blah. So, mobile browsers are an interesting thing. You’re able to access the web through these mobile browsers. So, you’re accessing web apps that are made to be consumed on computers but you’re actually doing it through your mobile browser and oftentimes, also you’re actively seeing peoples’ Web sites and information through another app. So Pinterest is famous for this. Twitter also does it Facebook does it where you’re not launching your own personal browser, you’re launching an internal, still wrapped within their information browser; it’s very interesting.

So that definitely muddies the water there.

And then also we’ve got native applications. So, we have native code. So code that’s specifically written for iOS versus Android. And then we also have HTML wrapped sites that are JavaScript bridge served up in a Web App format. It’s an application someone can download but really they are just consuming web code that’s wrapped and made to look pretty packaged for a “mobile device.” So, it gets complicated there’s a lot of different ways you can access this information. There’s a lot of different ways that you’re able to access the web. So, when you’re thinking about your users accessing your information, they could be coming from a mobile browser. They could be coming from a tablet that’s runs in OS that’s still technically mobile even though the screen is giant because how big tablets are these days. I personally run a Chromebook and I run WebEx on my Chromebook laptop. So, basically TL;DR, what we think of as mobile is just very broad. It means a lot of stuff. Back in the day, it didn’t used to mean so much but now, with the way technology has expanded, we are seeing something different.

So, next about the code, so HTML is not the same as native code and I think anybody who knows anything about development totally understands that HTML is not the same as native code. The way we know HTML5, DSS, and ARIA doesn’t really help you when we talk about PGP, Python, Native iOS. The things and tricks and tips that you know for building things accessibly in a web format, they kind of go out the window when it comes out to consolidated code.

So the way we design, develop and even the way that we test for these native specific native code is totally different than the way we do for HTML.

So some examples real quick. So, when we’re talking about iOS specifically: iOS headings, for example, there’s no hierarchy of headings it’s either a heading or it’s not. You can’t dictate this is H1 through H7; they are either headings or they are not. So, when we’re talking about things like serving up an application to a SmartWatch and someone saying, “Well we have to have an H1 on this, this SmartWatch has information on it we have to serve up H1,”…well, if it’s native iOS, there are no H1s. So even when we’re talking about testing or potentially accessing these specific native applications, we’re even using different screen readers. And I’m not even talking obviously iOS having VoiceOver but TalkBacks versus NVDA and JAWS on the web so you could be accessing the exact same code if we’re talking about say, a JavaScript bridge wrapped web application, you could be accessing the exact same code with a totally different screen reader that has absolutely different behavior, different orientation it announces things differently, so if you’re thinking about it as the way you would with JAWS or NVDA or an Android based app, TalkBacks are different, so you can’t think of them the exact same.

Zooming and enlarging text. So, obviously the web we control plus we zoom in and expand our pages and make text bigger. But when it comes to native code, we’re doing away with pinch to zoom. I personally would love to see the death of pinch to zoom myself. So, what we’re doing now is we’re relying heavily on the OS to handle the text size so the user themselves can go into the accssibility settings and change how big they want their font and the code, if done appropriately, should respond as†is needed. So, the way that we even zoom things and the way that we would build a native application, if you have a small box with content in it, you better code it in a way that if the text gets blown up 200% that nothing is going to break, it doesn’t pop outside of the box. It needs to be made in a way knowing that that text could grow quite a bit.

And then hover states. If you’re expecting your users who are, say, potentially accessing a news site, to hunt down links because, Oh, I have a hover state!” Technically that passes if you have your contrast up high enough it’s not color alone, you can’t expect your users to be able to hunt for underlines on links because there’s really no such thing as hover states when it comes to mobile. And the big thing is in most situations you can’t open the code up and see what’s going on. You have to rely on testing tools to tell you the story. So, I’m not able to open up the code inspector and check things out when we’re talking about 100% native code. I can’t simply ask my browser, “What the heck is going on?” I have to run screen readers over it and I have to use my best judgment and I have to do research and read into what’s going on if it’s iOS versus Android and that right there is difficult, especially when we’re talking about UAT environments maybe you don’t have access to the code. Maybe your development specifically for your native stuff, maybe it’s done in a different party, maybe it’s a third party company doing it for you and you don’t have access to that. So, it can be very difficult.

Last but not least, the WCAG 2.0 was not written for mobile. Now, obviously, it’s a great improvement from Version 1. A lot more prescriptive. Made to be broad. Made to encompass as many types of technology as it could. But WCAG 2.0 came out in 2008. For context, for those of us who have to think back to 2008, the RIM BlackBerry Bold that was the sexy new cell phone, the best selling phone everybody was talking about it in 2008.

So if that’s the kind of phone we were talking about, there’s no way the WCAG standards could have had any knowledge what was about to come, what cell phones would look like, or web applications, what even apps were about to look like because 2008 is when Facebook mobile site, not even their application, launched. The Facebook application launched in 2009, so the year the WCAG standards came out was the first year that people were able to access Facebook just alone on a phone, so that adds a lot of context when we’re saying, “I’m looking for standards for something super complicated in the double modal pattern that should never exist and uh we also have it wrapped in a JavaScript bridge on top of the fact that when I tap this button I’m sent to 100% native page what do we do about back button experience?” There’s no way the WCAG standard could have been equipped for that. Thankfully we have 2.1, so let’s move into Section No. 2 and let’s talk about the updates to WCAG 2.1 and how it applies to mobile.

So WCAG 2.1 has had several mobile related updates which is awesome to see. I follow the updates very closely. Had a couple of heartbreak moments with a couple of shift to AAA; it doesn’t make sense. You know, a lot of people were watching the March Madness. I was watching the WCAG standards. (Chuckles).

>> SHELL LITTLE: So while there’s plenty of standards…I can’t remember exactly how many are A and AA. I think it’s 12 standards, but, I’m just going to highlight a couple. I have five on the screen. I think I have five. Yes, I have five. So I have Orientation, Pointer Gestures, Motion Actuation, Target Size, and Reflow.

So first things first, let’s talk about orientation. Basically, Orientation says, “Do not restrict the view of the content to a single display orientation such as portrait or landscape.” Basically, allow your users to choose their own adventure when it comes to if they want them to be in portrait or landscape. Now, if you have already read through 2.1 and you’re super well aware, this is going to be a review for you. So, Orientation is super important because this criterion came to exist because people with motion, let’s see, there’s three different types of user groups who really rely heavily on this one, but, people with physical disabilities, especially people who have mounted devices, they have it in either landscape or portrait and to ask the user to constant switch the orientation of their phone is unreasonable. Now there are exceptions certain things require you to be in one mode or the other. Specifically the standards, they say keyboard application where you can play the keyboard, it wouldn’t make sense to have that work in a portrait mode. Orientation is super important to think about when we’re talking about working in the mobile space because a lot of times that doubles the wireframes for when you’re building something.

So if you’re not thinking about creating things and optimizing them for, typically for landscape zone, if you’re not thinking about that, you’re missing out on a big chunk of work. Now, yes, if things are technically responsive you can probably get away with it, but, a lot of times it requires some thinking and planning ahead which would require wireframing.

So Pointer Gestures: this one is involving fingers touching things or maybe things that mimic stylus pens, different types of touch targets. So, Pointer Gesturs, “Multi-point or path-based gestures can be used with a single pointer.” A big example people talked about a lot with this is maps. So, having to use multiple fingers to pinch and zoom and pull in and out. potentially having to drag in certain paths. Now, there are plenty of different work-arounds and exceptions. Some examples would be games. I can think of, like, Fruit Ninja was big one, people talked about you’re supposed to swipe your finger in a certain direction and without that the game would become unraveled. I would be interested in having conversations how to make that game accessible. That’s another talk. But, in general you have to be able to lean on your UI to be able to do these things. Google Maps they have a plus and minus zoom in button so you don’t have to pinch and zoom. Pointer Gestures are really important when we talk about legacy pages which we’ll talk about in a little bit. When things can’t or aren’t currently made to appropriately reflow, we can’t force users to be able to pinch and zoom and, pinch and zoom, as I mentioned earlier in the talk, I would love for pinch and zoom to stop. So it can be a problem.

For Motion Actuation, we’re talking about interactions that use device motion. We need to make sure those can be done with the UI. So, a great example, I remember when Facebook came out with 3D videos and I was on a plane and I was frustrated because I was like I look like an idiot waving my phone around on a plane full of people trying to watch a concert of some sort and trying to get the 360 experience. And eventually after they released it there was a way to swipe back and forth. If it wasn’t Facebook that came out with it originally, I can’t remember, there was another company that had, like, images where you were able to slide back and forth like panoramas. That’s a perfect example. Just allow your users to be able to swipe or put one finger, have arrows left and right, so they don’t have to wave their phone around because not everybody has that ability.

Target Size. Now, oh my gosh, I can hear the cries, “But Shell target size is AAA!” I know and I don’t really care that much so let’s talk about it! “Actionable items must be 44 by 44 CSS pixels.” Not too crazy. So the reason why Target Size is AAA is because there are certain things that are actionable items that is not practicable for them to be 44 by 44 or any sort of 96 of any kind. So, an example of that would be links, you know, in a sentence. You can’t make those ginormous because that doesn’t even make any sense. It’s also difficult because if you have two different ways, like multiple ways, to access something only one of them has to meet it, so that’s pretty good. But when we’re talking about it being AAA, understandable, maybe we can just talk about icons or buttons that are not X, Y, and Z variables because, when we’re talking about standards, both Apple and Google already have best practice standards of 48 by 48, so, if you’re following the Apple and Google standards then you have already passed the expected standards of touch target size. So the human interaction, the human interface guidelines from Apple recommends the 44 by 44 and then the Android material design guidelines, it’s 48 by 48, and then they have a recommendation of 7 to 10 millimeters in size so we’re talking about log-in buttons, cancel buttons, signout buttons, that’s pretty practical having these itty bitty teeny tiny little buttons, when you’re coming from the web going over to a browser, those buttons are tiny and it gets really difficult.

And last but not least, Reflow. Code should be responsive; it’s pretty simple. Make sure content doesn’t require scrolling in two dimensions. If you have a page that isn’t responsive and you have people scrolling left and right, up and down, that doesn’t pass reflow.

So, even with the updates mobile accessibility is still a lawless wasteland and that’s because mobile accessibility is difficult. There are so many nitty gritty interesting interactions that it’s just so hard to write standards for. So, it’s not the fact that WCAG standards aren’t good or they are not enough, it’s because mobile is really difficult and it’s difficult to write standards for.

So, let’s talk about a scenario real quick in the terms of responsive. So the rule being, “Cntent must be responsive.” So Reflow, it must have appropriate breakpoints. The issue I was talking about earlier, old legacy content does not wrap and break in mobile. I see that a lot in government, I see it a lot in higher education, and I see it a lot in older companies. You have Web sites. They are beautiful, they work, but they are not responsive. And if they are responsive, they are not responsive down to the breakpoint of a cell phone. That’s a big issue.

When we’re talking about it not being responsive, we’re breaking, reflow, which is no 2D scrolling obviously with exceptions such as tables, pictures, maps, diagrams, there’s plenty of examples. But that’s to 400%. Point Gestures: your user should not be forced to pinch and zoom. Maybe you’re able to get away with a double tap zoom, maybe it can work out. Then we also have the 2.0 standard of the resize text. So, that’s being able to ZoomText to 200%. So, if it’s not even responsive, it’s obviously not going to listen to what the OS has to say about changing text size. And then likely if your old legacy content isn’t responsive, it probably will not work in changing orientation or if it does, it’s just another view of the same giant website that people were scrolling around on.

So that’s a lot of fails right there just for a homepage that doesn’t respond and someone is accessing it through their mobile browser.

So you have two choices basically: make the page responsive or create a mobile version. Like good luck. That’s a lot of stuff. It’s a lot to do. Especially when we’re talking about legacy pages when there’s just a ton of them, even if it’s a roadmap to update it’s still a lot of content and that’s very difficult. And when we’re talking about just making willy nilly applications, users want to access functionality they have on the web with mobile and they want them similar if not the exact same. If you want to look at the iPhone store or the Google Play Store, if you want to find really, really angry users, look for Web sites that have apps that do not have the same experience, do not have the same functionality. That’s when you get angry users. So, we’re not even talking necessarily specifically about accessibility. Having differentiation between the two different experiences, that’s just not…nobody wants that anyway. o your best bet is to make things just responsive. Make them break appropriately. “Code responsibly,” as I’ve been told. And remediate them in that way because sometimes just throwing native code at something is not the answer.

So let’s move into Section Three. This is the last major section let’s just talk about some practical examples. Now, before I get into this I will say I am not a developer. That is not my strong suit. I personally am neurodivergent myself. So the programming that I do is limited at best.

So if anybody has any incredibly technical questions, I’m going to send you to Google or maybe someone else. But a lot of my experiences have to come with designing for accessibility and designing in mobile spaces. But also I do have some technical know-how, as well. I just wanted to preface that so nobody is expecting some big sexy page of code or anything.

So the first thing we’ll talk about will be camera functions. Now, camera function, we can talk about I kind of thought about two different things working in banking. Biometrics: that could be something like Face ID. Wells Fargo has its own internal Face ID, face recognition. You can Google it. There’s videos up showing what it looks like and how it behaves on the YouTube. So, you know having something that has camera functions or something like iPrint, Face IDs, those different types of different functionalities, you get the picture. And then in Banking. I know a lot of people love the fact that they are able to take pictures of their checks. And send them in. I bank with several banks myself and they all have that functionality. There’s also receipt capturing for business trips, for expenses. But also for a lot of the…I don’t want to say money saving apps…but financial apps that help you balance budgets and blah blah. They have, some of them have receipt capture as well to help you balance your checkbook, so on and so forth. But, basically, anything that’s forcing your camera to be used it could be scanning a ticket, a code, maybe a QR code.

So, basically when it comes to camera functionality, from my experience, what I have found from remediating different types of camera functionalities, from reading about them, from hearing from co-workers and people on the interweb, is Number One, “Information is key.” So, if it’s being displayed to your user, if something is happening and your user needs to know about it, it also has to be read by a screen reader. Any kind of tips, tricks, hints, anything that’s being informed: “Move your camera closer,” “Move your camera further away,” “It’s too dark,” “It’s too bright,” that kind of content, as long as it’s being displayed in a way that appropriately can be seen by people who have a vision related disability and also it can be accessed by a screen reader, that kind of information is crucial. Anything about moving your camera closer or moving it further away for someone who is sighted is monumentally more important to a screen reader user and screen reader users can use cameras successfully if we do our jobs right and plan ahead and we make sure these experiences are made for them in mind. So information is key.

“Simple is better.” So when it comes to things like cropping images or forcing users to take things at certain orientations, for example, the simpler you can make the camera functions, the better. It’s not too complicated. So I know for example some check picture things require you to crop. Some don’t. Now some users can’t crop. So if they can’t crop, what happens if they don’t? That kind of information. So if you can make it simple for them, then do. And then, when it comes to being simple, also automation. We’re talking about auto capture images, so it takes a picture for you. It also has auto flash and then anything basically auto, so, auto focus, auto flash, if you’re able to automate things and take the burden off of the user when it comes to camera function, that’s great. You should do that.

And then, obviously, give them options because sometimes auto capture is not good. If someone has a physical disability, maybe it takes them a little bit longer in the auto capture. It might be a barrier for them, so give people options. If they can’t get a good photograph in one way, allow them to try doing it manually. I know BECU app does that specifically where if you fail too many times they give you the option to just do it yourself which is appreciated.

Right, moving on we’re going to talk about Moving Content.

So, hopefully, I’ll get my slides up eventually, but at CSUN I gave a presentation on Pause Stop Hide and what happens with Pause Stop Hide. So, if someone has an attention related disability, moving content is a big deal. We’re talking about Moving Content. It’s funny I’m going to try to sum up my talk, an hour talk, in one slide, but I’ll try to do my best.

So when we’re talking about Moving Content, we have micro interactions, moving ads, and timers, tickers, scrollers. So, when it comes to mobile, these things get exacerbated because the screens are so little, so something that’s moving now is taking up much more real estate on a phone screen, so this moving content can be so much more intrusive, especially when we’re talking about moving ads in mobile which I’ll get into right now.

So first point I have is, “Pause Stop Hide. Are you there? Hello?” So, apparently, collectively, everybody has ignored that we have a criterion called Pause Stop Hide: “Content that lasts for longer than five seconds must be able to be paused, stopped or hidden,” and that includes ads for sure.

So, ad blockers: totally a thing! But if I’m accessing a Web site, say, I’m on Twitter and I select a link and it sends me to, like, some sort of journalism site, you bet your bottom dollar there will be 8,000 moving ads on that that I have no control over and I’m unable to close or move away from.

Now in my talk I gave, I had a slide that said, “Your users shouldn’t have to be hackers to use your software.” So, yeah, there are 6,000 different work-arounds, but in reality, shouldn’t we just follow the standard for Pause Stop Hide? So micro interactions are something that can be a barrier. I had a really big issue with auto complete feature that Google had implemented. So, basically on Gmail as you’re typing it suggests the rest of your sentence. And it suggests that for you in line with what you’re typing versus if you’re typing in the bar above a search, you have drop-down options. And have it fill in next to you, it’s a micro interaction. Technically, it’s not a fail for the standard but, boy oh boy, was that a barrier! Incredible barrier! And there are plenty of little micro interactions like that that, yeah, technically they pass, but they are a really big problem especially with how much people love micro interactions. And don’t get me wrong, some micro interactions are incredibly important. A, “Hey, I’m over here!” can be really important, but also a, “Hey!” button jiggling saying, “Hey, I’m over here!”…if it doesn’t stop, it can end the path.

So, in iOS there is a function to reduce motion. So is ReduceMotion enabled? One word or no spaces. You are able to code things to have a reduced motion for your users, talking about parallax scrolling or things that cause nausea or dizziness. Tt also helps with being, like, you know, I was saying, a micro interaction. But is ReducedMotion enabled, is it really general practice? I wish it was but the sad thing is I, personally, who has an attention related disability who finds moving content to be a barrier, I don’t use iOS. I’m an Android user so the ReduceMotion sounds great but I’ll never benefit from it, but in general, thinking about these types of things because native is so different from HTML, something like ReduceMotion, if that was used more we could break down the barriers with people with disabilities like mine. Another big takeaway for moving content, “Do not tie data saving to if I want moving content on or off.” In my presentation, I had an example from Pinterest. The only way I was able to turn off auto play, which is an incredible barrier for me was if I had, it was specifically to say when I wasn’t on WiFi. I’m unable to sit in my home on WiFi and enjoy auto play being off because to the developers, it’s only a data saving technique. They are not thinking beyond the saving and thinking about how moving content is a barrier.

Now, technically, “technica11y,” these all passed the standard because the auto play has five seconds to do its thing, first of all, and second of all, if I can pause it, which a lot of times you are able to pause like moving video ads on Pinterest and different things like that you’re able to technically pause it or close it, it’s technically not a fail but it’s still a barrier, so having access to reducing the amount of auto play features is really great.

Twitter and LinkedIn are two great examples that you’re just able to toggle it off. I don’t want things to auto play. That’s gifs, that’s videos, that’s anything that’s moving, basically. I’m able to toggle it off, so that’s a great feature. If you do have mobile app and you do have content that auto plays, I highly recommend thinking about creating a toggle because I myself find that to be, depending on how many spoons I have for the day, that could be make or break for me when it comes to pass.

Next is Back Button Behavior. This one is near and dear to my heart. I have a lot of feelings about it.

So, when we’re talking about a back behavior, there’s a lot of different “backs” when we’re talking about a back button. We have a Browser Back. We have OS Back, like a hardback, and then we also have a built-in Native Back. That’s three back buttons, that’s a lot of different behaviors.

So, when it comes to, specifically, let’s talk about a native back. If you have a native back, on say, the upper left hand corner in your window in a 100% native page, that back button is a Dot Back. It will send users back one page. Now, say, you’re at the end of the flow and the user just submitted and they were given, “Are you sure you want to submit?” screen and they have agreed and they have said yes and they have moved to a, “Congratulations!” and the thing that you want to do is totally done, High 5! They are on that screen. What does “back” mean there? If they were to go Dot Back, they will send them to either an error or to accidentally resend what they had sent and if we’re talking maybe in banking, that could be maybe another payment. If we’re talking about buying something, like maybe movie tickets or concert tickets, that could be buying accidentally several tickets. So, a lot of times the way to handle it is just to get rid of Back or to disable the Hardback. But if you have a button in the upper left hand corner that says Back on every screen except for the one that will technically navigate your user to an error, that’s a consistent navigation fail because the navigation item is not consistently located and consistently available on every page.

So, you’re unable to disable the hardback to just be a scapegoat. It’s something that we can absolutely design around.

So, how we design around that, and how people have designed around that, is to ask yourself, “What does Back mean?” So, my users at the end of a flow, where do they actually want to go if they want to go back and a lot of times, it’s back home. It’s back to the beginning of the flow. Maybe it’s a flow that they can do more than once. Maybe it’s an order form or something that they can repeat multiple times and go through the process multiple times.

Maybe they are setting up an account. It could be a thousand things. So when you give the user, “Congratulations, you’re done,” Back could mean something other than I want to go back one page. So, ask yourself, “What does back mean? What does my user want in this experience?” Because when you’re disabling a Hardback, so we’re talking about the Android Hardback, when you’re disabling that, what if a user is in the exact same flow but they are on the web, are you going to be able to disable the back button on the browser? Or maybe are we just going to have to design around it? Because there are so many different experiences with a Back button, we have to be able to design around them. Especially when we’ve got an iOS that has no Hardback, it relies heavily on a native back versus a hardback. So, say you did get rid of your native back but you did not get rid of your…or disable the hardback, right there you’ve got two different inconsistent experiences. So, Back buttons are pretty complicated but I will recommend that you just ask yourself what your user wants because getting rid of a Back behavior because that Back will put them into an error is not the answer.

“Tool Tips.” This is a quick one because obviously it’s pretty simple. So tool tips can be really important. They hit information. They can help contain help content and identifying information. But, tool tips don’t really work on mobile. They are not information you can really access. And the problem with that is that tool tips are something that would be even more useful when we’re looking at a mobile space because if you have less real estate. Getting rid of labels, moving away from labeling things inappropriately, and from identifying and differentiating between different icons, items, you know, actionable things, is really popular. “How can we save space? Get rid of the label. Let the users try to figure out what that means,” and that kind of experience is really difficult.

Now, technically, there we go again, if you’re…say we’re talking about a JavaScript bridge wrap native experience on app, so it’s HTML code. It has a Tooltip on it. Technically, that does pass the standard. But on a mobile device, somebody who is sighted, that doesn’t really help them. So, if you are a non-sighted user and you’re using a screen reader and you roll over that icon item button blah blah, you will get the toolkit information, that information will be read to you and everything will be great. But if you’re a sighted user with a cognitive disability, for example, a chevron or a button that says, “1” with no label next to it doesn’t really mean anything or an ambiguous up arrow with a, “2 “on it…like, what does that even mean? So, small icons, even though they are different and pass color contrast are still not enough; we can’t just do away with labels. Wo we have to find a way to work labels back into the way that we differentiate buttons. Now, there are some things that obviously have transcended labels, such as a hamburger menu. There’s also the triple One Two Three Up and Down Stoplight menu that just means, “More.” There are certain icons that have transcended but, in general, we just can’t do away with labels left and right.

And then, yeah, Tool Tips, super important. But again it’s kind of a funky experience. And this isn’t prescriptive, like maybe there are examples where it doesn’t matter, where it’s good to go, but in general you can’t rely on that kind of background information if you have a set of users who don’t have access to that information.

Okay. Next, and I think we’re getting close to the end, Hidden Page Titles.

So, page titles versus H1s. The fact that they are hidden and the fact that they help with wayfinding. So, this is more for iOS because as mentioned previously, there is really no way to do an H1; it’s just heading or not heading. So page titles are really important on a native page and sometimes page titles there’s really no place to put it, there’s no way to make the big broad sexy this is the H1, sometimes pages are a little bit more convoluted view. For example, a page that’s a success page doesn’t really have anything on it other than maybe a notification or an icon or an image.

So a way to do that is to do is `setTitle:@Home` or whatever you need. I spend a lot of time at work working with our content writers to determine what is the best page title for a particular native page so they are hidden obviously because it’s a page title.

Just trying to add extra context for non-sighted users and what’s really important to make sure every page has a unique page title is wayfinding and it’s obviously the way we do it on the web, but it also needs to be done in mobile and people don’t really think about that. If we’re thinking about in terms of H1, it’s easy to forget about page titles, but for iOS the H1s really won’t help you out. It’s more of a don’t forget than anything else. Obviously it’s not ground breaking.

And I think this is my last one. We’ll see. Navigation.

So just something interesting. This is not prescriptive or telling anybody what to do this is something I find incredibly interesting. So, Navigation. When I’m talking about navigation, I’m talking about like swipe order, so focusing the DOM, so focus order, meaningful sequence and keyboard behavior.

So that something I found fascinating. I had the pleasure of visiting Ben Yahoo just becoming an oak of their Accessibility Team. They do really fantastic accessibility user experience testing. And, we were told a story, my team and I, about a time they were so proud going into user testing. They had just really felt like they had covered everything. They had users with vision related disabilities. And they just felt ready to rock and the guy sat down and whipped out a Bluetooth keyboard and the whole room went silent and this guy used their app with a Bluetooth keyboard and it broke everything because people do use Bluetooth keyboards. It’s definitely a thing. Again when I was thinking about the work that I do with Chromebook. I have a keyboard attached. I’m practically using some native app, so if I tab through things, what happens? A big thing I find with focus order and meaningful sequence when it comes to native stuff, is it’s fascinating for me because the focus can get lost so easily behind modals, behind popups or behind when you have multiple pages open. So, say you open one window from the other and you’re in a native app and it does support that behavior, getting lost or if you swipe up too far, you’re still looking at Page 1, but say you swipe down too far you’re in Page 1, technically you’re focused on Page 2, but it’s not visible. Just really interesting stuff like that, so if we only think about native in terms of using screen readers and not thinking that sometimes people are without keyboards, it’s kind of an extra hold. An interesting story was about skiplinks. So, if a skiplink does not show visibly, obviously that’s an accessibility violation. When you’re thinking about native, you’re like, “If it’s announced to the screen reader user, that’s the main user, who will need a skiplink in this regard?” Pardon me, my animals in the background are making noise, but the main user who will want this is a screen reader user; it doesn’t have to be shown visibly. But then, if someone gets a Bluetooth keyboard out and the skiplink isn’t visible, they’re not going to hear that announcement and they will miss out. So that kid of blew my mind and it’s like, “My gosh, people use Bluetooth keyboards with cell phones?!” More anecdotal than anything else.

So wrapping up because we are short on time. In conclusion, when it comes to making accessible design decisions, we cannot wait for the WCAG standards to catch up and that’s not because the standards aren’t good enough. It’s not because they are low. It’s because making standards for mobile is really, really hard. It’s really hard to find a standard that can easily pass the goal and have a repeatable testable way. So, you have to move beyond into the dark water and we have to determine best practice standards for things like Back buttons, for things like what do you do when you have things like tool tips that aren’t visible; it’s a problem but it’s not a violation? We have to figure out ways to work beyond the standards to create experiences for people like me, who have attention related disabilities. Yeah, technically yes you pass really great standards, but the fact I can’t read articles because I’m bombarded with moving ads is a problem.

Next, mobile accessibility is hard because the lines between web and mobile are way too blurred at this point. We’re serving up HTML code wrapped up, we’re accessing special mobile sites via browser. People are going to access your content in ways you have never dreamed of, they are going to be on an Xbox surfing the web. I’m having a hard time with Netflix on my smart TV. The way we access technology is way beyond cell phones and computers. We’ve got tablets. We’ve got SmartWatches. We have smart televisions.

There’s thousands of different ways that we’re able to access content. So, if we’re thinking very much web and mobile, it’s not the way to think about it anymore. It’s muddy, it’s dark, it’s scary, and we’re all in it together. (Chuckles)

When code truly is native, it must be treated with a different approach than web code. Simple. Made that point quite a few times. If you’re going into, say, even testing for accessibility violations in mobile and you’re looking for exactly what you would look for in the web, you’re going to have a bad time. Perfect example that I made a bunch of times, H1s and headings, it’s just a different experience. I think this is the last one, yes. Mobile Accessibility is going to take time, creativity and input from persons with disabilities…I will repeat that…input from persons with disabilities to get right. It’s going to take time. But there are awesome companies doing awesome things when it comes to accessibility where there really are no standards. For example, people are able to take selfies with iOS because of the way they audio describe, because of the way that the phone communicates to the user. People who are blind are able to take selfies and that’s amazing! Things like that. These creative innovative ways and I’m not an iOS fangirl myself. But I do absolutely recognize that there are some really great things happening. Speech-to-text technology is changing my life. It’s amazing. The way that we’re using smart devices, these are going places and we need to have the time to talk to people creating those devices and the way they have worked alongside people with disabilities is really fantastic, so there are really great things happening. It’s not all doom and gloom. There’s really good stuff going on but it’s just going to take a little bit beyond the standards. It’s going to take brainstorming and making a lot of mistakes first before we get the right answers.

Again, my name is Shell. And you can find me†@ShellElittle on Twitter. I did put my email address out there I won’t read it aloud because I don’t support anybody emailing me. LinkedIn is better. Thank you for your time and I think we have a little bit of time for questions.

>> MICHAEL BECK: Yeah, thank you so much, Shell. It looks like…a lot of great stuff. I see you really spoke to Mallory; she was in the chat and cheerleading you quite a bit.

>> SHELL LITTLE: Oh yeah. “P

>> MICHAEL BECK: It was almost like a woman at a black Southern Baptist church screaming, “Preach on, brother!”

>> SHELL LITTLE: That’s great I’ll have to look at that. I can’t see it right now.

>> MICHAEL BECK: Yeah, does anybody have any questions? We’re just getting some great positive comments. Oh, someone may have a question.

>> SHELL LITTLE: Okay. I saw some pings and I was like, people will have lots of questions but I’m glad I got Mallory cheering in the chat.

>> MICHAEL BECK: Oh, yeah. What speech-to-text program do you use, if you use any?

>> SHELL LITTLE: So for speech-to-text, so in my free time, I stream on Mixer, a plug for Mixer. I rely heavily on the Google speech-to-text API. So anything that’s built into my device when it comes to searching, when it comes to typing, texting, and I gave a talk actually in Toronto at the a11yTO Conf. An example I used there was the fact that Pinterest does not allow me to use my voice-to-text feature in their search is a really huge barrier for me. So if anybody knows anybody at Pinterest, let me know. Because I rely heavily on things for dyslexia I, having dyslexia, I rely on things with speech-to-text when I’m looking up recipes, I’m not just looking up garbled words.

>> MICHAEL BECK: Is there any place that you would suggest developers go to learn more about mobile techniques?

>> SHELL LITTLE: Yeah, I’ve consumed a lot of the content from TPG. They have an iOS guide and an Android guide. And I highly recommend those two pieces of literature. Unfortunately, I’m not sure if they are paid or not so that might not be incredibly beneficial but it is worth it to me. As a non-developer, especially with iOS, I have to stack a whole project, so basically break down every element of a project to deliver to the developers, and with using the TPG guides, I was able to really learn a ton and successfully communicate the accessibility needs to our developers.

>> MICHAEL BECK: Okay, and Pamela points out that, for instance, like a library catalog may have extensive info on the desktop version but for mobile the details are usually significantly scaled back, that actually I know that very well as a former librarian myself. Would that be considered like a violation? Because she always thought that scaled down content for mobile was more accessible and not necessarily less.

>> SHELL LITTLE: When you’re talking about scaled down information, are you talking about, like, say like a description on a book has less content?

>> MICHAEL BECK: Yeah that generally happens. It also might have — it might pull off information — oh I’m trying to think here it’s been a while since I’ve looked at a mobile catalog. It may have less information but not necessarily vital. Like on the mobile catalog it may just have maybe a picture of the book or the title of the book and where it is and the call number and whatnot and maybe the availability across branches as opposed to on a regular web it may have a full-on description. It may have reviews of the book and all of that sort of thing.

>> SHELL LITTLE: Uh-huh got you, yeah, so I think obviously optimizing stuff for a mobile experience is really important because correct you don’t want to bombard your user. But at the same time that’s what expandable content sections are for and that’s what click here to learn more or expand is for. So, maybe minimizing the information that you’re giving upfront but if the user really wants to find that extra info, it shouldn’t be on a different platform. It should be maybe behind a, you know, maybe a pop up a window that gives you all of that information, and users are able to scroll through. But if we’re talking about, like, pulling out the fluffy stuff and leaving the really important content, I see no problem in that as long as the content would be considered parallel and equal in what a user would get out.

>> MICHAEL BECK: Okay yeah Pamela just pointed out that maybe a title might have 15 subject tags and 10 authors on a desktop and on mobile it might just have the first 3 subject tags and the first 2 authors. So that…

>> SHELL LITTLE: Got ya.

>> MICHAEL BECK: That may not be as successful because that’s a little more vital.

>> SHELL LITTLE: That’s where I would say like having a dot dot dot or, like I said, click here to or tap here to read more would be really important in that situation.

>> MICHAEL BECK: Have you heard of hooking up phones to laptops to see the code. Mallory has heard of people hooking up things in Macs and hooking them up in Safari and hooking up Androids to things and viewing the source in Chrome.

>> SHELL LITTLE: I have heard of it nor have I had the experience to do it myself nor have I seen it in person but it sounds super interesting to me.

>> MICHAEL BECK: John points out TPG’s testing guides are freely downloadable, so go check that out.

>> SHELL LITTLE: Fantastic.

>> MICHAEL BECK: And one final question for you as we’re nearing the end of our time, Chris Frye has a question about iOS headings he audits a lot of interfaces that using a ton of bold text to delineate categories such as dates with several child elements under those dates but in some screens there are weeks worth of items so we are looking at a minimum of seven headings on small screen real estate. Is there a soft rule of thumb when considering how many headings are appropriate or when developers should consider reorganizing the information?

>> SHELL LITTLE: Yeah, so, first of all, hi Chris Frye. I’m not sure I fully understood. Let me look through the question one more time. So, basically the question is there’s too much content basically?

>> MICHAEL BECK: Yeah if you’re hitting seven headings that’s quite a bit and is there a soft rule that you follow that would be like hey maybe we should cut it off here or go back to the drawing board and reorganization?

>> SHELL LITTLE: Yeah I think if we’re talking about, so a shared codebase, so, maybe it’s just like a web based thing wrapped into or broken down to a mobile device size, if it’s not working at a mobile device size because there’s too much content, because it’s too cluttered, then honestly it probably sounds that would be a great reason to reorganize, because if there’s that much content and some of it is unnecessary users who are potentially screen reader users accessing it on the web will find it just as cumbersome as somebody doing it on mobile. So just reorganizing and minimizing content because when we optimize for mobile we’re optimizing all experiences. Just getting rid of extra clutter, getting rid of unnecessary paths that loop. I think I’ve found that when we have redone old legacy stuff and just cleaned out the content and gave it a facelift that it makes the experiences better all over.

>> MICHAEL BECK: Okay. I think that was it. Well, PJ has a quick question where should we go before presentations to read about the upcoming topic. Well, you can go to technica11y.org. That’s technica11y.org. We usually have all of the bio information and topic information about two weeks before or at least two weeks before the next talk. Speaking of which, next month we’ll have Michelle Williams, who is a Senior UX Researcher for Accessibility at Pearson and she’ll be onto discuss what’s really needed to conduct accessibility user research and how that generally involves having an accessible ecosystem to work with. That will be on May 1st. Oh, it’s on May Day! Wow, instead of dancing around the maypole with Lord Summerisle and burning a Wicker Man that may or may not have Nicolas Cage in it, come listen to Michelle Williams here on technica11y on May 1st at 11 a.m. If you missed anything out you can keep an eye out for Tenon’s Web site we’ll let you know via social media when it’s available or subscribe on the channel on YouTube to get automatic notifications. And with that I would like to thank Shell again for her excellent presentation and all of you for joining us today and we’ll see you all next month. Thank you!

Shell Little

About Shell Little

Shell Little is the Mobile Accessibility Lead at Wells Fargo DS4B.