Could browsers fix more accessibility problems automatically?

Now, interpretation is hard, that’s one thing to note, as Wilco Fiers and Glenda Sims have done in their blog post, “Accessibility Wars: The Accessibility Interpretation Problem.” This blog post is all about, if you ask a number of different accessibility specialists to look at your website, they may give you completely different results or somewhat different results because sometimes they might interpret some of the WCAG criteria differently.

Interpretation is difficult, and this is nobody’s fault.

If we would have a standard with very easy to interpret guidelines, we would need a lot of them.

We would need a lot more success criteria to make that work.

So it is a balancing act between how easy is it to test?

How objective are these criteria? Versus, how many of them do we need?

And lots of other factors as people well versed in WCAG might well know.

Now this may remind you of accessibility overlays, and I should highlight that, you know, accessibility overlays have issues.

They include that some of the vendors of these overlays, they make false claims, so an overlay is a product that website owners can buy and install on their website.

Sometimes it’s advertised as you can only, you only need to put in one line of JavaScript and automatically your website will now be accessible.

Claims like that are very tricky because as we said before, we can only detect a very small subset of issues and anyone who claims that they can detect all accessibility issues is lying.

Something else that is a problem with overlays is that they don’t always work well. And sometimes they might make things worse as well, for people with disabilities.

So that is a thing to look out for.

I don’t think it’s a problem necessarily with automatically fixing issues per se. I think it’s a problem with how the specific overlay products have implemented and if it shows one thing, it is that this isn’t an easy thing to do because you do need to get it completely right for it to really, really make sense.

Something else to say about overlays is that they only fix the websites that they’re installed on. So some of these overlay vendorsmay sell their product and charge per website, so the website owner will need to pay and not all websites will have these overlays.

So if you would install an accessibility overlay, you’re not really contributing to the larger problem of, you know, websites on the web at large, not just the ones that you want to fix, but all of the websites on the web. I think that scope is more interesting and that’s the scope we’re looking at today.

Another thing to say about overlays is that they often don’t work well with the DOM updates, which are done of course, by a single page applications.

They will replace parts of your web page sometimes based on what is happening in JavaScript, so just states that is kept in JavaScript will influence which part of the DOM are replaced, and these overlays might not always realize that part of the DOM has been replaced. So sometimes that just doesn’t work very well.

So these are caveats and you can find these and more on a website called overlayfactsheets.com and on this website, a number of accessibility practitioners, including myself, have signed this manifesto where we say, you know, accessibility overlays have issues and, you know, please don’t use them.

So the way that I’ve structured this talk, is that I’ll be introducing a number of different features that I imagine browsers could have. Now I’m imagining all of these as checkboxes, just for the sake of argument, but I imagine any browser engineer or user experience people at the browser might find better ways to add that dysfunctionality. I’m just saying they’re checkboxes so that we have something to talk about it today, but, you know, I imagine these to be implemented in whatever way works best in the particular browser. So let’s look at the first and the first number that I have are actually features that already exist in browsers. And later I’ll be talking about some features that don’t exist yet, but I feel they could. Now the first one I want to talk about is, what if browsers let us force readability?

Now this is actually something that also exists, not as a checkbox, but it’s something that some browsers have started doing by default. For instance, Apple announced in 201 that they ignore, they started ignoring the user-scalable min-scale and max-scale settings and they recommend developers to test with that, because, you know, they want to make sure that users are able to zoom and they kind of prioritize the user here above kind of what the developer wants. Now, sometimes this can be tricky for developers. I once worked on a product where we had avatars for users, they would upload their photo and then they wouldn’t be able to crop the content. Now, this is really hard to build for touchscreens, if you’re not able to suppress zoom because pinching to do your cropping will then conflict with zooming in the webpage.

So that was kind of an example of where it would be useful to suppress zoom, but I feel like it’s been abused so much that it only makes sense that browsers have decided, you know what, we’re going to disallow this for everyone, always, There are still a couple of browsers that will listen to this meta tag, so, I feel like it would be good if they would also follow what Apple has done here.

