>> MICHAEL BECK: Welcome to Technica11y. A Webinar Series dedicated to the technical challenges of making the web accessible. This month our presenter is Mallory van Achterberg, senior accessibility consultant at Tenon. >> MICHAEL BECK: Hi, hello, everyone, and welcome to this June 2019 edition of Technica11y. I'm Michael Beck, the operations manager at Tenon and your beloved host and moderator of this incredible Webinar Series that we have going on here.
Seriously, this wealth of knowledge, the good practical knowledge, that we have gathered here is pretty astounding and I do sincerely mean "we." The questions that you've asked of our presenters have only served to flesh out the details and make information more relevant, more actionable and most invaluable of all, invaluable I guess you'd say. So before we get to this month's topic please give yourselves a round of applause, a pat on the back, or perhaps treat yourself to something extra delicious today. Oh! Speaking of which, "Eid Mubarak!" to any of our Muslim attendees who may be taking a break from their festivities. You really do deserve something delicious today. Quick note for those of you who were expecting Rian Rietveld today as I announced at the end of last month's webisode, we had to reschedule her and she'll be presenting in August. This month we have Tenon's own Mallory van Achterberg with us. She's in the hot seat. Hello, Mallory!
>> MALLORY: Hello.
>> MICHAEL BECK: Long-time attendees know that Mallory is one of the more vocal members of the peanut gallery, as it were, but this time I've turned the tables on her and she'll be talking about designing and coding for users with low vision and, before I hand the reigns over to her, as a technica11y first, Mallory has made her slide deck available to you, so you can use your own device and whatever assistive technologies at your disposal to follow along instead of just relying solely on the video feed from Zoom. I'll put that link in the chat box right now for those of us in the live feed and it will be down in the description if you're watching later on YouTube. So that's it for me. And take it away, Mallory. >> MALLORY: Okay. I'm going to be talking about designing and coding for low vision. I'm going to be going over specific parts. And I will have practical tips when tips are something people can do anything about. When people think about accessibility on the web, they seem to like to focus on blind users. I'm guessing because, as developers, we're used to solving problems with code and screen readers are very code sensitive. But they're are really small number of people, there's much larger groups of people that we should be concerning ourselves with. But I'm going to focus on the low vision folks. First I'll go through a group of typical vision issues. It won't be all of them. But the first and sort of the most popular one would be just acuity. Things are not sharp. This is one of my eye problems. And I can wear glasses for things that are far away. But to make things sharp, the glasses make things very, very tiny. So what I'm more likely to do is to get closer to the thing or zoom in. Another one is cataracts, which can cause both blurriness like we saw before and it can lower contrast and a lot of people don't notice right away if they have something slow and progressive like cataracts that their vision has deteriorated. This is my only moving slide, I promise. But, with diabetic retinopathy you have blood clots floating around in your eyes while your vision is slowly degrading. With glaucoma, you lose peripheral vision, so you can see things mostly in the center. Whereas with macular degeneration and other things, peripheral vision is all you have and this would be a group who would need to zoom out, for example, rather than zoom in. And colorblindness is not new to anybody and yet we keep forgetting about it as we design things. So there's various ways people with low vision can deal with it. And I'm going to go through those. They could use a text-to-speech engine. They might use a screen reader, but that really is a very complex piece of software. There are also much simpler text-to-speech engines that usually will highlight where it's reading or read where the mouse is. But that's one thing some people can use. What may surprise people is that zooming out can be a thing. I'm showing a slide from a talk by Damien which is a really great talk and in my slides I link to their slides. But if you can find the talk online, it's really great. In the talk, he (sic: they) explains that most people when they are reading rely on the shape of the words to tell what it is. And if you're really zoomed in and you can't see the entire word and can only see one or two words, then you lose that speediness you get by recognizing shapes of words. You can make the fonts larger in your operating system. But, that doesn't mean that all the applications running on your computer actually are listening to it. I had a heck of a time setting up pass codes because the line heights were apparently very rigid. Most operating systems have a magnification software built in, although the one for Linux kind of has been abandoned and there are third party screen magnification programs. The thing about screen magnification is, it's as if you have a credit card sized view of the entire screen and you move that view around by moving your mouse. Or, if the application supports it, by keyboard focus. As you tab around, that little magnified viewport will also move with it. But you would be surprised how many people just lower the screen resolution because the application just doesn't make the fonts large enough. So, if I'm down by 600 by 800, I can actually see some of the text on Dragon's startup window. Another example is the GIMP (GNU Image Manipulation Program), something ported from Linux. If I actually want to read it, I have to lower my screen resolution, so, if you hear people saying nobody uses 600 x 800 anymore, that's not entirely true. Most operating systems have a high contrast setting, which is great, but, I'm going to specifically call out Windows high contrast because this tries to really ensure that the minimum contrast is really high, at least 7 to 1, if not higher. It's not the same as reverse color or inverse video. This is definitely special. So, I always make a special callout for Windows high contrast. If you need really high contrast, Windows has excellent high contrast. And, unlike a plug-in that might be sitting on a browser or an application, this is operating system wide so long as the application listens to it, which not all applications do. And there's always the good old nose to the screen. This is still a thing. If you want to have the text seem larger without only seeing parts of a word, sticking your face right up against the screen is sometimes the best way to go. So, there are very typical problems that come with low vision, which I think if I show them, my goal is that those watching come across something that they hadn't thought of and will think about it the next project that they do. So what is magnified scrolling? You can't do anything about this. If you're using a screen magnifier, if I want to read a sentence I have to go from left to right and there's nothing any designer or developer can do about this. Text doesn't wrap inside magnified viewing because that's not just how it works. However, for people who are using browser zoom, that is something you can do something about. Here in GitHub, if I want to read this comment I have to scroll from left to right and back again. That's not cool. Same with Gmail, which I actually can't use this view. I have to use the plain HTML view which still means I have to scroll but at least then I don't have two huge sticky things wasting lots of my screen real estate. Don't do that. So, I'm using GitHub's code here. And I'm using one of their pre-existing breakpoints. I don't set my breakpoints in pixels but an example of what you could do is, if the screen is smaller, undo floats and let widths be auto. That wouldn't work on GitHub alone because there are other things that have widths set on them but also because the Flexbox in the header. Flexbox is something I'm starting to see more and more is causing issues and I'm showing CSS-Tricks on my slide because it's mostly done pretty well. They are mobile responsive and their Flexbox is really clean, so it's easy to show in this example: I have a logo, a search control of some sort, and the other control is offscreen and that's because that whole header area is a Flex container. If we let things wrap, at least I would have access to it. The default for Flex wrap is no wrap. If you have a Flex container in things in a horizontal row, you have to check if you zoom in whether or not those things can wrap if they need to and again, you can use a media query and again, I grabbed one that was already on the CSS-Tricks page. This is just an ugly but functional thing which is fine, but you could also, of course, make it all pretty if you wanted to. Getting lost is very common when you're zoomed in quite a bit. And it gets worse when excessive white space is used for design reasons. Lots and lots of white space looks clean. So many Websites are using a lot of it. But, then at some point, you run out of landmarks. And I wanted to make a special note of cards that are usually very large clickable areas that have a bunch of text. Now, Rian will be talking in depth about cards on another technica11y, but, I wanted to mention them here because I've seen cards that are not done well like this one. This one is from the Event Apart Website which does it well. I can still read this. They darken the text slightly when you mouse over it, but in other places I've seen it where everything gets completely dark or the text is replaced with some other text or a picture is loaded on top, and what I want people to keep in mind is that for some people the only view that they have of the thing on the page is the hovered view. There is no default view because you can't get something into your viewport without either moving the mouse there or moving keyboard focus there. There are ways to get around that with the screen magnification software. You can use something where there's an unmagnified part to help orient where you are and a magnified part to read. You can have it attach to your mouse which I think I just heard Apple's recent...they had some big update and they have something like this now, which is nice. Or you can dock part of it. Docking is not great unless you have multiple monitors, in my view. I always tend to do full screen and if I need to orient, I'll turn off the magnification, figure out where I am, turn it back on, but if you have multiple monitors, this isn't uncommon to have magnified and unmagnified views on separate monitors. But, it's not always useful if you don't have the room to do that. And a big issue is auto focus. Auto focus is just throwing you some place on a page and the screenshot is from GitHub from a couple of years ago. I'll go back. This is what GitHub looked like and you would auto focus on the "Pick a username" despite the fact that the website has lots and lots of links and lots of buttons and lots things you can do they assumed everyone who came to GitHub.com doesn't have an account and if I moved my mouse down I would see the "Your email address." And this is not cool. They had a label. It was technically accessible for a screen reader but the label was hidden and they relied on placeholders which vanished when you were auto focused on something. That's not cool.
Cookies are often sticky and Trello, at least, makes them sort of mobile responsive. It squishes but because it's absolutely positioned and stuck to the bottom, I can't see the top and I can't scroll up any higher. Even more common is the button to close the cookie warning or to accept the cookies is off to the right, but, because it's position fixed, I can't scroll to the right because you can't scroll fixed position things. LinkedIn is a terrible example of this. Don't make your cookies sticky. It's very popular to have a drop-down menu stuck to a sticky header, meaning if you open up the menu, you can't scroll down to reach the bottom of the menu. Don't do that. There's a mobile version of what I showed was Twitter. This is a mobile Twitter. But, while the mobile version looks actually pretty good on the portrait mode of a phone, I'm going to get a mobile view if I'm zoomed in on a desktop and the difference is a desktop is going to look more like a landscape orientation than a portrait and now the height matters. You get huge things covering up text. Don't do that. The menu is better, though. I have a large scrollable area. So, the menu has been fixed. It's still stuck to the left, but it's been fixed by giving me a larger scrollable area. Another example is T-Mobile which has a drop-down menu of like 40 items. It's huge. But they are mobile responsive so I can zoom in, right? But when I do there's a big empty sticky thing on the top and I can only see a couple of items at a time and additionally they have put title attributes on the links with nothing but a smaller version of the text that's in the body of the link so it gets in my way and makes them more unreadable. Don't do that. You can test for a height and I have some example code where I'm using a max height of 10em but whether you're going to use a min height or max height or 10em or something else, it's going to depend on how big your sticky is. Does content inside it wrap as people zoom in? You have to check it yourself on a browser to find out what numbers work best for you. That way, if the designer or somebody else insists that something is sticky, it's not sticky once people start moving in and the heights of their viewpoint is limited. Tool tips and popups have issues. Most designers and developers do it right with drop-down menus, where we're used to hovering over a menu item a drop-down appears and the mouse can go over the new drop-down that's appeared and it stays on the screen, but sometimes people forget to do that with tool tips. An example of where it's not been done is JIRA. I moused over a button. And it has this big tooltip that shows up. But I can't read it because to move back and forth to see all of it I have to move my mouse back and forth which means my mouse is no longer on the button, which means it's vanishes it's unreadable. So, the tooltip itself should stay at my mouse moves over it. It can also be the other way around, where it does stay on mouseover. I'm showing a screenshot on Twitter if you accidentally mouse over say, a username, you get a whole huge bio, which is good if I want to read it but it's bad if I want it to go away. I should be able to close this without having to carefully navigate my mouse around it and out of the edges. For example, by hitting the escape key or you could make it that wherever my mouse is if it's not on a link that clicking there could maybe make it go away. For this reason, I'm not a huge fan of CSS tooltips because it's difficult to have the closing with something else without moving the focus or the mouse; it's generally Java script. I have seen a complex CSS solution for this but it was a very complex CSS solution. Title attributes in general. You can't do those kinds of things like making it hoverable or making it vanish because it's generated by the browser so, by adding a title attribute, this popup just shows up and the developer has no control over it. I'm showing a screenshot from WordPress.org which, this has been fixed. This was an issue that they had in their tracker and somebody was arguing that, "Well, the title attributes were nice, they were just extras and they were just injecting a bit of fun into the page," but I showed with this screenshot that I can't read enough of it to tell if it's important. Do I need to read this? I can't. Because as soon as my mouse moves to the right I'm not hovering on plug-ins and it vanishes. And some people like putting title attributes on containers, which is awful, because everywhere your mouse goes, this stupid little title tooltip shows up and it covers things making stuff hard to read and depending on the browser, it may or may not vanish after a certain pert of time. Avoid title attributes. Really think twice if you think you need them. Windows high contrast is one of my favorite topics. I'm showing on example of sort of a custom form styling page. This is old. This was developed by one of the Twitter guys. And this is a styled select drop-down and it's fairly accessible. It uses an actual select with actual options. It does everything a select does but it looks funky. In Windows high contrast, it looks like nothing. You can't tell what it is. Be careful of styling custom form controls. There are two things I can always tell people to do that should just work without having to use special high contrast media queries or anything. One is you can always put a transparent border around the element itself. Then, people can see where the hit area is of the thing. And you can use a transparent outline on focus to show, "this is what it looks like focused," because the original uses a box shadow. I didn't take a screenshot of it but box shadows don't show up in Windows high contrast for good reason. Here we can see what the thing is and we can see that it is focused. But, we're still missing the arrow. And for me to know that this is a drop-down, I have to see that arrow. That arrow is a very important visual cue for me, but because it's a CSS technique arrow that we've been using for years where it's two transparent borders plus a visible border, we should use something else like SVGs. But be careful with SVGs. It's very common for programs that people use to make SVGs to put in an inline fill or stroke color in the actual SVG code. Don't do that.
Because you can't guarantee that the contrast is good. What I typically tell people to do if the SVG has just one color, whether it's stroke or fill, is to set the color you want on a parent element as a color property. And then have the SVG have its fill or it could be a stroke set to current color. Because what that does is as the high contrast theme changes text color, the SVG will come along with it and it will ensure the contrast is as high as it is for the text. Now, you might have an SVG with more color, in which case this trick won't work. I say for those people to give their SVGs a background color. Normally, it's transparent. If I set a background color to your SVGs that's the same color as the webpage, then only high contrast users will even see there's a background but that will ensure that the contrast is high enough and that the SVGs are visible. And States. This is a big one. People like to use color alone to denote states. I'm showing a log-in form with a disabled submit button, which I'm not particularly a fan of. But my high contrast theme here uses green to denote that things are disabled. So this person, made a button, they put in disabled and it works. But custom buttons are all the rage and here the developer attempted to do everything right. They gave it a role of button. They gave it a negative tabindex and set `aria-disabled=true` but aria-disabled is a thing for screen readers. It doesn't show up for high contrast because the operating system of Windows doesn't know anything about ARIA and it never will. But opacity is something that works. This has been my go-to suggestion for clients who say, "How do we show that our custom element is disabled?" You could lower the opacity, because it will look like this, which I think it works a lot. But what I want people to think about is, there's lots of states that you need to be aware of. Use outline for focus states, but it's very common for an error state to only change the border color of an input to red. Make sure that instead, there's also a small icon, an SVG icon, and that the error message is close by and maybe the error message even says something about error. If you have a bunch of buttons and one of them is `aria-pressed`, you have to be careful that that pressed state won't show up or if you make a custom drop-down where the currently selected item in the drop-down has a different background color that doesn't show up in high contrast in addition to the background color, think of something else, such as perhaps that's the only bold text option. Low contrast is something people hear about a lot. They are constantly hearing about contrast on Websites is too low. No matter how often you hear it, it's just still a thing. It's something designers really like because it looks professional or something. I have a link on my slides going to a discussion about the algorithm that is used for the WCAG luminosity contrast ratio because sometimes something will technically pass some color combination and everybody looking at it says, "But that's not readable!" If we switch to something else that may help stop those false positives from popping up so much, but, if that comes, it's going to be in the future. But, it's a very long interesting thread, if you're interested in that algorithm and where it comes from and what it might be replaced with, it's a really good read. There is a new trend I've been seeing on several websites. The text has plenty of contrast. But the links are denoted with something that's got practically no contrast such as yellow on white. Don't do that. Egghead.io uses blue on white. Now here, from the text, we have the word, "Links," above what are clearly links. This happens to be a page about Marcy Sutton. It's got what are clearly her Twitter, her website, her GitHub, but how would you know the word transcript was a link? It looks like a heading. Don't do that. Luckily in Windows high contrast, if you marked it up as a link, it will look like a link regardless of how badly it was styled. But, that doesn't mean set everything to black on white or white on black. Very high contrast is not easy to read. It gets in the way of people with reading disabilities. It can be a problem for people with dyslexia. It can make letters look like they are jumping. I have an example of a designer I know who has low vision and she needs very, very, very low contrast to read stuff. So her own Website wouldn't pass the WCAG minimum but this allows her to read it. I do have a trick for people who want to really quickly throw on a low contrast widget. This is not a good thing to do. But, it can work. You can throw on an overlay and then have `pointer-events` set to none so that you can still click stuff. But most Websites that allow people to log in you can actually dedicate time to making a lower contrast theme, if you want. Some of the reading plug-ins will lower contrast. And I've seen it on a few magazines, online magazines, that expect people to spend a lot of time reading but it's more common to find a high contrast plug-in than to find a low contrast plug-in. And lastly colorblindness is something we know about. We hear about it. And we keep forgetting it. Because stuff like this keeps happening. I don't know how many hundreds of people were involved in setting up a big American football game but nobody noticed the problem with red jerseys versus green jerseys on a green grass field until after it was on television where people call in saying I can't tell who is on what team. Or, for developers showing if a build is passing or failing. Using only color instead of additionally a symbol, an icon, or some text is a bad idea and we keep still seeing color alone to be showing some information. Don't do that. Here is an example of a switch I found. They are clearly trying to imitate Apple's little checkboxes that look like switches. But first of all, if I can't see the colors, which here they do have green for when it's on, and there is a directional difference, but I can't remember which direction is the checked direction because I'm terrible at that and I don't have any Apple devices. And if there was something else like a check box or something, some check mark that let me know, that would be better but this was pretty bad. I couldn't look at it and just tell is it already selected or is it not selected. And in Windows high contrast, it's actually completely invisible, except in these screenshots, you can see a border around the track because I'm focused on it with keyboard. Otherwise, it was completely invisible. Once you decide you want to make a custom control, you now get the responsibility of ensuring that it is as visible as the default native control. Don't do that. So, what should we do? Long list. I don't think people are going to remember all of these things. But I do hope that some of these things are in mind. Do mobile responsive, but keep in might that height can be just as important as width because almost all media queries I see are based on width of the viewport, but height is also good and you can test with browser zoom. If you use Flexbox, check the containers by zooming in. At some point, something might go off screen. Let the stuff wrap. Designers, when you're designing the general page look, use visual landmarks. Use consistency in things like alignments, distance between headings and stuff that they head and use white space. It's very important, but don't use huge crazy amounts of it, please. Don't use auto focus unless the page has one dedicated goal. Like, if there's also a footer full of links, that's fine. But a log-in page can have auto focus. But a page that happens to have multiple forms, no. Don't let me tab on stuff I can't see. Make feedback local. So that if it's on the edge, I didn't miss it. Think twice and then think a third time before removing keyboard focus styles. Kill all stickies, please, for the love of God, kill all stickies! Make sure tooltips or anything that shows up on hover is hoverable and dismissible. Keep Windows high contrast in mind. Use decent contrast. Stop forgetting about colorblindness and just test everything. Almost everything I've shown, with the exception of stuff viewed through a third party expensive screen magnification program, is stuff that anybody, developer or designer without accessibility knowledge, can check for, so I would love everyone to try zooming in, check the stuff, make sure it still works.
And that's my talk. >> MICHAEL BECK: All right, thank you, Mallory. Excuse me. It seems like I've got a frog in my throat now. Anyone have any questions? Just go ahead and throw that up in the chat box if you do. Nope? Okay.
>> MALLORY: That means everyone fell asleep.
>> MICHAEL BECK: Here we go. Doug asks if you have any good example of SVGs? (Chuckles).
>> MALLORY: As far as SVGs that look good or...? I mean mostly what happens is when I'm testing a page or viewing a page when I turn on high contrast, a lot of people have dark colored SVGs, dark gray or black on a white webpage and they look fine, and when I switch to high contrast, I never use the white, there is a white contrast theme, but whenever it's dark, I have dark gray symbols on a black page and they are invisible. They are just gone. Most of the time I'll check to see is there an inline color actually in the SVG or sometimes somebody will actually set the fill in the CSS instead of telling it to inherit from the current color. It's almost always the problem when I run into it.
>> MICHAEL BECK: He specifically means a URL for an icon for low vision. A URL of an icon for low vision. >> MALLORY: No. I've seen people use media queries to switch their icons, which I don't do because I think it's a lot of work. But, I have not looked specifically for low vision icons, although that would be a good thing to look at is, if an icon has a lot of detail, it's not unlikely that bits of the details might not be visible, in which case, if you have an icon that looks like a circle and another icon that's a circle with a little tail, that might look exactly the same. And having more room, there's a name for that thing that letters have, the gaps in the letters like the circle inside the letter A. The same thing holds for symbols. It has to be large enough that people can discern what that thing is. But I don't have a URL. I never look for special low vision icons. I'm sure somebody has made some. Microsoft probably has some.
>> MICHAEL BECK: Yeah that's a good point. Isabella asks, "I work for an agency that focuses on visual design. How can I work with them to ensure they don't feel like their designs are being compromised, yet still be accessible?" She feels like when she says things like, "Don't do parallax. Don't do scrolljacking. Don't do stickies," she feels like she is killing their creativity and she wants to find options to work with them.
>> MALLORY: Yeah that's difficult.
>> MICHAEL BECK: Any buzzwords that you think might help? >> MALLORY: Actually, when I worked with designers at Pearson, a lot of them asked, "Why?" or "How come?" And they all wanted stuff to be accessible. I never had to argue with anyone at Pearson to make stuff accessible, which was really, really great. I loved that. I never had to fight about it. What I could do is show people this is what my experience looks like. It's a little difficult with ZoomText for example. It sits on top of your GPU and you can't use something like Zoom or Google Hangouts and show the magnified view but I could use screenshots and I could say this is what I have. This is what your design looks like on my end. And I am a fan of seeing how much of the design you can keep and only adjusting it if certain things happen. For example, having sticky crap but once the viewport height starts getting too low, removing it, because at that point the page doesn't look like the design anyway. Or for the SVGs people want a certain color. You can style it with a certain color, but if you do it in a certain way switching to high contrast theme, I get my own colors well. At that point, your design doesn't look anything like what you thought of anyway, so I will try often to work with the designers to say, "What do you think are the options?" Some designers really thrive on having constraints and others don't, but if they do, they usually come up with stuff: "Can I do it this way?" or "Can I do it this way?" If you're lucky enough to have a direct dialogue with designers, let them show up with a bunch of crap, show them what the problem looks like, let them think it through and chances are they will come up with something where you can (say), "Do something like that and we can do this and we can do that." Sometimes it's, "Okay, let's add a control to the page," or "Make it a setting if somebody is logged in," that has a different design but the default is still what they were originaly going for. I'm a huge fan of seeing visible text labels of indecipherable hieroglyphics on buttons. Designers love things on buttons. I hate it; I don't know what they mean. If there was an option for me to click a check box that says, "Just show the visual labels," like they have on Gmail. On Gmail, that's one of the options if you're using the CSS version, the fancy version, you can say, "Hey, I only care about icons because I'm not a good reader," or, "I want the text with the icons." It's a setting. The original design was probably just with the hieroglyphics, but, with an option you can let people change it to yeah but I need the text or the other way around. Someone asked, I can see now what tools to use for zoom in a browser. Control-Plus and Control-Minus works with every browser I know of and often works with PDF viewers, as well. I once found a website for a blood bank that, it looked like it had a text enlarge widgets. It had a small A, a middle A, and big A, but when you clicked it, it was actually a link to a webpage that told you how to enlarge and shrink your text with your browser. It was brilliant. They don't have it anymore, but I loved that, because people in my country are used to those little widgets for text englarge that you see on websites.
>> MICHAEL BECK: That is quite brilliant.
>> MALLORY: I wish they had kept it. I wish they had kept it. Because it was amazing, because now people, they go to click it, that means it's the people who need that, they are clicking it and they get told, "Hey you can make all websites bigger text. Wow!"
>> MICHAEL BECK: It's almost like you have to trick people into learning.
>> MALLORY: Yeah, nothing wrong with that.
>> MICHAEL BECK: Yep. (Chuckles).
>> MALLORY: Good. We'll post that somewhere. >> MICHAEL BECK: Yeah, James had mentioned you can try to sell it as a challenge to the designers which you kind of basically said that in...
>> MALLORY: It can. It depends. It depends the designer. Some designers are...they like pushing the envelope, trying new things and they work better with constraints. There are other people who, that doesn't work for them. They have certain things they want or certain things that a CEO or somebody or a client said they really wanted. And then it starts getting into hacks and shoehorning, so somebody gets what they want but somehow it can be made to work for somebody else's needs. But, I think if more designers could see how stuff looks to those of us who have to adjust it and they see us struggling, or I believe it's Basecamp, 37Signals, some company like that. Their rule was anything that anybody built they were forced to go into a room and watch users use it. I think every company should do that and enforce it. I don't care if it's remote video. You get to watch somebody go, "Where do I go next?! What does this thing do?!"
>> MICHAEL BECK: That is a great policy. >> MALLORY: Yes.
>> MICHAEL BECK: I mean, even just having someone, a designer do that once or twice is going to have an impression on them. >> MALLORY van ACHTERBERG: Right. It might get them thinking.
>> MICHAEL BECK: Exactly. Making them do it all the time is going to really get them thinking, though.
>> MALLORY van ACHTERBERG: Yeah, and somebody says something about calls to action. So with icons on buttons, I call them hieroglyphics because a lot of times I can't tell. I've started to guess that the spiky circle is settings, but there's a lot of them I just don't know. I have another talk I gave about icons where I showed some quote-unqoute icons everybody knows what they mean. But, I found lots of instances of them meaning different things. So, again, the idea of, if you could then add a control where maybe the default was an icon, but there's some way for a user who doesn't understand it to go find the text. I'm a developer, so I right click on stuff. I inspect the element and try to see if there's a class name or something hidden or maybe hidden stuff for screen reader users so I can guess what the thing does before I click it, because I don't trust clicking stuff. But you can build that in, a check box or setting or something, where the default is still the general wish of the designers, this, because that is a good reason of icons make things clear and compact and lots and lots of text is pretty much the opposite of what you want for people who have trouble reading, for example. People with low literacy, people with dyslexia, often want less text. They want so minimum amount necessary to convey the meaning and icons are really great for that. But, there's the other way around where, "Yeah, I can't recognize what your icon means." So, making the page as flexible as possible for people, that's a sort of general thing in accessibility anyway. The user needs to be able to choose how they consume the content, how they interact with the thing, and the more control they have, within reason, is generally better, especially so long as it's not really difficult to figure out how to get that control. A lot of the tools I showed, there's a lot of people when their vision degrades all they do is stick their nose closer to the screen. They've never heard of a screen reader. They've never heard of screen magnification. They don't know anybody that does that, the eye doctors don't do anything about it, they never tell their patients, "Oh you could use this."
>> MICHAEL BECK: Yeah, or at best they will have one of those giant magnifying glass overlays that go over the monitor.
>> MALLORY: Yeah, that works and you do what you do. People will do what they do and as your vision goes down...we are visual creatures and we will use every last bit of our vision even when it gets to the point where, to be honest, we would have been faster, happier, and more efficient if we just switched over to a screen reader. But if you have so much of your brain dedicated to visual processing, yeah, people are going to use every last little bit of vision. That's what we do; we try to strain to see our little bits.
>> MICHAEL BECK: My dear mother only got reading glasses when her arms weren't long enough for her to read something. >> MALLORY: That's common.
>> MICHAEL BECK: Exactly. It's very common. It goes exactly to your point that we're stretching our vision to the limit. Even though we have all of this available technology to us. This old technology even, like reading glasses of all things.
>> MALLORY: Yeah.
>> MICHAEL BECK: But, yeah, the more people know about the tools they can use on their computer, the better.
>> MALLORY: Yeah.
>> MICHAEL BECK: There was one question in the actual Q&A thing. An anonymous attendee wanted to know more about stickies in regards to main navigation: one of your favorite topics.
>> MALLORY: Yeah stickies are my favorite topic. There's even a GitHub issue mentioned by Wayne Dick, who is on the Low Vision Task Force at the W3C, who helped add some of the new WCAG 2.1 Success Criteria that's focused on reflow. And he mentioned, "Boy, our How to Meet (the Success Critera) page should say something about stickies," and somebody else, I think it was Jake Abma, came up with an example that either will be, or maybe already is, on either the Understanding page or the How to Meet the Success Criteria page. There's been more discussion about it, when sticky things start eating up so much screen real estate. The guidelines will never be hard and set, though, because there's too many possible combinations and the WCAG tries to be very technologically agnostic and doesn't want to set anything too hard. A rule of thumb is like, if something sticky takes up more than a quarter of the visual viewport in a zoomed in browser, for instance, then that's starting to get to be too much. But, some people are okay with something taking half the room. I don't like it, but there are other people saying, "That would be okay blah blah blah." The reason people make stuff sticky is that they want something to be available for mouse users without having to do a whole lot of movement. For example, if you're a mouse user with limited mobility, where using a mouse is difficult but you do it or use a head mouse, having stuff at a close distance is an accessibility improvement, but for low vision person zoomed in, it's a pain in the ass. And that's why I like the idea of, "if the viewport has certainly smallness to it, then maybe we'll let stuff just scroll by." So it doesn't remove it from the page, but it becomes position static, if it's at the top of the page, that's where it is and I scroll away from it. Or if it's on the left side of the page, I scroll away from it. Or if it's at the bottom, I only see it once I get to the bottom, something like that.
With cookies, I almost want to tell people, always put your cookie warnings at the top of the page but also the first thing in the DOM order, so my first tab goes to the stuff for closing it. Because if it's at the bottom in the source code, I can't get to it very quickly on the keyboard unless you automatically move focus to it. I'm of differing views on whether I like auto focus on cookie warnings but some websites do it because they stick the cookie warning as the last item on the source and then you have to tab through the whole webpage to get to it, so they do that.
>> MICHAEL BECK: Charles just asked for a little clarification on stickies. Do you mean the CSS feature of position sticky or position fixed or something else?
>> MALLORY: It's both. Position fixed is almost worse because you can't scroll from side to side, for example. If you go to LinkedIn, I believe it's position fixed at the top of the screen and the thing has a width and you can't scroll to the right. Position sticky is a little different in that the idea is something starts off not with being fixed but once you scroll away it switches to fixed. I mean both of them because the end result is, I have something in my viewport that I can't get rid of and if it gives you the same effect of you stick Post-It notes covering part of your monitor and can't see the rest of your page...if that's the end effect, it will get rid of it. Those techniques are slightly different from each other but the end result is what I care about and usually the same type of media query works for both.
>> MICHAEL BECK: What would you say is a good alternative to stickies or position fixed?
>> MALLORY: I guess you could ask why you're fixing stuff. For example, I see social media buttons are sticky on a lot of article websites, news websites. Because to them, they may have some kind of an earning thing, money earning thing, with getting people to click on those and share stuff. Whereas I always have to go into my developer mode and display and delete the things from the DOM so that I can read the text that's underneath them. And my thing is, if something has to be sticky when people are zoomed out, I just don't want it to be sticky. Like position it with CSS in the place where it's supposed to sit normally, but if I can scroll away from it or if it can't cover the other text, that's my main thing. It's not really a replacement because the whole point of sticky is to act like a Post-It note stuck to a monitor and it depends on your reason for doing that. A lot of news sites do it because they want you to always see the name of the site they are on. You could argue that could have a cognitive benefit. And when you're zoomed out some of them are quite small they don't look like a big problem because, what is it, the Wall Street Journal or somebody? Some of those sites, they have this real thin little header at the top that doesn't look like a big deal. But, if you zoom into 400% and it's suddenly covering half your screen, you know, that's not cool. Don't do that. >> MICHAEL BECK: All righty. Well, we are coming to the end of our hour. And we seem to be dying out of questions. Thank you, Mallory, for not only that informative but very entertaining talk. I still love the slides that say, "No." (Chuckles)
I have seen it in the Dutch version and, "No," doesn't seem to carry the weight that, "Niet!" does.
>> MALLORY: "Niet doen!" Yeah!
>> MICHAEL BECK: It just has this gravitas to it for some reason which you really can't get more clearer than, "No, not do it!" Anywho, next month we'll have Eric Bailey on, accessibility advocate and inclusive designer at thoughtbot. He'll be on to discuss the intersection of performance in accessibility, highlighting the opportunities and techniques to improve website and web app performance by improving an accessible and inclusive mindset. I'm sure we have all seen instances where unnecessarily long and complex code that's in there for God only knows what purpose is put in the production. And it affects not only the accessibility of the product but also the performance. But I know Mallory knows what I'm talking about. That will be on Wednesday, July 3rd at 11 a.m.. Again, Eric Bailey talking about the intersection of performance accessibility. Thanks again to Mallory and thank you all again for your attendance, your questions, your retweets, and general support of Technica11y. I really do enjoy seeing the numbers of the participants go up with each passing month and we have you to thank about that for spreading the word. thanks to Clare from ACS Captions and I'll see you all next month.