Transcript from the "Accessibility Q&A Round 5" Lesson
>> Speaker 1: In regards to accessible colors, some of the things we run into sometimes is where the color is actually more visible on white than it is on a darker background, but it passes on a darker background. An example of it, if you go to accessible-colors.com,
>> Speaker 1: And if you just did a text color of 009900,
>> Speaker 1: And then background color of white,
>> Speaker 1: You could see it fails, but obviously, the green is a little more legible over the white than black.
>> Jon Kuperman: Yeah.
>> Speaker 1: Do you, I mean, have you-
>> Jon Kuperman: No, that's a really good point. So I mean yeah, like so these are, yeah, so when you're looking at color contrast, it's specifically looking from the perspective of being color blind or having some kind of condition with your eye.
[00:00:50] But sometimes, in an attempt to pass color contrast, you're actually making it difficult to see for people that have very good vision, right? Cuz yeah, in this case, I would prefer the green on white than the green on black, even though the green on black passes. I mean, I think, as much as it kinda stinks, is to find one that satisfies both.
[00:01:14] Find something that passes, but also is a little bit more legible. Cuz yeah, that's a tricky situation. I've also seen it, like I've picked terrible color schemes to put into that site earlier. And it's been like sweet, that passes. And I'm like what, no, I mean, it's so ugly.
[00:01:30] But those don't always go hand in hand. So yeah, I guess just trying to play around, find something that satisfies both parties. Sorry, I don't have a better answer for that one.
>> Speaker 1: No, I'm just curious cuz it seems that the algorithm is based on reflective light more than it is backlit displays sometimes.
[00:01:49] And so-
>> Jon Kuperman: Yeah.
>> Speaker 1: It kind of seems like it's a miss.
>> Jon Kuperman: Yeah, I mean, it's another thing, yeah, that would be interesting to do a little bit more research into how it's calculating these and if it's actually a contrast problem.
>> Speaker 1: The green on black wouldn't be so bad if it wasn't surrounded by white background.
>> Jon Kuperman: White? That's valid too, yeah.
>> Speaker 1: Yeah.
>> Jon Kuperman: Here? I don't know, trying to. [CROSSTALK] Yeah, no, I know. [LAUGH]
>> Speaker 1: No, yeah, that's what I'll do, yeah.
>> Jon Kuperman: Yeah, it's really interesting.
>> Speaker 1: Good point.
>> Jon Kuperman: Yeah, sorry?
>> Speaker 1: One thing we haven't talked about in much detail and we kind of glossed over is the distinctions between the different single A, double A, triple A categories, in so far as they relate to legal areas and legal risk for particular quality levels for your web site.
[00:02:58] I noticed that a lot of our checklists that we were going through, most of our descriptions tended to focus on just a single A level. But most of these tools that we're looking at are automatically set to be requiring things up like the double A level.
>> Jon Kuperman: Yeah, no, that's a good point and [LAUGH] unfortunately, it's a little bit intentional that they've been glossed over because they're pretty murky.
[00:03:23] So yeah, the definitions of what makes A, double A, triple A are not super murky, they're pretty clear. So if you go to the web aim checklist, each category will have, if applicable, will have what makes it each category. But when it comes to what is our responsibility for it, that's where it gets a little bit murky where there's not a ton of legal precedent on what makes an accessible web.
[00:03:47] So we don't have something as simple like, if it's an educational site, it must be at least, we don't really have that as much as we have individual cases of users saying that this can't work and that goes to court and whatever. So I think, yeah, unfortunately, that's missing from my slides on purpose cuz I don't really have a ton of good Information on pretty much any of the legal precedent stuff, you know what I mean?
[00:04:12] It's a little bit difficult to pin down what you're responsible for as what type of organization and what the legal risks are, you know what I mean? A lot of that is [CROSSTALK]
>> Speaker 1: As sort of a rule of thumb or a general principle from your understanding then, is the general area that we should be aiming for as good enough or a minimum bar of acceptability mostly A level, mostly double A level, making sure that we don't have a majority of things that don't even get to the A level?
>> Jon Kuperman: The thing is, so those get really tricky. And I'm curious what Jack's opinion on a lot of this stuff is too. But as far as, some of the differentiation between A and triple A or something like that, seems to really be application specific. Where it's just like, I'm curious, I know you've worked more on anything to do with legal representation sides of it, too.
>> Speaker 1: So what I can tell you is that the standard is double A. And what we've seen in terms of legislation, for example, in the EU in Canada, is that they've actually adopted the double A standard as law.
>> Jon Kuperman: Just taking it verbatim as, okay.
>> Speaker 1: Basically yes, and the US Federal government is on the way actually to be doing the same thing probably for final adoption in 2017.
[00:05:35] Triple A is really considered aspirational because even-
>> Jon Kuperman: Cuz some of the stuff, right, is, there's certain functionality you can't have and be triple A compliant, which is kind of a showstopper.
>> Speaker 1: Yeah, so shooting for double A.
>> Jon Kuperman: So what does it mean to say, I was just gonna ask about the NUS and ADA and so on, but what does it mean to say it's in law that you have to be double A?
[00:05:57] Does it mean like.
>> Speaker 1: So Section 508 was the piece of legislation that began to help define how, it specifically speaks to. Shoot, like when the Federal government goes out to purchase products, products have to meet certain standards. 508 defines what those standards are in terms of accessibility.
[00:06:25] And what they're doing is that they're actually going to take the WCAG guidelines, and they're gonna fold them into that law. So any money that the Federal government spends on any vendor, anything they buy from them needs to meet those standards.
>> Jon Kuperman: They need to be double A.
[00:06:38] So is that the same than in Canada and in Europe then? That's what we were talking about, there is that-
>> Speaker 1: Yeah.
>> Jon Kuperman: Canadian government does with the European.
>> Speaker 1: Essentially.
>> Jon Kuperman: Okay.
>> Speaker 1: Yeah, I mean, and again, I'm speaking very broadly about that, but yes.
>> Jon Kuperman: Yeah, so I think, I mean, the big thing, like we mentioned, like the triple A stuff, is that it really precludes certain apps.
[00:06:56] There's certain things that you just can't have, yeah, which is a bit tricky. And then where it gets really murky is if you're not anywhere related to government contract, if you're a startup or a firm or whatever. Where do you go from there? Whereas that's where less legalese, but more of the web aim checklist.
[00:07:15] I find a really great resource for that kind of stuff, where you're not so much concerned with legislation as you are with user experience, right? So you're just kind of reading over them, like okay, these things should have alt text, these things should have labels, that kind of approach instead.
[00:07:29] But yeah, that's really good info. Yeah?
>> Speaker 1: Another question from Ben, in the case of redundant ARIA roles and HTML5 tags, [articlerole=article, which browser screen readers are being targeted with this redundancy? Are there times when you should not use ARIA roles and simply rely on HTML5?
>> Jon Kuperman: Gotcha, so, yeah, [LAUGH] again, a little bit tricky with versions of things.
[00:07:56] So as far as how the element, like an article element, is going to be parsed depends on browser version. So example, older versions of Internet Explorer, those are just gonna fall back to just being dibs. So if you have a product that's supporting older versions of IE or other browsers, then having article with no role would just get turned and flattened out into a div.
[00:08:24] Whereas the HTML roles have been around for a lot longer, so even having div role equals article, it's still gonna fall back in a good way. So I don't know if I talked myself in a circle there. But basically, so the HTML5 element is gonna be good enough, but if you're supporting old browsers, you'll want the role as well, is what I would say.
>> Speaker 1: It's never actually going to be detrimental to double up the ARIA.
>> Jon Kuperman: Right, yeah, that's not gonna be a problem, it's not gonna be-
>> Speaker 1: Is there something like, can I use that list what browsers.
>> Jon Kuperman: Yeah, I mean, so, yeah, I mean, assembly if you wanted, you could go, I think can use a hybrid, but the HTML5 on MDM will have, like if you look up a header tag or something like that.
[00:09:07] And then those all came at the same time, header aside. So you could look at those with your browser support. If you were using something like React or whatever, where you're generating that code, I would always, just to double up on it, in that one time, and then use it everywhere that way.
[00:09:21] But yeah, you can definitely check out the browser support behind the HTML elements to see if you support browsers that don't support those.
>> Speaker 1: What about email? I know it's a little caggis, specific to web, but what about translating some of these guidelines into other digital assets?
>> Jon Kuperman: Yes, that's interesting.
[00:09:42] So a lot of it is gonna be the same, right? Cuz if you're looking at a web mail client or something like that, although you're not really held to the same, the structure isn't really as important there, right? I mean, people are making these entire HTML emails. So I feel my first instinct on it is that the same exact rules apply, right?
[00:10:04] That if you're gonna be sending just a text email, there's not a lot to do. If you're gonna be structuring and sending an HTML email, then the same web accessibility rules will just apply there. Because I think even if you had a non web mail client, it's still gonna have somewhat of a web rendering engine for handling that kind of stuff.
[00:10:22] So, yeah, I think the same rules would apply for making those.