Navigated to episode Dark Adventures in Mobile Accessibility.

Dark Adventures in Mobile Accessibility

by Shell Little

recorded on April 03, 2019

Transcript

[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!

Back to the main page