This is actually something that the people behind the Polypane browser have built in the form of a plugin. They call this the Fix Contrast plugin, and you can download it for various browsers. And what it will do is when it’s turned on, it’s going to look for contrast issues and automatically fix them, so if you have a bit of light gray text on a webpage, it is going to bump that up to kind of black text if it’s on a white background, just to make sure that the contrast is sufficient and in the settings, you can say how much contrast you want. So whether you want it to meet WCAG double A, or maybe triple A, or even some custom value, if you want a lot of contrast. Now, if you browse the web with this thing turned on, you will see a lot of websites that are not as the web designer intended it or as the content the editor has intended it, but you do see these web pages in a way that works for you.

So these are, I think, this is functionality that is very useful for end users and it gives them more control over how they view websites. Now, this is also something that Microsoft Edge will do when you have Windows high contrast mode turned on, there’s a blog post by Melanie Richards and Alison Maher called “Styling for Windows high contrast with new standards for forced colors.” And in this blog post, they explain a number of things about how high contrast and forced colors works. But they also explained that in some instances, the browser will draw backplates behind text a bit like I mentioned before, where if you have a bit of white text on a white background, you would draw a black bar underneath and you know, this can have lots of different variations, but the gist of it is that you adjust the contrast by adding a background color to text that would otherwise have insufficient contrast.

So on this slide, you see a screenshot of a bit of text with some links in it and I’m currently focused on the link approaches, but you cannot see it because the website owner has decided to undo the focus style, so you don’t know where I am. Now, if I would turn on this new checkbox called force focus indication, the browser would just highlight it for me in a very clear manner, so it would maybe use a 10 pixel black border to just say, you know, this link is the current one, this is the one you’re currently on. Now, this is very utilitarian, like you just want to know where you are on the page and you don’t care if it’s pretty or not. So maybe the original website designer would shrug when they see this. and not like what this looks like. But as a user, you now know where you are and that’s kind of your goal when you’re on this website, because you want to find out which link here are clicking on and maybe you want to, you know, book a trip or whatever, get on with the task that you’re on this website for.

So here I have a screenshot of an article in The Guardian and here is a list of navigations, main, subjects and support, and basically what this would do is it would allow you to jump to any of these navigations. There’s a list of sections main article, most viewed, most popular and again, you would be able to jump to the sections directly. This is something that screen reader users can do if they use that landmark menu. And I think it would be nice if all users would be able to do this and maybe it would even encourage developers to name their landmarks well, and to choose their landmarks well. Now this one is a little bit risky because even on, on this particular webpage, I’ve had to make up the names for these landmarks because they didn’t exist on this prominent newspaper website. So a problem with this functionality may be that there are not a lot of websites that actually have useful landmarks. Maybe this functionality could help developers understand how they need to do that, but, you know, it might not make the functionality very useful. So that’s a little bit of a chicken and egg problem and a problem that’s also currently experienced by people who use screen readers. And it would be something that then more people would experience, but it wouldn’t necessarily be good. So, you know, I’m a bit torn between whether this is a good idea or not.

So when you have an input that is labeled, but the label is not programmatically associated with the input, so maybe you have a development just in front of an input that happens to describe what the input is for, the browser starts to guess that, that might be the accessible name for that input. Now this is a little bit risky because what if that content is not related, but if you compare it to maybe the default, which is completely unnamed input, which has zero context, it might be useful to add that that empty div or that the div will know no relationship and try and make that the accessible name, because in many cases it will actually be more useful than nothing. So this is something that Safari does for inputs. Maybe more browsers could do more of this sometimes.

Now some of us have been looking at this problem as well in a W3C community grope, community group, sorry. That is called ally feat or accessibility features. And the goal of this group is to find features that can fix accessibility features in any web content. And we’re distinguishing between a number of different features, like some stuff that might always be on, some things that might be toggles. And the goal of this group is to kind of collect these features, make a list of them, figure out if they are in browsers or maybe not, prototype sometimes and try and encourage browsers to implement some of these features. So this community group, I started together with Eric Eggert and Wilco Fiers, it is currently paused because many of us are too busy to run it. And it would be something that we would be interesting to pursue more in the future. And if this sounds like your thing, definitely get in touch and maybe we can restart some of this group’s work.