Tuesday, May 5, 2020
Communication Access Realtime Translation (CART) captioning is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.
This transcript is being provided in rough‑draft format.
Title: It's Always Sunny in Mobile Accessibility
Chicago Digital Accessibility & Inclusive Design Meetup
Santina Croniser: All right. Unless anybody has a reason that we shouldn't start exactly on time, I'm going to go ahead and start. Again, very excited to see that we have folks from all over North America. I saw one reporting from Ontario Canada, as well as Georgia. Boston, like I already said; California, and, of course, Chicago! Naturally! Obviously, where most folks are, and — naturally being the Chicago Digital Accessibility Meet‑up group so really excited we have the chance to come together. As folks — most of the folks know who know me in person, I moved out to San Francisco; so, these remote Meet‑ups, actually, offer a rare opportunity for me to come in, and see everybody all over again. So I'm so excited. That I get to come and be a part of the accessibility group. Remotely. So thank you, everybody, for attending. Thank you for spending, May 5th with us, even though perhaps, you would rather go and have a margarita, or, you know, have a margarita, while you are tuning in, that's also acceptable. [LAUGHTER]
I'm Santina as it says on the slide, and we already did the introductions, we'll perhaps, have some after — to just chat and kind of talk and catch up, as well; so, you can feel free to stay after for that as well. Feel free to continue introducing yourselves, as well while I'm speaking. Just a reminder: That if you do not want to have your face captured in any way or you don't want to speak, that's absolutely okay. We're completely fine with that. Just make sure you turn off your video camera, and/or turn off your audio, and certainly turn off your audio while the speaker is speaking. We'll go ahead and go through the announcements and introduction, and then we'll get started. It should not actually take me that long to get through the slides.
We'll get started with our Speaker, Crystal Preston-Watson. "It's Always Sunny in Mobile Accessibility". And then we'll wrap up around 7:30. If you would like to follow along with the slides, you can certainly do so. We have speakerdeck.com/A11YChi. And Nick did post that in the chat as well. So if it's easier for you to click on a link, go ahead and find that link in the chat.
Live captioning is available, on any device with a web browser, so to access that, you simply go to streamtext.net/player?Event=CDA, with the capital CDA.
Live captioning is sponsored by McDonald's! So thank you, very much, McDonald's for sponsoring the live captioning!
[APPLAUSE]
And please do keep the discussions going on Twitter, you know, A11YChi. @A11YChi or # A11YChi; and, you know, taking quotes from the speaker is a great way, to not only boost the — your own visibility, but certainly, boost the visibility of the speaker. So the speakers always appreciate when you can —@them along with an interesting (Santina Croniser) interesting piece of information that — she might have had, that resonated with you!
Santina: (Continuing), of course, we do have our YouTube channel. You might be tuning in live on the YouTube channel right now, but if you would like to have this presentation afterwards, you want to send that out. Or you want to refer back to something, just go to YouTube.com/A11YChi.
...
Oops! Ah! Sorry about that.
Again, if you prefer not to be in the recording, check to make sure that your camera is off. Please do hold Q&A, for the very end, we will be monitoring chat as I mentioned, as you might have heard me say. Nick, myself, and — in the — and the rest of the organizers are going to go ahead and monitor those chats, and we will raise those questions at the very end.
Also, if you have any technical issues, or any questions, please feel free to ping us in the chat. We will go ahead and monitor those and help you out as much as we can. So I want to open this up, for jobs? Feel free to take yourself off of mute. If you are offering a job, and/or, just post that in the chat! And, of course, if you are looking for a job, as well. Feel free to take yourself off mute. And mention that and/or post that in chat. So I'm just going to pause for a minute. So folks can go ahead and do that.
(A pause)
Santina: Very quiet today. All right! Not your only opportunity. So if you have a job to offer and/or if you're looking for job, go ahead and mention that in chat and we can circle back towards the end and also we can announce that — we can open it up for another opportunity if — if folks weren't able to unmute or didn't get a chance to say that.
Also, wanted to plug our next event. That's going to be occurring on May 21st, for global accessibility awareness day. We're don't go with to have an invisible disabilities panel, where myself, Keidra Chaney, Fen Slattery, and like I said myself, hopefully, you can join us for that! Very excited that we will be talking about "invisible disabilities. "
And now to introduce Crystal, pronouns she/her a Quality Engineer with a focus on accessibility at Salesforce, she believes accessibility is "a human right" and is passionate about building accessible and inclusive applications for everyone, and, of course, the Twitter go ahead, and @ her, if you do quote her, @ScopicEngineer. And, now I'm going to go ahead and turn this over to Crystal. So Crystal, I'm going to stop sharing.
You can feel free to go ahead, and bring up your presentation!
Crystal Preston-Watson: Okay. Let me make sure — I do this. (Taking the mic) all righty! I have done it — let me share my screen. (Giggling) and then I will share my presentation!
Hopefully you can see — (giggling) you can now see my presentation! So, thank you for the introduction (to Santina). I'm Crystal, and this is — it's "It's Always Sunny in Mobile Accessibility", and as you can guess, I am a huge — it's always sunny in Philadelphia fan! (Giggling). So — and — I — I realize that, this title, could be a little bit, you know, given this — the kind of style of the show, it could be a little bit kind of, maybe weird, but, I — I love the show, so I just thought you know what? I — I'm, you know, passionate about mobile accessibility and I really like that show. You know what? Go with this title. So, I am a Quality Engineer at salesforce.org, and on the screen — is Frank Reynolds, played by Danny DeVito in the show, dressed as an art critic. I am forgetting the character's name. But, this is going to be my Halloween costume. For this — [LAUGHTER] For this next year, even if it's just sitting in my house. Due to everything that's going on. (Continuing) so this is kind of, over view of what I'm going to talk about. Going forward. And I'm — and I'm (giggling) I realize I'm look to the side — so for those, who can see me — I'm very — I'm someone who is very awkward, and also. I am someone who has visual impairment. I have Caraco n is and Ocular toxoplasmosis , so I don't have — I have my macula scarred in my right eye. The screen in front of me is really zoomed in. So this — just kind of a preference, if I go like that and I'm staring off, I'm reading my notes. But, so I'm going to go — this is our kind of, framework for what I'm going to talk about tonight (referring to PowerPoint) I'm going to say a few words on mobile usage.
Do a WCAG overview for those who may not know — or new to what — to web accessibility, and the Guidelines — exploring WCAG 2.1, mobile success criteria. And then explaining a little bit about Android™ Ios features and tools. I do want to preface: This is really not getting into any sort of, like, code. I just — I feel like, that, would just — unless we wanted to take, like, five hours — and dive deep! And that's — and I didn't — I didn't want to put in any code. This is kind of a — kind of introductory talk to mobile accessibility and really kind of giving some of — of the gist of the guidelines that WCAG covers. Specifically, applies to mobile, devices. So on the screen is a screenshot of an article from the BBC.
And the headline says "people think you can't be blind and use a phone" — and this — this is something that's really — prevalent with a lot of — of the public. When they think about — especially those with disabilities, they don't think about the — they think about people with disabilities as in a way, "Well, they just sit in their house, and they don't do anything." And, you know, they're sad and they should be pitied. And maybe, is there some kind of, feel‑good pandering story. You know, that, you know, they — I don't know — did something — that's — that's especially in media, you see a lot of people think about people with disabilities.
And this article, really showed and talked about people, who are — who are blind and visually‑impaired. They were harassed about their phone usage. This came out, in 2019, the beginning of 2019. I read this article. And the fact is, is that, with — especially people who are blind and visually — and visually‑impaired, Mobile Devices are — are widely‑used; and it's actually for a lot of people, that is their main connection to the Internet and to the Web. Especially, when you're thinking — when we think about mobile accessibility — there is a focus on desktop. And there — and — and mobile devices secondary. Especially, if your company is not making their primary product is not a mobile application. But the fact is, there are many people in developing countries. And even in the — if you want to frame it in the U.S. — in underserved locations — especially in inner cities, in rural areas of America — where mobile devices are their main connection to the Internet. There is no — like, there is no — their Internet connections are really, you know — are poor, if nonexistent. And so using their phone is their main lifeline, and for those with disabilities, in those — in those areas, that's the same thing.
So, if someone has a disability, who lives in the area, that, you know, doesn't have stable Internet connection, a phone is going to be what they use to connect to the — to really connect to the outer world. And that's where, you know, I want — you know, I really have been focused on accessibility. And I know for me, as I rely more on using screen readers, I, actually, started mainly, using my Mobile Phone; so I use Talk Back on my mobile phone, and I use an Android™ device. And then I started to use screen readers on desktop, mainly, voiceover as I use a Mac. But mobile accessibility is a very important — because it really, does — I mean, it's something that, you know, — uh — forgive me, I'm a little bit nervous. (Giggling) but it's really something that, you really do need to be concerned about.
And this is from WebAim. This is something — from their — this is from 2017, from their readers survey. This was the readers survey, number — No. 7 and on the screen is a graph that charts mobile screen usage.
And it goes from January 2009 to October 2017. And from — from over the years, the amount of readers — of readers, and of people who they surveyed, use Mobile screen readers — increased significantly. It was 12% in 2009. And in October 2017, it was up to 88% of the people they — who they surveyed used a mobile screen reader. I just looked today from their latest survey, in 2019, and, though, they didn't really pull for this particular screen reader usage, in this particular way, but 86% of the people did respond, actually, yes. And so 80 — 80% of the people who did respond, did use a screen reader on their phone.
So it's pretty much the same. And, though, it's — and it's only going to grow. And I know, like, WebAim is just a small portion, but you can kind of take just by the fact that, you know, screen reader — like, — mobile phone usage, just in general, is on the rise — that's only — that only means that people who rely on Accessibility and assistive technology, also will be using mobile smartphones, and that their need for assistive technology like screen readers, will also be on the rise, also.
And so we're going to go on to WCAG overview: Hi, everybody out there! I hope you're all doing well (giggling) you know what? I'm going to take a little bit. And I — I am so — I do — believe it or not, I did improv. So I'm going to improv right now! I get really nervous, I have social anxiety disorder. If you haven't figured out. If you couldn't tell! [LAUGHTER] So I get really nervous, so I'm just going to shake it out. Going to do, you know — I'm not going to do voices, because — if you ever see me do an improv show, I only do a southern voice, or when I try to do Italian voice they're, like, "That's a really good Jamaican woman that you did". And I'm, like, okay, let's move on to WCAG, this is the overview. For those of you new to web accessibility — and I pronounce it WCAG, I think you can pronounce it different ways. That's just the easiest way for me to pronounce it, it stands for Web Content Accessibility Guidelines. And, they're a series of guidelines that, many people have used throughout for improving web accessibility. It was created by W3C, which is the worldwide web consortium. And, like, if you are if you're new to web accessibility, you work with — it's something that you do professionally, career‑wise, you know WCAG!
(Continuing) (next slide), now, let me kind of — talking about — and, again, I don't know where everybody is on — on their knowledge of web accessibility. So I'm not going to go too, too deep, into kind of the intro — and kind of base — like, all the basics of WCAG. Just because, I — when I've tried to do this, this talk has ended up being two hours! [LAUGHTER] But I'm going to give the brief overview, on the slide we're going to talk about the "four principles" of WCAG.
And these are very — I think if you take away anything from WCAG, even if you don't work — if you're not doing things day‑to‑day, for accessibility; and I know kind of unfortunately, the nature of some people in positions, is that — and in certain companies you don't get to do Accessibility every — you know, like, all the time. And that's not your — some companies are, like, "Well, you know, still it's a thing that's nice to have" and, like, "We'll get to that later" I'm not going to off — that's a whole different area. If you're going to take away anything, going to remember anything, especially even if you're not focused on... um, accessibility, remember these four principles of WCAG: And those are.
- Perceivable.
- Operable
- Understandable
- Robust
... if you were a a in the '90s, pour. Users must be able to perceive the information presented. Operable users must be able to operate the interface, understandable, users must be able to understand the information as well as the operation of the user interface. Robust: Users must be able to access the content as technologies advance.
And then also, when it comes to (next slide) conforming to WCAG guidelines, there is three levels of conformance.
There's level A, which is the kind of really, you know, the minimal amount of accessibility that you can have for a site. So the most basic web accessibility features.
Level AA: And that kind of — addresses — the most major, most common accessibility issues, so level A deals with the biggest and most common barriers for disabled users and level AAA, the highest and most complex level of web accessibility.
I — I — got this from W3C, and it does — it says — I think it's a higher standard, it says "most complex" — I like that it's the higher standard, not "most complex" because I think that can really intimidate some, you know, — some teams, like, let's not even try for — a AAA on something. Because that's too complex. And I think you can't get maybe AAA on every single, you know, piece of function that you have on your Web site, but for a lot of areas, I think for, you know, — you can definitely try for that. And you can definitely succeed.
So that's more — less of — the most complex, and just the hierarchy of it. So, if you're not in the "know", there is WCAG 2.0 and there's WCAG 2.1. And WCAG 2.0 which are the guidelines, they were released about nearly ten years ago; and one of the main things is, like, if you think about mobile accessibility — ten years ago, which is 2010 — they're — I mean, you know, smartphones were a thing. But it was still kind of — I want to say, like, the Wild West of figuring out, like, apps. You know, it was only — I forget when I — like, the iPhone — really came out — but I — you know, I still feel, like, you know, Mobile Devices, and mobile phones were still kind of in their toddler ages, maybe around, like, that, you know, age where kids, like, learn the word ", like, no, and they'll say no, do you want ice cream? It's, like, no! (Giggling), do you want, like, broccoli, like, no! So everything is no. So that's kind of where I feel — when WCAG 2.0 came out, there was a lot going on when it came to mobile applications. And mobile development. And so it did not — it really didn't deal with mobile accessibility. It was mostly geared towards, you know, browser web‑based accessibility. And you pretty much had to take what, you know, what it said about that. And then tried to figure out, and apply it to your mobile device. That's really (laughing), it's — and it works for basic things, say, like, with alttext, and even color contrast and things like that. But when you get into Native Mobile, kind of functionality, that's where it gets really tricky.
And the Guidelines really, don't — there is really not a good way to kind of take the — the guidelines, and then for, like, — say, a web — a site in the — in a web browser and then, apply them to a mobile application. (Continuing) so 2.1 came out, I believe — it was.... the beginning of 2018. January 2018.
And pretty much 2.1, this — you know, it takes all the success criteria from 2.0 so there wasn't anything "oh, we're going to throw stuff out" and, like, you know, we're doing it, like, we're just doing it all! All over it. Pretty much everything for 2.0 is in 2.1; but! They added more stuff! So there's 17 new success criteria. And there is 8 that kind of — that deal specifically with mobile accessibility — accessibility! So, and that's where what, you know, this talk really focuses on, we're going to go through those 8 and go a little and just pretty much break it down into, like, I — I say into more kind of "conversational" explanation. Because I know, when I have dealt with... um.... testing, for this, this was not, you know — because WCAG, I love it. I love this documentation. Not everyone does... like. [LAUGHTER] I read "Ulysses" when I was a kid, and I don't know why. I Les Miserables. If you want me to talk about Hugo, I can talk about that. But let's go on. So WCAG 2.1 — mobile success criteria! So as I said, there are 8 new success criteria. These specifically deal with mobile accessibility. And I'm just going to — we're — I'm just going to talk about how, this — go through them and just kind of explain what it means, and what — what that means for, mobile applications. (So, (first one is "orientation," so this is 1.3.4, orientation. It's — level AA. And it says "content does not restrict its view, and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential". And pretty much what this says is you — your application needs to honor the orientation that the user wants. When it comes to a lot of applications — (next slide) — they tend to want to have the user stick to one particular view. (Credit: Xialong wong), this is great, if they need for their phone, to be in a certain position, if you're trying to — if — your application won't work in that position, then they are barred from using it. I know Talk Back, is a very weird — if I use it in — in — in landscape mode. I've tried to use, when I've had a Web site, that's tried to make me use it in landscape mode. And then I tend to — I tend to, like, to pull up the talkback menu, and I — I can't, so I have to constantly pull, like, you know, go like this, pull up the talkback thing, go back like this — it's really — it's not — it's not a great experience.
Now, it's excluded, like, from applications, where it's necessary, to force a particular orientation. Say, you have a photo application — application, and there's a landscape mode. So, obviously, you don't want to change — you don't want the landscape mode to be in portrait mode, but that's — the only real case. Otherwise, it's not — I mean, — it's not wise, it's really not just good. I think overall good usability. If the user knows what they want, and then trying to force them, because you think, it's better for your application, is — I don't know! It's kind of, like — you're really — I think, you're doing yourself — it's detrimental to your application.
Next up is "2.5.1, Pointer Gestures" and that's level A it says, "All functionality that uses multipoint or path‑based gestures for operation can be operated with a single pointer without a path‑based gesture, unless a multipoint or path‑based gesture is essential". This breaks down, to just using simple gestures. And, you know, so if you have an application, and it requires you to use... like, four or five fingers for — to operate, you also need to provide a way for a user to use a single pointer. And — but the things — what's excluded from this is any gestures that are included with the operate assistor, so iOS or Android™, they don't have to meet that. But if you have an application, where you're, like, "Hey," you know — we're going to have them pet it like a cat, and they need to point all 5 fingers onto that — yeah, that's — that's cool. But you still need to allow them to. [LAUGHTER] To have a single point of touch. And a good example of this, which is a — a map, like, say, something like Google Maps, though that's not what's on the screen, it is a generic mobile application on the phone so if you have a mobile — a map, app on your phone, I think most of them have, like, the pinch, to zoom. Or, you know, — pinch to zoom or move two fingers to go out. But usually — the application is good, they also have a plus or minus button that allows you to move to zoom in and out. (Credit: Sebastian Hietsch) now, say when it comes — you're going to hear me say this a lot. Video games are excluded from this. And this is going to come up. I feel like when it comes to any application that wouldn't — that would be excluded, there is really not really a lot of good ones, other than games and even when it comes to that, a lot of games should have better accessibility. But this is not a video game. [LAUGHTER] A video game accessibility presentation.
Next: 2.5.4. Motion Actuation. I am so sorry. I'm — mispronouncing the — mispronouncing that! Oh! This is level A. "Functionality, that can be operated by device motion, or user motion, can also be operated by the user interface components and responding to the motion can be disabled to prevent accidental actuation, except when... supported Interface or Essential". So Supported Interface, that's — those two exceptions are talking about really, assistive technology that, the user might be using; that they — so that, actually, would not have to meet this criteria, if there is — if a User is using something that has motion as part of its function. An essential — again, games, games, let's say again, that's excluded.
So an example of this, is on Android™ — and I believe — the latest Pixel, I think pixel 3 and pixel 4 folks, there's active edge, and it allows you to squeeze your phone, and it will pull up your Google assistant and it will you can do a couple of other things, the thing about this, for those who have limited mobility who may be have tremors — they can't do that. They can't squeeze, you know, their phone to do that. The same for — I know I have right now, because I dropped my Pixel, I now have a M. 7. And you have to shake it to get the flashlight going, and I have had this flashlight come on many times! And, again, for someone who has tremors — this thing — and it doesn't take a lot for this flashlight to come on! So, you know, again, this — with this particular criteria, you should be able — a User should be able to disable this.
And then they should be able to have an alternative way to pull up different applications or functions without having to do any sort of motion. (Next slide) "2.5.2: Pointer Cancellation (A) and this is level A. "For functionality that can be operated using a single pointer, at least one of the following is true: No down‑event, abort or undue. Up reversal, essential". And so when it talks about no down event. Is not used to execute any part of the function. No abort or undue, completion of the function is up event and the mechanism is able to abort the function before completion or undo the function after completion. Up reversal. The up reverses any outcome. Down event, essential, function on the down event is essential — pretty much this is dealing with when a user is completing an action, like, — it allows users to cancel, or kind of back out of an action, if they accidentally trigger one. And this really kind of — you see this coming — coming into play a lot with drag‑and‑drop. And pretty much — what you want to do is — if you can have, your — your, like, your applications really, a keyboard, or a key — like, a keypad, a pad, that's really what is preferable, versus especially, if someone has — again, limited function — mobility — that's — it's really easy to — for them to accidentally, you know, click on an incorrect action. And so on this slide, this is something I actually ran into, when I used Spotify. This slide I'll read through it when you accidentally hit the wrong button on Spotify and banish an artist you enjoyed to the shadow realm. And there is a guy in a really cool sweater saying, "I guess I'll die!" And shrugging. It's only been five years, I'm sure they'll fix it soon. So this came about — Spotify, where if you went to — and they actually have corrected it. [LAUGHTER]
You would go to interact — I think it was actually like — I think, either like the — the song or follow the artist — and then, it actually said that — you didn't want to hear them anymore. And this is something that really does happen with a lot of function, where it's, like, drag‑and‑drop this, and once you drag in the middle of the drag there's no way — if you drag the wrong option, you can't back out of it. So either, you know — it's, like, you know, if you're — like, okay, I want to — to just, like, lose all my money in, you know, Animal crossing — because I've been playing, a lot of Animal Crossing, if you have an app like that and you're in the middle of, like, you — you're dragging to say no, I don't, I really want all my — I don't want to lose them. But you're — you realize that you're right over the — yes, please do. You should have a way, (credit: Internet) for the use to back out of that. This is what this success criteria is dealing with. Pretty much, when you have, kind of, gesture‑based functionality, please, just have ways for users to back out of things, if they — if they accidentally do — things they don't want to do.
(Next slide) which is 2.5.6, Concurrent Input Mechanisms. This is level AAA. This is web content does not restrict the use of input modalities, available on a platform, except where the restriction is essential, required to ensure the security of the content, or required to respect user settings." So pretty much, this is saying "don't limit the users' choice of input." And this comes um, from (credit: Hable) I haven't really come across it too much, but for a lot of people, especially if you're someone who is blind and visually‑impaired, they may want to use a — a — a Braille keyboard. And, actually, on the screen, this is a Braille keyboard for um, both Android™ and — Android™ iOS, it's called Hable, a company out of the Netherlands, and it's really cool. And it's, you know, very compact, where I've seen some other Braille keyboards that are quite larger. So this is actually, very, very compact. And mobile. And really, you know, if you have an application, you shouldn't, you know, — you shouldn't block what, you know, — what a user wants to use, to interact with your site. Just, like, you know, a desktop. So — and that's — and not just for assistive technology, like, what I have right now. I have headphones on, and just think: If I couldn't use a — headphones to interact with Zoom — like, you don't want to do — you know, do that. I actually use headphones a lot because when I use Talk Back, especially, kind of the — the nature of my — my impairment, at night is — even worse, and, like, glares — I just — when I'm reading, in bed. My husband doesn't hear me at night, where I'm, like, you know, trying to, you know, read through things and I'm, like, — because I get up superearly, and — and, you know, I don't want to be at 5:00 a.m., like, yes, this is the birds and me, you know, reading the daily news, having talk back the news to me. [LAUGHTER] And one — again, so one thing that is — that doesn't have to fulfill the success criteria, is games. There's always games, games are always — honestly I don't think it should be, but hey.
Okay. Next slide, I think we're halfway there, about halfway. This is 2.5.5: Target Size, and that is level AAA. "The size of the target, for the pointer inputs is at least 44 by 44 pixels, CSS pixels, [sic] except when: Equivalent —" which means there is another link or control on the same page that does — that has this in action, inline. In line is if the target is within, like, a — it was — what's in a block of text. So a link, within a block of text. User agent control, so it's a default user agent, and not something that's modified by developer. Or Essential: Games! [LAUGHTER] More games!
(Next slide, credit: Apple Design) on this slide — I just took this straight from Apple Design, because it was perfect. And we have two examples. The one on the left is a hand, pointing at two buttons. Both are 44 pixels, by 44 pixels. The first one is a cancel button, the finger is over. And into the right of that — the cancel button is a save button. And the second example to the right is the — both of the same buttons from the first example, but very much smaller. And as you can tell, this is something for people who have mobility issues. I mean, I have issues with very small buttons. I think this is not — you know, this is something that, I think, a lot of people have to deal with, is just very small buttons. And I feel that, especially when it comes to web — kind of — web apps versus Native Applications, is that usually, there is something that's not accounted for. So the buttons, like, — oh, yeah, we'll — it's not a native — not a native app. It's just a web app, and then somehow, you know, we go to the site, and buttons are all just, like, supersmall. And, like, I have fat fingers — and I'm. [LAUGHTER] — I have, literally — one place, I've seen this — and — and it's better, but Amazon.... had this problem. And they had this problem where they — it's, like, buy, one‑click button and I almost bought, like, a $300 — it was, like, $300 headphones. And it was, like — [LAUGHTER]
So I was, like, oh no. It was just, like, I — I didn't — it was very — it was very small. And I — was trying to have — so, yeah, this is very important. This is something, that, you know, accessibility, and usability. There's no reason for it. You don't need small buttons, you know, this is not an app for ants.
(Next slide) 2.5.3: Label in Name. So, for user interface, components with labels, that include text or images of text, the name contains the text that is presented visually. So this is talking about, when you have — like, mainly, you want the text of the label, to be — at the start of the name. This is a little bit complicated and I — and I (giggling) this is probably the one — I have a little bit — because I'm not — you know, I — you know, in my day job, I'm a QE, and so I'm not doing a lot of and development at the moment; but, the label identifies the control, like — so the label is what you're going to read. So if you see something that says "search", the label is going to be there, and it says "search." But the name is what your screen readers are going to use to — to identify the control to the user.
So you want the label and the name to be the same, or at least the start — you want the label to have the start of — the start of the name. So, there's no confusion to the user when the screen — say, a screen reader is reading off the control. And... so this is my example, this is, from the — this (credit: The Internet), it's a toy that says "Dogs" but they're clearly two ostriches, and really pretty much what you need — you want the accessible name to match the visible label. Because, it's very, very — it gets very confusing. Especially, when you see — when you have your screen reader read off — it says, you know, it says, "Okay, submit", you know, "submit" and then it says, "Send" and it's, like, okay what am I doing? It — you can't assume that well, of course, they'll know that submit and send is the same thing, because, again, you're assuming, for those with — you know, maybe you have mental impairments — that's not — that's not a — that can cause some confusion.
So matching your accessible name to the visible. And this is the very last success criteria. And this slide says 2.1.4, Character Key shortcuts. If a keyboard shortcut is implemented in content using only letter (including upper‑and lower‑case letters), punctuation number symbol characters then at least one of the following is true: Turn off, remap, or active on focus" this is pretty much dealing, like, hot keys or keyboard shortcuts. So "turn off" means a user is able to turn off the shortcut. Remap is that you can remap to, and a shortcut that has more non‑printable keyboard characters so control, alt et cetera, and keyboard shortcut is only active when that component is used.
So I wanted to put at least one more — it's always sunny — [LAUGHTER] (credit: 20th Television operates this is Charlie from "It's always sunny" and he's in front of a cork board, that says, pepe Sylvia, this is just saying if you're going to have keyboard shortcuts, you allow the users to either turn their off or remap them to fit with what's best for their needs. So, yeah, this kind of takes — this is the success criteria, I know it's quite a lot. [LAUGHTER]
When you — but really, I mean, it's all — when it's all said and done, it's really just — good things to do. Like, this is — I think it's all kind of inherently — yeah, why — pretty much let the user do what they need to do to use your application. That's what it kind of breaks down to me, it's, like, don't stop them from using the orientation that they want. You know, make sure they know what — what things are — you know, named. You know, let them, you know, use the input, the keyboards that they want — if they want, the — the headphones they want. I think WCAG can be very dense. But when you — hopefully this will break down, really kind of, helped you out in kind of, you know, getting the gist of what these success criteria are. And I wanted to go over a little bit over, like, different Accessibility Features and Tools for the different... operating systems. So I'm going to go, both Apple and Android™. I think when it comes to mobile accessibility usage — (graph: Mobile platform usage) you can see, this, is from WebAim. It's another graph. Talking about mobile platform usage, and the graph goes from 2010, to October 2017. And it has iOS Android™, and others, iOS is kind of — has the larger share, so starting with 33% of the survey — people surveyed using iOS, in 2010 to 76% in October 2017, and then Android™: Where 4% of the users surveyed used Android™. Going to 22% in October of 2017.
And then others: Started at 63% in December 2010. And then going to 2% in October 2017 — I believe — I — I couldn't figure this out, but I wondered if that's when, like, Windows Phone died — [LAUGHTER] So I have that feeling because I'm, like, I think that's when — like, I think that was when — Windows phone! [LAUGHTER]
So I — I — so I know — and the — I still want to focus on both because I do feel that, when it comes to mobile devices, I — there are more — iOS — and this is certainly, just my opinion — price‑wise, I feel that it — there is a barrier for some to get an iPhone. With prices. I know that's kind of — it's — it's come a little bit, you know, — maybe that's not true so much now; but in the past it was, where, you know, the price of an iPhone versus — I don't know, if — you could get some burner — like, phone, with Android™. I feel there is — you can't and you shouldn't just focus on improved accessibility for just one particular OS, for people. So I know, for a lot of people — and a lot of companies — they only have iOS — they — they may have only iOS native applications; and that's — that's all you can do. But there are a lot of places, where they have both. And once — and one or the other suffers. Because then — and I know that's true for outside accessibility; but I think it's just — it's — I don't like it. I feel that, you know, if we — if you truly care about Accessibility, you're going to make sure that everyone can use it. Even if they use the less‑desirable, you know, Android™, which I — [LAUGHTER] I got called — oh, because I use an Android™, by someone on Twitter! [LAUGHTER] Just outside that — we're not going to — but, yeah, I — so that's why I'm kind of focusing on both, and not just focusing on iOS. Even though iOS, is — has the bigger share.
(Next slide) so when it comes to iOS features: They have quite a few — and they both kind of have similar features. So iOS, has Voiceover, which is the screen reader; they have Zoom, where you can — Zoom for text, Magnifier, you can invert Colors. You can — you can make text larger. And you can also use switches, which, is — for people who have limited mobility. They can use a switch to control their phone without — again, that goes back to the success criteria of allowing users to use alternative inputs to navigate your site. Android™ — accessibility features are Talkback, which the screen reader, magnifier, switch control, also high‑contrast text; larger text, live caption — and transcribe. Live caption and transcribe are new. Live caption.... is — I actually — talked to the developers there, because, it wasn't really playing nice with Talkback, but they've put a fix in — [LAUGHTER] Mainly because I was, like, I don't — because I complained enough, and I was, like, well, I use both of these! I use Talkback, and live caption and so they're putting a fix in, because Live Caption — like, Talkback, wouldn't announce when live caption was turned on. And I just feel if your phone is doing something — it should announce! [LAUGHTER]
That — you know, that something has turned on. So, special note about Talk Back, and voiceover, especially when the comes to testing, these are probably the biggest kind of tools that you'll use. This — I mean, really, you.... definitely (you don't want to neglect — you know, the next — other things, sometimes I feel that can happen. Where there's not — like zooming in on text; making sure that things don't get distorted. If somebody zooms, like, say, 200 to 400, but Talk Back, and Voiceover are certainly the two biggest testing tools. To use. And those are the two screen readers for Talkback for Android™, Voiceover, for Apple iOS. So, when it comes to (next slide) tools, and I realize, I — forgot to — I forgot to fix this slide.
Axe for iOS, actually, I don't think it's any longer a thing. I could not find a — it used to be a — it was going to be a tool that DQ was bringing, like, their A xe for Android™. I can't find the page anymore. It's kind of been scrubbed from their site. If I'm wrong and I was looking in the wrong place, someone please let me know. And also accessibility inspector Xcode, a very good tool if you're an app developer, it's pretty much the main tool you're going to use. There are other tools out there. — don't look at the tools I'm listing here as the end‑all‑be‑all, because they're not. These are just ones either I've heard about, or — for Axe, except for iOS — I've heard about it or I've used personally.
Android™ accessibility tools, you have A xe for Android™, that one does exist. So — and it's, you know, really good for — again, for any sort of Android™ development. And you want to — accessibility development you actually it's very good. Accessibility scanner: So if you have an application and you want to scan for accessibility issues and your accessibility scanner for Android™ is very — a very good tool. And then, also, the Android™ Accessibility Test Kit — this is just the site if you go to — if you're an Android™ developer, it has just — there's resources and information, about kind of how to, you know, really — you know, develop for accessibility, in — for Android™ application.
(Next slide) and that.... is.... it! Thank you very much! This is my Web site, I think the LinkedIn is wrong, but it's correct on my Web site! [LAUGHTER]
And so, you know, Web site CrystalPrestonWatson.com. I'm not going to read the LinkedIn one because it's incorrect. And I do know what it is, I do know, I corrected it on my Web site, and my Twitter is@Scopicengineer. And I do have some resources — you can —@me on Twitter. Or, you know, find me on LinkedIn, and — if you want some links to these resources, I can definitely let you know. I can send those to you — yeah, and that's it.
[APPLAUSE]
Santina: Awesome, Crystal, thank you so much. Everybody is responding very well in chat so you can go ahead and read that. And, you know, if — if folks want to take themselves off mute, give a little golf clap, please feel free to do so, or, you know, go ahead.
[APPLAUSE]
Crystal: Thank you, all!
Santina: It was really great and great how you took the time, and settled yourself in the beginning of the presentation. [LAUGHTER] You know, that is important. It's so tough to give a presentation to folks and you handled that amazingly well. So thank you, so much. I really appreciate it.
Crystal:. It's so funny. I can do improv, and I only get nervous before, but I'm, like, — I do this as a job, and now, I'm, like, oh, no.
Santina: When the two kind of coalesce, I know, it becomes a whole other different thing, yeah, 100%, I agree with that.
Some of the questions that we received throughout — I'm going to go ahead and read them. I know that some other folks tried to answer them, but I would love to give you the opportunity to talk about that. Q&A session: One question we had was, how does allowing the changing of orientation, help users who need additional accessibility to use apples in mobile Web sites. So that's specifically with the change of orientation, if you could speak to that?
Crystal: This is especially for those who need, say, someone has — does have, like, limited mobility. Who may use a — like, a mouse‑stick, so they would — they wouldn't actually be able to hold the — the — say, their phone or their iPad in their hand, and it's going to probably be attached to something. So they can't constantly turn the — the, you know, the phone, you know, different ways. And so, that's why, you want to be able to allow people to just — if they want to have a fixed orientation, you shouldn't force that. Am I — maybe, hopefully, that's what they were referring to, you know — why wouldn't — why you would want a user to — to — have a fixed orientation. Because some people just, literally, cannot, you know, keep switching the phone around.
Also, as I said, with — with Talkback, I found, when I've had to, say, if — a site, or application requires me to use a — in a landscape, then if I am — again, I can't — it works, but I have to — so, I can do — so I have to go, like, this, to pull up the menu, because I'm very reliant on the menu for Talkback, so if the application is in landscape, I can't pull up the menu — the menu can only be pulled up with the gesture in portrait. So I — and that's very — you know, and, again, for me, personally, it's not the end of, you know, — I — I can do it. It's very frustrating, but for some people that's just, literally, not possible.
Santina: Awesome, thank you for that. I did get a question, I think it's directed specifically for the Accessibility organizers asking — if the slides would be available on the a11y Web site, I do not believe we have a Web site, but we will go ahead and post them in meet‑up.com, the meetup group there, please do look for them there. And I don't know, if Crystal, if you plan on posting them to your Web site, we can go ahead and direct folks to that as well. If you would like.
Crystal: I will, but — [LAUGHTER] I will — but they will not be up tonight.
Santina: Yeah, no not a problem, and Nick did chime in on the chat and say they are on the event page, if folks want to access that immediately, we certainly do have that. And we do have links in the chat as well. So that's not a problem. Another question we had is... Is there a good tool for checking color contrast on iOS ordroid. For now I take a screenshot and use color contrast analyzer on my desktop, from Glen Walker?
Crystal: I — I've — you know what? I've heard that they might be — I — off the top of my head, I know I've tried various ones. And this — and this has been, like, about a year ago, that I've really looked. I can't — there is none that I can say, I can absolutely say, it's top of my mind, yes, this is a good one to do. Honestly, what you're doing, is what kind of — how it's done, so if someone knows — I would love it. But I don't know of one, I'm sure there is some out there that say, that they are, but, again, I — I haven't found any — I'm, like, yes, this is amazing.
Santina: Sure, so if folks do have any kind of recommendations, feel free to add that in the chat. I do know Android™ does have a tool, but you need to have that hooked up to the computer. Otherwise, I don't know of any myself.
Crystal: Yeah, that might be through Android™ Studio, yeah, and so that's — and I believe — I was — it's the same way. It's, again, kind of one of those things, if you're a developer, that's very easy to kind of — I'm not going to say "easy" but it's more accessible to do. But if someone is, say — as a tester, I know, I don't do all my testing of an application, like, in Android™ Studio. So, yeah. [LAUGHTER]
Santina: Yeah. Sure.
Crystal: And I am wearing the A11y cat shirt.
Santina: Oh, you saw that question! I think we had a follow‑up question on the color contrast... What is the best way to do color‑contrast test using hex value to color picker? So just some advice on what the best way to do that contrast test.
Crystal: I — this one is a little bit — I think this is slightly.... You know, I — I'm not going to — because I'm — I'm not going to really — I really can't... I just use hex value. And — and I don't want to say that is the best way. [LAUGHTER] So I — so, I'm going to, again, kind of ask other people, if there is a better way. That's just one of those things of where I'm, like, I — I — I haven't done a lot of kind of the color contrast. So in the stuff I've done, it was just, yeah, so — [LAUGHTER]
Santina: I hear you. We'll go ahead and open that up towards the end so people can talk about it. And honestly, you know, our discussion with what could you give a 20‑minute presentation on? There's so many ways to test color contrast, and perhaps that can be an entire 20‑minute presentation.
Crystal: Yes.
Santina: We're going to go ahead and table that towards the end if we have a little bit of time. I'm just making sure I have some of the other questions that we have in here. One moment... For 2.5.2, allowing a user to cancel a triggered event, are there recommended events to ensure we account for, or is the ideal to have this on most or all?
**Crystal:**Can you repeat that? I'm sorry.
Santina: To allowing a user to cancel triggered event — are there recommended events to ensure that we account for, or is the idea to have this on most or all? So feel free to chime in. That was from Steve. If I'm not capturing that question right or if you wanted to clarify, feel free to take yourself off mute or to clarify that in the chat.
Steve Woodson: Yeah, maybe I worded it weird. I was wondering what events would we want users to cancel? The one that came to mind initially was delete or something that could not be taken back —
Crystal: Yeah, so anything that — that really is going to alter — so, like, delete. Anything that's going to submit, like, a form, anything like that. So, say, you're — someone's — if you have a form on — your application has a form, and there — and the user is — kind of kind of touches the button and there's multiple options and those options are going to allow them to send something, and — there's no way to back out of it, as soon as they complete that action, that sends it. So you don't want things like that, especially if there's no way — there is only, once you — once you — you're in the action — there's no way out of it, and that — and the completion of that action, is going to submit or remove content, or — a functionality, from — from that application, or — or that — that form.
Steve: Great, thank you!
Santina: We have a question from Sophia: Any advice on getting buy‑in, for supporting WCAG 2.1, as opposed to just WCAG 2.0AA which is more common in lawsuit rulings?
Crystal: Which is more common in lawsuit rulings? Oh —
Santina: How to get buy‑in for 2.1, as opposed to 2.0 since that's traditionally been used in the lawsuit ruling.
Crystal: I see, I have — you know, personally I haven't run into this issue; but, I think, the best way is to say that — we're getting to the point, especially when it comes from, if you are a — a company that has been present on the web, which means you have presence on mobile devices, that the adhering to 2.1, means you're also solving for mobile accessibility issues. And the thing is, it's, like, well, why not support 2‑ — again, it's all the success criteria for 2.0 are in 2.1, with added — like, — and, like, kind of just, like, with added protection. You know, added protection, for mobile accessibility. Things to do — 2.1, also kind of deals with — with the older pop‑ — things that affect older populations. So I think just saying hey, let's just be — instead of being, you know, defensive, you know, we're offensive. I am — I don't — [LAUGHTER] I don't play, these sports, that's a good analogy, pretty much, like, saying things are going to move to 2.0 that's going to be kind of the — eventually the legal, kind of legal adherence so let's get a jump on that. I feel if you put it that way, sometimes you can't appeal to the humanity of people, appeal to the pocket. And just say hey, eventually 2.1, will be sort of sited in lawsuits, so let's try to circumvent that.
Santina: Absolutely. Great. We have another question: Would you recommend using CSS media queries for not restricting content to a single display or no?
Crystal: Oh... — I don't want to use, — I'm going to have to — I'll have to get back to you on that. Let me look at — that's a little bit outside my — and I'm, like,. I'm going to think about that one, if someone wants to answer that, otherwise, I can get — I can find out for you quickly after this.
Santina: Not a problem, and, again, we can open it up for discussion afterwards, so we can certainly hear from others as well, on some of these questions and ideas others may have. One last question — before we go ahead and wrap up, and open that up, to a larger — a larger discussion, is — How about Lighthouse on the Web? Any thoughts on their accessibility audit? Are there areas that can be improved?
Crystal: I — I don't — so, I've used it. I feel that it's a tool. It's not something to rely, you know, — it's not the end‑all‑be‑all, it's just — it's another tool. I think it's good, at letting you know of more things you should look into. It's more of — there is an article, I'm forgetting the author's name, that actually got 100 — a complete, like — this is great accessibility on a site that was completely inaccessible. And so, there is a — you can't overrely on tools, it seems like it — I know, it's — it's nice to think that you could, to just push a button, and then it's going to tell you everything you need to know. And then as long as you fix, or do things to that, you know, every time you run in and fix the things in there that you're good and your golden — but that's just not the case. And so, I feel that Lighthouse is good to kind of — is a good starting place. But, there are so many things that you can't — it can't account for. There's so many, yeah, so, it's — one of those things, like, it's fine. Just don't, you know, don't think it's — you know, — don't use it, and think you're going to be, like, oh, cool! Lighthouse said — we're completely accessible, because you find yourself — in these lawsuits because, yeah.
Santina: Awesome. Awesome. [LAUGHTER] And I love that our chat community is posting the references that you mentioned. I don't know if you can see that. They actually posted the link already to the article you mentioned, which is fantastic.
Thank you. I want to thank you, again, and give the group a chance to thank you again, feel free to take yourselves off mute and do a little golf chat. Thank you so so so much. We appreciate the talk, you did an amazing job, I really appreciate you joining us.
Crystal: Thank you, all, so much.
Santina: And folks can go ahead and unmute themselves, and as I said, we'll go ahead and give some time for some discussion afterwards. I just want to mention, again, the job posts — we did have some folks posting for jobs they were looking for to fill. As well as they were looking for jobs as well; so go ahead and scroll up, if you are in the category of either looking, or looking for a job. We do have that posted in chat. As I said feel free to take yourselves off mute. We can talk about some of those things whether that's the color contrast issue, or — whether that was the media query, of whether or not to restrict it. So go ahead and chime in.
(A pause)
Santina: And if you need a drop, feel free to drop as well. This will be posted on our YouTube afterwards; and as I said, we have the links for the — for the slides posted in the Meet‑up group.
Gregory Haynes: I'm wondering if we can get some more context on the CSS media query question
Santina: We cannot hear you, I can hear you just barely, coming through.
Gregory: How about now?
Santina: That is much better.
Gregory: There's an issue with my headphone port: My name is Greg everybody, it's nice to meet you‑all, and I guess what I was asking, in regards to the media query question: Is, is — for instance with media queries, how — media queries are used to basically — to basically have content fit the — have content fit for, like, different devices on different screen sizes. I was wondering if that could be used in the same way as well to — on a mobile device, in order to have it not fit to, like, a single — just a single one display or not.
Crystal: Yeah, I'm — yeah, actually, I'm not sure about that. So I will — I mean, I can look that up, because that's something I know I should know. And I'm — and I know I've dealt with this before, but for the life of me, I can't remember! [LAUGHTER]
Gregory: That's fine.
Crystal: Yeah, I will — but, no, I will — yeah, let me. If you can keep in contact with me, I will find this out for you! Because I want to know. I need to figure out the answer too. Quick follow‑up, maybe question with that Gregry (Glen Walker) you're talking about media queries, for Web sites. I understand that. But are you talking about is there an analogous type of technology for mobile? Native app mobile development?
Gregory: Well, I guess the thing is, what I'm saying for media queries, is that media queries or CSS media queries, like, they fit content into kind of, like, how responsive design works — or, like, how media queries are use in responsive design. They fit content with different — they fit content in a different screen width that can be both for desktop or mobile or Tablet. Or even, like, I believe, a television screen width — I'm not too sure, but, yeah — but, yeah, like, that's what I specifically mean by media queries, also fitting in to that, like, mobile screen width as well too.
Glen Walker: I was just asking about technology‑wise. If you're talking about all mobile — I mean, sorry, all web version of technology, whether you review the Web on your desktop TV or mobile device, CSS media query, yes, absolutely — I mean, that's the whole point —
Gregory: Yeah.
Glen: I didn't know if you were asking for native app development which is very specific to iOS or Android™. Right? Those are — those have a way to develop your app so that you can view it in portrait and landscape, but other than those two orientations, I'm not aware of any native app type thing, to allow different types of queries.
Gregory: Okay, got it. That makes sense.
Steve: And I do believe there's also CSS media queries that allow us to know whether they aren't in portrait or landscape mode. It's not to lock them into one or the other, but if there was something that was... preferable in portrait, but not on landscape, that is something that could be effective with CSS as well.
Gregory: Got it.
Santina: I think some good examples of this is, actually, either you can bring up Google Maps, on any device or at least, with an iPhone, if you bring up the calculator — putting in portrait versus putting it in landscape, will reveal very different things. So having features that are hidden away, that people wouldn't be able to access, in one particular orientation is really where the problem is. So that's. Crystal: Yeah.
Santina: That's what the specific conformance item is talking about, rather than mobile web — it's talking about the apps, and being able to change the orientation without losing any kind of functionality. So, that's — um... that's probably what the — what the ambiguity is here, over media queries. That's a completely different conformance item (laughing) so maybe if we could think of it in — in that regard, I guess. (A pause)
Gregory: Mhmm.
Santina: Anyone else? Any further discussion? Anything you would like to mention? Any shameless self‑promotion? You would like to mention at this juncture? (A pause) awesome. I guess that — that is going to wrap. We're going to wrap a little bit — well, I guess we're a little bit over. So, thank you, everybody, so much for coming. And thank you, to our sponsor, McDonald's, for the live captioning! And don't forget: We do have the event coming up for global accessibility awareness day on May 21st, where myself, Fen, and Q, will be talking about invisible disabilities, join us a little bit later in the month. Otherwise, thank you, so much, everybody for joining! We'll see you next time. Thank you! Bye, everybody
[transmission concluded at 8:49:45 p.m. Eastern Standard Time, stenographic captioner: Anthony Trujillo.]