Karl Groves

Tech Accessibility Consultant
  • Web
  • Mobile
  • Software
  • Hardware
  • Policy
Telephone
+1 443.875.7343
Email
karl@tenon.io
Twitter
@karlgroves

On Overlays as a means of resolving website accessibility issues

Recently an article has been making the rounds: Should Accessibility Overlay Tools Be Used as a Strategic Part of your Accessibility Efforts. Some have asked me what my thoughts are on this topic and I feel compelled to share a few comments, because the article discusses a handful of emerging approaches. I’ve already shared my opinions on products like eSSENTIAL Accessibility and UsableNet. But “overlays” are a bit different.

Exactly what “Overlays” are at this point remain somewhat poorly defined. For instance, Debra’s article discusses a handful of products that are different from each other in important fundamental ways. Because I’ve already discussed all of those embedded assistive technologies like eSSENTIAL and ReadSpeaker, I’ll leave those out of the discussion and instead function on JavaScript-based products aimed at dynamically repairing websites’ accessibility issues.

The idea of being able to automagically fix accessibility issues without interfering with existing code is pretty compelling. In a situation where the accessibility issues are egregious and the organization is under considerable outside pressure (i.e. a visit by the DOJ or legal complaint) then something like an overlay can offer a quick fix.

It is important to keep in mind that an overlay is really just applying JavaScript to the current UI to fix the existing accessibility issues. In other words, any skilled JavaScript developer with good accessibility knowledge can do the same thing, without the need to pay for a third-party service. In fact, the Mother Effing Tool Confuser is an example of doing exactly that. Chances are, the overlay is backed by a good library of built-in utility functions but fundamentally what you’re dealing with is still just JavaScript. As a consequence, any inordinately high price for the product is probably unwarranted.

It is important that any overlay needs to be regarded as temporary, for one important reason: if the underlying UI code changes it will break the “fix”. Again, I suspect that the overlays have been developed to do the best they can to anticipate such a thing, but it seems scary to think that the more substantially you change the existing UI, the more likely that the “fix” will break. To my knowledge Simply Accessible does a lot of this type of custom overlay work and they’re at least ethical enough to state clearly to their customers that it is meant to be temporary.

Ultimately you must keep in mind that this fixes the symptom without treating the disease. In many cases this comes down to a business decision. Time spent fixing bugs costs money and also impacts the availability of resources that could otherwise be put onto other work. External pressures, such as deadlines for other projects or legally mandated deadlines may make something like this a good option. But the existing inaccessible interface code that this “fixes” will still be there. Worse still, the development practices and other libraries/ frameworks, etc. that caused the problem will still be there. So no matter what you choose regarding using an overlay, you should also come up with a plan to actually remediate the underlying issues and train your developers in accessibility so that they don’t continue creating the same type of inaccessible code that caused the problem(s) in the first place.

As I’ve said in other posts: The code is where accessibility happens and so long as companies’ budgets are being diverted to ineffective products, these budget dollars are not being used on things that matter.

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

Tenon.io December webinar is now online

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

Full Transcript>

Karl Groves: …We’re live. All right. This is interesting. This is my first “Hangout”. I did a playing around hangout with Billy Gregory who is the other half of the “Viking and the Lumberjack”. Billy and I played around with it and I thought I’d be smart and I would do one of these with hangouts and for Tenon and look what happened. My Google App’s account tricked me.

Let me go over here. I’m going to share my screen.

[pause]

Karl: There is a actual chat tool box in there, comments or something like that. If you guys have any questions or anything like that along the way we’ll do that. I’m assuming everybody can hear me?

All right, cool. This is the “Tenon” home page. Hopefully you are aware of that. If any of you aren’t Tenon users that’s OK, because I’m going to go through the entire process of logging in and all that stuff. Which is, I’m going to log in.

This is a fresh account, completely fresh account, it’s my test account. This is what you see when you first log in and when you first create an account. I come in here at the bottom and no I won’t ask you to upgrade. For a lot of people one of the things that they need to do first is they need to get their API key.

We have a lot of people who use external plug-ins like, Joe Dolson’s “Access Monitor” for instance. Joe Dolson’s Access Monitor requires you to enter your key. One of the things we get a lot of people asking questions about is “where do I get my key?” it’s labelled here on the left and it says API key.

You can go there, you get your key and then you can use that with any of the third party tools that exist out there. The Grunt plug-in, the Gulp plug-in, the Open Scholar plug in, like I said, access monitor, any of those sort of things.

Let me go over the user interfere a little bit really quickly to get everybody familiar with the Tenon user interface. The dashboard is where you go when you first log in. It’s going to contain a high-level overview of your performance across all of your different projects and all the pages you’ve tested. As we see here, this is a brand-new account, there’s no information on it.

“History” would be a running log of all the history of all the tests that you’ve done. That’s good. Then we have projects. “Projects” would be a list of the projects. We are going to go over that. “Profile” is your profile. You can add your name. I’ll write my name here, Joe Schmoe. I can’t type. It gives you all sorts of information about your account. It will give you your progress.

Right here it says you have used zero of your plan 50 calls, because, like I said, it’s a brand new account. “Account notifications” give us a list of the notifications of all the emails that we’ve sent. “Password” is where you change your password. “Address” is your address.

I’m going to go through here for settings and API settings and applications. “Settings “is going to be basic profile settings. This has your date format. You can choose any of these optional date formats for any of your update information you have.

Your time zones, so it localizes to you, to whatever your time zone is. How long you want to time out to be, your session timeout, up to a full 30 days. Your number format. Of course, you can subscribe or unsubscribe to the mailing list here.

I would say that I recommend, if you don’t want mailing list stuff that’s cool, but subscribe to the updates. This is where we give information about system updates, change logs, stuff like that.

Next, I’m going to get to the “API settings” because these are really, really important. If I go to…local host, [indecipherable 4:42] , documentation…There’s some documentation here about the API itself.

Right now the documentation is only for the API. We don’t have a lot of documentation on the website interface which is unfortunate. That’s one of the things we hope to beef up here in the next quarter.

Throughout this, what we’re going to have is, we’re going to have some information on the request parameters. The request parameters are going to be listed here. They are described in long form API documentation style format. I’m going to go through some of these because these are going to be really important for customizing your settings.

One of the things that’s interesting about Tenon, is these two request parameters here, “Certainty” and “Priority”. What’s cool about Tenon is that we try to avoid false positives. They’re are sort of the bane of accessibility testing tools. You can go to the web and list all the way back to 2003 and you hear people talking about these things called false positives.

False positive is anywhere where the product creates a result that’s inaccurate based on context or whatever. We are particularly sensitive to that. We don’t want to create false positives. That doesn’t mean we’re perfect but it means were very sensitive to it and we want to try to avoid it if at all possible.

We create this thing called “Certainty score.” It’s basically a subjective interpretation of how certain we are that something is an actual issue or not. Something that has 100 percent certainty, it means the tool is a 100 percent certain that we have an actual issue.

Let’s say something like a missing ALT attribute is something that we have a 100 percent certainty on. We know for a fact, that there’s 100 percent certainty on something like that.

Other things maybe not so much. For instance, we had — we disabled it — we have a test here that look for implicit headings. The implicit heading would be something that had bolded text. The only sub tag in there would be bolded text.

That only had a 20 percent certainty. As a matter fact, we found in practice it was creating so many false positives that we disabled the test altogether.

Anyway, what’s cool about this is you can set your default settings here to only test for anything that has 100 percent certainty. That way you would know without a doubt everything that Tenon had done would be certain.

This is definitely the kind a setting you would want to use under two important scenarios. The first scenario, would be something where you’re using a continuous integration. In a continuous integration scenario, you would be looking to fail a build for accessibility problems.

You wouldn’t want false positives in there. You want to set it to 100 so you didn’t get any false positives.

Another scenario would be if your team was new to accessibility. The problem with tools like this is that people tend to believe the results on their face without any further scrutiny. That’s great. I mean, if you think about it, why would you want to pay for a tool that didn’t have a high degree of reliability.

The reality that sometimes the tools do create false positives, and we need to avoid those. In that case, if you were in brand-new to accessibility or your team is brand-new set to a 100 until they get their feet wet, until they get an understanding of it.

The next one is “Priority”. Priority is also important. This uses a proprietary algorithm that I developed that takes into consideration a number of factors to help to rank some of the accessibility issues. It ranks them on a protest basis.

What happens is, every time a test-run runs we get all of our results. Then, the priority algorithm ranks each one of those things according to a bunch of things, like ease and speed of repair, impact on the interface, impact on the user and so on.

This is 0, 20, 40, 60,80, 100. You can say that something that had 100 percent certainty would be the kind of thing that had high impact on the user and a very easy repair that had no impact on the interface. All ALT attributes for images will be really hot because it doesn’t impact the interface at all. It does have a high impact on the user. It’s going to have a higher priority.

In practice, you probably don’t want to set this any higher than 80. What we’ve seen historically throughout our data is that you will see a lot of things hovering around that 80 mark, maybe even between 60 and 80. You’ll see a lot of important things hovering around there. You’ll want to set it here. At your maximum would be about 60.

This one, this fragment parameter tells us whether or not what you’re testing is a part of a page, rather than an entire page. This is important because this tells certain tests to run or to not run.

Remember, in this case we’re talking about our profile settings. You’re probably going to want to say no here. If you knew, for instance, that you were only going to be using say, the grunt plugin and you’re going to be testing partials or template files, you may want to select, “Yes”. For the most part, you wouldn’t want to do that.

Importance goes into the prioritization algorithm. You could say everything you are testing has a high importance by selecting three. Generally speaking, you’d want to do this on a per-project basis.

The last couple of ones are probably a lot more easy to understand. Default level is whether you want to test for WCAG A, AA and AAA. I have a blog post on my own website about understanding WCAG level. I heartily recommend that people read this blog post before simply wanting to select AAA only.

The reason why is because the levels here don’t directly correlate to importance. The way that WCAG one was, they had a priority level. It was basically based on user impact. In WCAG two, they changed things around a little bit. You still will find things that I would consider easy to fix and important for accessibility in level AA.

If you’re in an organization that’s concerned only about compliance, then historically, the legal compliance level that is mandated most, accessibility settlements, is level AA. I wouldn’t blame you if you chose that. Leave it at level AA for a bit. You may find some things that you’d like to fix that are AAA.

These last two radio button sets are “Reference info” and “Store results”. In Reference info, do you want reference information to be returned in your results. I would suggest yes. Especially if you are new to accessibility.

Store results. Whether you want the system to store results. That’s a yes or no. By default, it’s going to say yes. The reason why you would want to do that is so you could get access to archive test results.

User agent string is going to be the browser user string that you want to have returned in your results. This doesn’t do anything magical as far as testing is concerned. It would be more of a case of if you had a system that was sniffing for user agency, maybe you’d want to have one to pass through here.

The last two here are going to be view port width and view port height. Tenon is Dom aware. What I mean by Dom aware is it tests in a headless browser and is fully of any changes to Dom with JavaScript and also sizing of things based on the view port.

For instance, let’s say you wanted to test your responsive designs. You could actually pass through your brake points into these settings. You would get results based upon those view port changes being made. The default one is 1024 by 768.

We use that because there are a lot of people with low vision who tend to use resolution about that size. We do some testing based on view port sizes and stuff like that, so we use that setting. You can put whatever you want in there.

“Default delay” is really fun. If you have any JavaScript that takes a while to load. Let’s say you have a bunch of JavaScript that gets loaded from a CDN, or you have ads that display or anything else that modifies the Dom after a couple of seconds.

You could put that delay in there in terms of milliseconds. 2000 seconds would be two seconds. That would be your default delay. I leave that blank because again, this is my profile setting. I’m going to set this. This is set globally for me now.

Every time that I do testing, if I don’t change any of these settings, it will run under these defaults. As a matter of fact, now that I’ve done that I’m going to go here and set that to 60.

That’s my default settings.

What’s cool is if I go into my projects and I want to create a new project, I’ve clicked that project link on the left. I’m going to click here, it says “Add new project.” What’s going to happen is, if I scroll down to project settings, this project has inherited all my settings from before.

Let me go ahead and create a project. This project is going to be called “FORTUNE 500”. I can give it a name. This is called the FORTUNE 500 home pages. I can give it a description, “This is a project to test fortune…” I’m going to go here. That’s not what I wanted. I have this list stored up.

What’s really cool is if you know every single URL of your site, you can dump a list of URLs in there. I have this text area. It says “Add, remove URLs for testing”. I’m just going to paste those in there. You can paste any amount of gibberish in there, and what it will do is strip the URLs, so you don’t have to do one every line or any of that sort of stuff. You can put them in there.

Next is do I want to test these URLs now. Of course, I’m going to say yes. That’s almost always going to be yes, so I’m going to say yes.

Do I want to monitor these URLs? This is really cool. What will happen is, Tenon will periodically check to see if any of those pages I’ve put in here have changed. If they have changed, it will retest them.

Unfortunately, it’s not a terribly intelligent test for changes. In other words, if you do a lot of A B testing or if you have ads that get displayed or something like that, it will retest them. What it’s doing is determining whether the Dom of the page has changed. Of course under A B testing or advertising, that would have changed, so it would trigger the retest.

You can monitor the URLs doing that.

Here’s all of our same identical settings from before. Down here is, “Do you want to set this as your default project?” I’m going to say no here, but I’m going to describe exactly what your default project does after that.

If you notice when I first got here to this projects dashboard, I already a project here, called “Default Project.” As a matter of fact, you always must have one default project because at the request time, if you don’t have a project as part of your request, it will dump it into the default project. That’s exactly what this thing does.

If you see at the very top, this analyzed now thing, will allow me to run a test, and doing that will allow me to analyze a page now and it goes into the default project. I’ve tested this page and gotten my results.

This gives me a good opportunity to go ahead and show you guys what the test results look like. Now keep in mind that the website, the Tenon website that we’ve been looking this entire time is just a client of the API.

As a matter of fact, if I go here and I go to “Postman”. If you don’t know Postman, it’s a really awesome tool. if I go here to Postman and I enter my key which is here, and I enter a URL and I enter, http//:www.google.com, I’m going to do the request here and I’m going to get my results.

This is the JSON format that you are going to get from the API and this page here is just a prettified version of that JSON format. We have only put a limited amount of the data in here. I’m going to go through and show you all the other nifty stuff in the JSON format but let’s face it looking at JSON isn’t exciting.

It gives us our stored test results and then we have a couple of things that we can do. First is, we can just download the CSV. This gives you a CSV that you can use, if you are a Q analyst, you can log into your bug tracking system and attach the CSV, and say, “Here is all the issues from testing this page,” or you can test multiple and get all the information.

We have here our stored test results that’s coming from the JSON request. At the top is how many issues were found, the URL and some other information about the page size and so on. The left graph shows us the number of tests that were run and how many passed and how many failed.

We see here that we’ve had 7 tests failed out of 62 and in this graph here, is a pie chart that shows us, the relative amount of failures from the results that we got. I don’t know how in the heck I did this with this zoom business here. I’m going to go ahead and close that. I hate when I do that. Dashboard, there you go.

Matter of fact, let’s take a look now at my history, go back in the history and I can view my results. Back to the results here. This is the result list in this table here. The result list has two important things on the left, the first one here is of course the code snippet it that we found that had the accessibility problems.

This is the actual HTML from the Dom, and this trips people up sometime because they go, “Hey, that’s not in my page.” They find out the job description or something else has injected it. The next thing that’s important here is the test ID.

This is test ID nine. I want you to keep very close attention to this because if you ever are using Tenon and you find a result that you disagree with and that you think is bogus, you think it’s a false positive, you think it’s not really an error, I want you to do one very important thing for me.

Tell me the test ID, and tell me why you think it wasn’t an issue because again we really care about false positives and stuff. If it is bogus to you, it’s probably bogus to somebody else and we need to hear about it.

The next thing that we are going to see here on the right-hand side under the description column, it’s going to be a lot of the information about the issue itself. First off, whether it’s an error or not and we say error, errors in warnings are going to be shown here. How do we determine that?

We determine that anything with 80 percent certainty and above is going to be an error and anything below 80 percent certainty is going to be a warning. Kind of arbitrary, some people would say 100 percent or not. We think that these need to be called out as errors if they are 80 percent and above. There is only rare chances that they are not actual errors.

The next one is the priority score. Remember I said that each of these priority scores are normalized, they are normalized against all the other issues on the page. This one is probably the highest, it’s got a priority of 95, I doubt we are going to see 100 down here. There it is. There is our 100.

Let me describe why this is 100 because it’s got blank link text. Now there is a title attribute on that but the title attribute is not visible to people who have motor control problems, who use something like dragging, but we also give you the line number and the column number. This is on line 11 and the source. We have the test here for what the issue is.

Let me go to one of this here, if we click on “Recommended fix”, this takes you to a full best practice entry for this. It says, “Provide all attributes for image element.” It gives us a description of the test itself and it gives us the remediation guidance.

This is pretty sparse, add an attribute for image elements that can be fleshed out a little bit. Here is our prioritization information. It tells us we have a user impact that’s high, or paired that’s high impact on the interfaces is done and so on. That’s the raw score. That got normalized at 95 percent.

We also have code samples. The first one is the bad code example. The next one is the good code example, and other information about the standards and guidelines and all that reference information that comes along with this. I hardly recommend perusing the recommended fix.

He recommended fix information some of it is a little bit of a cobbler’s child at the moment, where we need to be fed up. You find one that you say, “That’s not clear, it’s not complete, I want more information.” Shoot me this link here at the top, just shoot with the link forth and I will be sure to take a look, and see what I can do to make it easier to understand.

Let me go back to our projects. Our projects are listed here and if I go here to default project, it will take me to the dashboard for that project. Let me go over a lot of these things here. First off, the top information, the summary information gives us a listing of all the pages that were tested.

I have one distinct page. It’s one distinct URLs that were tested, it gives me the successful versus the unsuccessful. The reason why you want to know unsuccessful is you want to know if you’ve had any problems with some of your tests not working right.

Sometimes we have people try to test up behind a firewall that’s not possible. If they have a high amount of unsuccessful ones, then we might want to give them some help. Gives us average errors per page, average warnings here at the right, average issues, average certainty and average priority.

Down here we have two graphs for the number of issues, per kilobyte and the distribution of density. Let me log into the main Tenon website with my admin account, because it will give you a better understanding of what these things look like.

That’s what these look like, this is going to be a line chart, this when it loads up it’s going to be a bar chart. This is much more realistic, the depiction of information here.

We use issues per kilobyte at source code, because that’s a little bit more of a realistic description of the status of the website. If you had a page that was 10 kilobytes that had 10 issues, you’d have 100 percent density versus if there was 100 kilobytes of source and had 10 issues, it would be much lower. Density is a much better indicator than raw issue town.

We have this Tenon graph here. We have the bar chart, these are the number of pages at zero all the way up to the number of pages that had 100 percent. As a quick glance, the more of the bars that are on the left that are taller, the better that you are doing. If you get these last three here getting really tall, that particular project or that site, performs particularly poorly.

Down here we’ll see, this is the worst performing pages there. This is an important one. This is duplicate issues, now the duplicate issues table is an indication of how many times, we found the exact issue in your pages.

At a meta level, in this situation, we are looking at all of our projects, that’s not terribly useful because we are looking at all our projects and it’s not a good indicator. If you had selected a single project and then you started seeing a bunch of duplicate issues, then you would notice, that there was a lot of patterns that were repeating that we should stop doing.

These are again, like I said, duplicate issues. When I say that I mean the same exact issue using the same exact source code located in the same exact spot. What I usually tell people is, imagine I’m on the CNN site. This CNN search box then this little search affordance that they have. Let’s say there was an accessibility problem with that.

If we scan 10,000 pages on cnn.com, we would see 10,000 instances of that issue. That’s silly. It’s only one place in the code and that’s what we’d be looking at here. We could explore what’s going on there and find out what those are and then we could make a big broad important fix across the site. Those are duplicate issues.

Below that we are going to have issues by test ID and this shows us the specific issues that have the count for each issue as well. These are not the most common issues. These are actually all of our issues and we can sort by this and determine which ones have the highest incidence.

By percentage, the blank link test is the most frequent issue that we have in our site on down to duplicate IDs and so on and so forth. This is a good indicator at a organizational level what practices we need to stop.

Down here, that was the duplicate, sorry. These are the issues by test ID, there we go.

Down here is going to be issues by success criteria. You’ll notice here that some of the roles are grayed out. They are in a disabled state, because we don’t test for this things. This is one of the most important things that people who are new to accessibly testing need to know. Accessibility testing tools cannot find all of your issues.

If you look at some of this and if you are familiar with WCAG, you will see that it’s pretty obvious.

For instance, there is no way that for 1.2.9, there is no way in the world that an accessibility tool will tell you whether you are meeting the requirements for audio only information that’s live.

In other words, what they are looking for is if you have audio only information that’s playing live, do you have a proper alternative, which would be in most cases be some sort of caption or live transcript and so a testing tool is not going to do that.

There is a listing of all the ones that we do test, as well as how often. We found issues with those. How many distinct issues we have and what the percentages are of those? We go through here and we can download a CSV of that information.

This is at a high level of all of our information on the website itself but let’s talk about some of the other things that you can do. For one thing, the API itself as I mentioned before, extremely powerful the website itself is a client of the API.

This is what our API response looks like. If you are not familiar with JSON, that’s OK. You will see here that a lot of this same information, that we saw in the user interface, is here, but we do have a couple of other bits and pieces that can be used and added to this.

“This is great. How can we use this?” You can use it in Joe Dolson’s Access Monitor. If I go to a11ybuzz.com, Joe Dolson has done a really awesome job of creating a plug-in that goes into word press website.

You can hit this button to do accessibility check if we go to a post and we go in here to…Let’s take a look at this. We have a post here that we want to check, Joe’s done a great job here. You go ahead, it’ll check the page itself, it will check the information in your post. It’s going to see here that there two unlabeled form deals and unlabeled image.

I run the check, it’s going to go out, get the results and here you go. It tells us the post may not be posted. This doesn’t meet our minimum requirements, give us the information right there. Let’s say you are a developer, you can go into use this as a Grunt plug-in.

If I go here, this is a Grunt-Tenon demo. Now I’m going to through some of this. If you are not a grunt user, it’s pretty awesome. I’ve vacillated a little bit between going from grunt to Gulp and back to Grunt personally, but this is great because what this does is that we can run a bunch of different checks on our code.

I almost always, I’ll use this task which is JS hint. Let me see if I can zoom in on PHPStorm. JS hint is great, because it does a quick syntax check of your java script files and I love that. It helps me from making bone-headed mistakes that I have to fix later.

JSON lint, it will run a linting, checking of my configuration files so on and so forth. There is other things I can do with Tenon itself. What I’m going to do here is that I’m going to show the Tenon task.

This was done by, I think this was done by Ed Garci and if I mispronounced Ed’s name I apologize. Ed created this Grunt Tenon client, and so this is the Grunt plug-in that uses Tenon itself as a client. It lets you run the checking on your pages as you develop them.

What I can do is I can give a folder full of source files and it will test them. Simple as that. If I have my projects here and here is my source files, I have the regular old website right and my Css and all my other assets carved out here.

I can give it a configuration file, so Tenon RC. If you recall from earlier the API settings that we have talked about before, the Certainty, Priority and all that sort of stuff, we can put all those here, which is cool.

The other thing that Ed did was, he created a filter. In other words, if we have some tests from Tenon’s that we don’t like, you can filter them out by putting their tester id here [indecipherable 36:32] .

The other thing that I can do is you can run your configurations inside of the task itself and so this is the whole Tenon task here. In this case, this is going to test them all under default setting. If I wanted to do responsive testing of my iPhone responsive design, I could put that there and put that here for the tablet.

Check this out. I am going to go to terminal and going to run Grunt Tenon. What’s that is going to do is that is going to the Tenon web servers, it’s going to get the results and it’s going to test all this pages, and give me all the information about them.

When it’s done it’s going to bark at me and tell me how many issues it found. There we go, so the task failed. That’s the problem that we failed our task and we’ve got our issues. One of the things that I have done is that I have commented out the files to save it, but he also has a task here where we can save all the JSON responses into this file here.

The other thing you could do though is there is a number of other plug-ins that are out there that use Tenon. One of those is this one called Tenon reporters from Justin Stockton. One of the things that you could do is that it will return HTML, it will be a fancy little HTML page x unit.

If you are using Jenkins or Hudson for your continuous integration, it will do that and then I think he’s got csv in here as well. What you could do is actually instead of putting it here you could you could pipe that through some out through one of this reporters or something like that.

Another thing that I have added to this…There is another thing that we’ve done, and that is, I can add it as a Grunt watch task so any time my HTML files change, Tenon will test it. Another thing I did is I added as a Githook, so as a Pre-commit cook, it will run inside here as a Githook and kick back if there’s any problems.

Like I said, there is a number of other node modules here. This is the API client that Ed built both his Gulf plug-in and his Grunt plug-in. This is the node module that Justin wrote for his recorders, and this is another Grunt Tenon which is done by guy named Andrew Razorfish.

This is a pro-tractor testing plug-in and it also uses Tenon. Finally Grunt Tenon inline was done by one of our developers. What’s cool about this is what the Tenon inline task will do is that it will inline all your assets. Let’s say you wanted to test your css, well, it would inline the css file into the HTML file, so you get that final rendered Dom test of the page during the testing.

Then Travis. The other thing that I did [indecipherable 40:39] yeah, there we go. Here is the Grunt Tenon demo. What I did is I added this to Travis CI which is a continuous integration tool.

I created my Travis file here. Here is my Travis file and it installs on my node modules and installs on my [indecipherable 41:07] dependencies, then it runs the Grunt task. Here is my output.

We have all of these individuals specific work flows covered. We have the website handles are QA engineers or any of our, may be compliance folks who want to do testing but they don’t want to get their hands dirty with any of the API stuff.

Our QA engineers can use the API and tie that into any of their stuff. They run Grunt task or any of those sort of things. As a matter of fact, I can run this as part of Selenium. I’m running out of time. If this takes too long, I’m going to bag it.

[pause]

Karl: I’m going to bag that, the Selenium example is…I have that on YouTube I think.

[silence]

Karl: We’ve got 10 minutes left. There is one more thing that I want to do and that is to talk a little bit about testing only to pieces of code. You can simply grab a piece of code from one of your sites, one of your pages and test that OK. You just copy that, paste that in there it will automatically determine whether you have code or a page in there. It will test them.

One other thing that we have a challenge with right now is how to test things that require authentication and how to test thing that are behind a firewall or something like that. Right now that’s pretty much it. You going to grab a piece of code and you are going to come in here and you are going to analyze it.

We are working on a couple of things in the…Leading you into a segue, and that leads me to the segment of the road map for Tenon. The road map for Tenon is pretty exciting. We have a couple of things that we are getting ready to release in the relative near future, Christmas break, Christmas vacation for work, affording more time to some of this things.

The first exciting thing that we are going to have is a reports API. All of this information that you see here, you’ll be able to go and grab from a reports API. You pass at your API key, you can optionally pass in your start date and end date and then the type of report that you want.

If the type of report that you want was the information here in the summary, you pass and type summary and you get that JSON. You can integrate that into anything, any other reporting dashboards that you may have. Some sort of business intelligent stuff you can pass in and you can also pass the project name as well.

The next thing that we are working on is a project’s API so right now the only eternally facing API we have is the test API. What you will be able to do is you will be able to create a new project, and you will be able to submit test against that project immediately, as well.

For instance, if you are going do…Let’s go back to our Travis example. If you wanted to create a new project for every single build, you could do that. You can create that new project with the API, then you run your build that does the automatic testing and then that information is returned back to you in your test or you can get back at it from the dashboard.

That’s also going to include a spider. I’m not a huge fan of spiders, I think of them as sort of very broad hammer that you are going to smack something with. At the same time, there are people who work on websites that have massive amount of content being added all the time and so how do you monitor that kind of stuff?

Spiders are your only choice if you have all these content being added from outside of your development environment, say, the content management system.

That’s another big fun thing that Ace and I are working on, she virtually right now. That will be done very shortly. Another thing that’s going to happen to those of you who want to test on your development environment but you can’t expose that development environment to the outside world, we are adding a tunnel.

That’s going to be called “Tenon tunnel” and if you watch on our GitHub repository, you will notice it when it comes up but the tunnel is going to allow you to create a reverse tunnel, an SHH tunnel connection that’s a single connection between you and the Tenon API.

What’s really cool about that is you create the tunnel, you run your tests and when you are done running the test, that connection is killed off immediately. That connection will never be reused, that resource dies immediately and is gone forever.

That’s another important feature. If you’ve ever used anything like ngrok or LocalTunnel.neat, it’s the same kind of thing. The only difference is that it’s authenticated directly from your specific API key.

If you don’t have a key, you can’t even connect to this. So we don’t even have any sort of issues with outsiders connecting to the servers.

That is it. I know that this is a lot of information that was getting dumped all at once. I’m going to cast future webinars in the coming weeks. They are going to be specific to a specific type of task.

For anybody who uses Joe Dolson’s Access Monitor, we’ll be doing a webinar for that. For the grunt and Gulp stuff, we’ll be doing a webinar for that, for Selenium, any of that sort of stuff.

The last thing I’ll leave you with is if anybody is interested in elaborating on one of this things let’s say a plug-in for Adam, some blind text, or something like that, absolutely enthusiastic about supporting things like that.

Our goal with Tenon is to facilitate testing whenever you do your work. we don’t believe in the idea of having to go to an external product to do that. As often and as well integrated into your products that you already in your day to day work and that’s where we want to be.

So that going to be it from me and a number of you submitted questions ahead of time for what you like to see in here. If I haven’t answered those or I’ve just created more questions for you let me know.

What I will do is, I will do a prerecorded answer and post that on YouTube as well. This one as soon as I’m done with it is going to get uploaded to YouTube but I’m not going to publish it until it’s fully captioned.

I will caption that, I anticipate the length of time of that to be about a week, but I will email everybody who attended and let them know about where that is and I want to thank you all for showing up and see you next time.

Effectively including accessibility into web developer training

In October, energized by having just attended Accessibility Camp Toronto I quickly threw together a post titled Your computer school sucks. Looking back at a handful of my previous posts, they reminds me a bit of reading Nietzsche – not in terms of content, but in terms of consisting of a lot of criticism and not a lot of solutions. Today, I’d like to follow “Your computer school sucks” with some actual guidance for web developer training schools and bootcamps.

Do not treat accessibility as its own topic

A few years ago, I wrote a series of blog posts under the theme Selling Accessibility. The content for many of those posts was driven by interviews I did with a number of people in the accessibility field, one of whom was Cher Travis-Ellis from CSU Fresno. Higher Education has some unique challenges when it comes to online accessibility, especially when it comes to the amount of content being created and the large numbers of non-technical people who create that content. During our discussions, Cher shared with me a neat trick she used when training CSU Fresno staff on accessible content creation: add the accessibility training to all the other training. Unless there’s a really specific technique that deals only with accessibility, nobody really needs to know that you’re teaching them how to make something accessible. For instance, if you’re teaching someone how to use MS Word and you talk about using actual headings instead of bolded text, the accessibility aspect of that practice doesn’t really matter. In other words, you’re teaching people how to do a good job, anyway. The same thing goes for web development. Many accessibility best practices are also just quality best practices. Teach people how to do a good job and, when it comes to techniques that are specific to accessibility, that should be in the core curriculum too.

Discuss the role of "markup" in Hypertext markup language

One of the most important things that developers should learn about front-end development is the etymology of the term “HTML” and especially of what “markup” means. The act of “marking up” a document goes back to the early days of the letterpress. Back then, the publisher of the document would annotate a document’s content to give instructions for the press operator regarding how to lay out the document on the press. In other words, the markup gives meaning to the content. In HTML this also has important ramifications for not only the visual presentation of the website but also the meaning of the content when rendered in user-agents.

Discuss the Document Object Model, including Object-Oriented Principles like Abstraction, Inheritance, and Encapsulation

Your students aren’t going to your school to learn just HTML and CSS, but even if they were they need to know that their HTML, CSS, and JS is just a polite request to the browser and that ultimately the browser forms a DOM to represent the response to that request. By giving them a strong understanding of the DOM you will make them better developers overall.

Discuss user input devices

As part of a discussion on the DOM and JavaScript, it is important to discuss how events are fired. Students should know, for instance, that certain objects listen to both ‘click’ and various ‘key*’ events and they should understand that many DOM objects have native events they can respond to. As part of this discussion they should know the role that the user’s input device plays in these events.

Discuss quality

Similarly, it is crucial to impress upon your students the importance of quality. I don’t think that anyone actually wants to do a bad job, but I think developer training needs to focus more on specific approaches to ensuring quality. This includes obvious things like checking your work in different browsers, but hopefully also things like unit testing. Additionally it should include things like keyboard testing and other accessibility-specific tests.

Discuss basic user expectations, including predictability of the interface

One of the biggest frustrations people in the usability field often express is that even in college-level Computer Science programs, students aren’t taught anything about usability even when their assignments include a user interface. For instance, students learning to program a Java application using Swing Components are typically not given any instruction relating to design of the application at all. They’re given basic requirements on what the UI must do in order to make the program work, but that’s it. The same often goes for web developer training. During JavaScript training, students are often taught about creating things that are neat and flashy without actually considering how the user will expect the interface to work. A fair portion of time should be spent specifically talking about user interaction and there should be a general focus on usability throughout the entire training.

Expect More

Finally, we should expect more from our students, especially if they’re learning front-end development. Students should learn, understand, and internalize the notion that they’re ultimately creating something that people will use. In the long run, both the end user and their future employers will benefit.

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

When the treatment is worse than the disease

I’ve previously discussed the pitfalls and false claims of all those per-site accessibility tools that claim to make your site more accessible. To be blunt, I think the vendors of such products are criminals for selling products that are proven to have little to no benefit. Their customers are duped into believing that the product will solve their website’s accessibility problems. These claims are unquestionably false.

The code is where accessibility happens and so long as companies’ budgets are being diverted to ineffective products, these budget dollars are not being used on things that matter, like training developers and remediating their sites.

This is based on the three very clear facts: First, Text-only is not accessible. Second: products that don’t address the site’s specific code failings are useless. Third: Adding new & different accessibility problems is a net-negative to the user.

When is something accessible?

At a very real level, a website is accessible when people with disabilities can use it. That seems a bit vague, but it helps to understand that something is “accessible” when all people, regardless of disability have equal access to the same information, features, and services as everyone else. That seems a bit of an unattainable goal in some cases, and likely not attainable depending on what the actual website is all about. That being said, there’s a distinct difference between being pragmatic and being dismissive of basic human rights.

One thing is for sure, any solution that doesn’t seek to address all users’ needs as completely as possible is very definitely not a useful approach. For instance, a product that “reads” the content aloud can, at best, assist users with cognitive impairments. A product that creates a text-only view of the site is, at best, a solution for people who are blind. In both cases, it betrays a lack of understanding of these users’ methods of using the web. A user who needs the content read out aloud will need that on all sites, not just one. As a consequence they will already have the necessary assistive technologies to facilitate this. A product that creates a text-only representation of the site probably won’t effectively remediate any structural or content-related issues inherent to the text material itself.

In other words: as I’ve said before, any money spent on such products is money that could be spent remediating the underlying issues.

You should definitely avoid making your problem worse


Screenshot of the Virgin America “assistive” version, as created by UsableNet

Today, Adrian Roselli pointed out that Virgin America has made the mistake of allowing UsableNet to create an “assitive version”. This version is, obviously, intended to help Virgin America airlines flight search more usable for people with disabilities.

It is great that Virgin America want to help their customers with disabilities, especially because their website is dreadfully inaccessible. The front end runs on Angular and it is impossible to use with a keyboard. Hunch tells me that a fair amount of their accessibility issues can be fixed by properly including ngAria. Instead, they’ve chosen a solution that not only fails to address their code-level shortcomings but also doesn’t meet the core requirements for accessibility.

The first observation one can make about this “Assistive” version is that it is extremely plain looking. Some might claim that it is OK for it to look plain – after all, its intended users are people who are blind. But that isn’t true:

The footer from the Virgin America “assistive” version, created by Usable Net

This makes it clear that UsableNet markets this as a solution for low-vision users as well, as they provide options for text resizing and color/ contrast enhancements. But if a user needed these features, they’d need them on all websites and, in fact, every application on their computer. In other words, these features are useless.

The plain appearance is a symptom of shortsightedness and a misunderstanding of accessibility and users with disabilities. It is born from the belief that we can somehow organize people into distinct boxes into which they all fit neatly. “Disability rarely travels alone” is a message we try to convey when doing training. It is not at all uncommon for people to have multiple motor or sensory impairments that mean a “solution” focused on only one of those impairments is not useful. Before you discount that as “rare”, keep in mind the total number of people with any disability in the United States is 12.6 million. However, adding up the number of all disabilities is 17.9 million. In other words, there are 5.3 million people in the United States with more than one disability. The total number of people with more than one disability is more than twice as many as those who are blind. (Source DisabilityStatistics.org). 

There are more than twice as many people with cognitive impairments than there are people with visual impairments, and other than greatly simplifying the design, this “Assistive” version does absolutely nothing for such user. In fact, it is arguably worse, because the only mechanism provided to group content together is through headings. The lack of distinct and obvious visual feedback when activating controls on this screen would make this worse for such users.

This takes us to a discussion of why this “assistive” version is, at best, a marginal increase in accessibility for sighted keyboard-only and non-sighted screen reader users. The single reason that this is better than the main Virgin America site is because the Virgin America site is among the worst experiences for these users that I’ve ever seen. It is beautiful, interactive, and incredibly inaccessible. It is the poster child for what not to do when it comes to accessibility. However, under normal conditions, the “assistive” version would probably be a step backwards for these users.

To demonstrate what I mean by it being a step backwards, I created the video below. This video demonstrates using the “assistive” version with the VoiceOver screenreader with Safari. While there are a ton of small nitpicks that I could make, the biggest problem has to do with the user knowing what the heck is going on. Every time a choice is made on the fields on the form, it causes a page refresh. This is actually a violation of WCAG SC 3.2.2. Changing the value of an input should not cause a change of context. While UsableNet is attempting to manage this by putting a named anchor on the link they’re exhibiting a failure to understand how users interact with the site. I’m on a 50Mbps FiOS connection and yet the round trip to redisplay the page is long enough that a non-sighted user is likely to have already tabbed elsewhere. This is because the expected interaction from the user’s perspective is that once they’ve made their choice on a form field, they expect that activating the Tab key will take them to the next control on the form. Instead, tabbing causes “hocus focus” – the focus goes back to the top of the page. UsableNet has assumed that the user knows the page is going to refresh, which is not the case, or that the refresh will be fast enough that their named-anchor trick will work, which is also not the case.

This practice is even worse when you consider the very first set of radio buttons. This is possibly the best evidence that UsableNet’s developers don’t know what they’re doing. The expected keyboard behavior of a radio button set is such that once the set has focus, arrowing through each radio button also selects that radio button. This, in turn, causes the page reset. In other words, once you get focus on one of those radio buttons, you can’t even explore the options without causing the page to refresh!

Finally, you’ll notice that the error handling is terrible. Actually, if you’re a blind user of this application, the error handling will appear non-existent. On one screen, it asks for a promo code. When I attempt to submit the form without entering the promo code, it triggers an error. However, the only notice that there’s an error is that they append the word “Required” next to the field label. Since that text isn’t programmatically associated with the field, the user will have to hunt around the text on the page to find that single-word message. The message itself is merely in bold text and therefore non-blind users will have a hard time noticing it as well!

In short: add-on accessibility is a sham. Whether it is something like AudioEye or even an apparently “custom” solution like UsableNet, they are terrible. They fail to provide anything beyond a marginal benefit for the end user and are, at best, a band-aid over a gaping wound. Virgin America, and companies like it, would be better off spending their money educating their design and development staff on accessibility than wasting their money on snake oil solutions made by amateurs.

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

Your computer school sucks

Sitting at my gate returning home from Accessibility Camp Toronto and remembering some of the great conversations I had. The Friday before camp, Billy Gregory and I did a presentation on accessibility at Hacker You, a company that provides web developer training in Toronto. Billy actually does these sort of lunch and learn sessions at Hacker You pretty frequently, which is awesome. But there’s two problems: Most other computer schools don’t discuss accessibility at all. But even a one-time, optional, lunch and learn isn’t enough. Schools that provide web developer training that don’t cover accessibility as an integral part of all curriculum are doing a disservice to their students and to their students’ eventual employers.

To be clear, it isn’t just computer schools failing their students, but MOOCs, book publishers, tutorial sites, conferences, and bootcamps. About 3 years ago, a Baltimore area group got together to create a several-week long training program for high school students, organized in teams. The students would be focused on learning-while-doing and the end result was that the team with the best end project would win some sort of prize. I reached out to the group and offered to train and mentor each team in accessibility. The response I received was lukewarm, at best, and ultimately got zero traction with the organizers. Apparently giving away expert knowledge and guidance in accessibility still couldn’t get this group to give a shit.

The problem this creates is actually bigger than accessibility. The first lesson that any web developer should learn is that their markup is nothing more than a polite request to the browser. Specifically, they need to know that markup results in the creation of objects. Those objects have methods and properties available to them which form the basis of how the end user interacts with the website they’ve designed. Not understanding how the DOM impacts user interaction is the root cause of most accessibility errors. This should be regarded as core knowledge that all developers must have if they plan on excelling in their craft. That is, unless your school’s goal is to churn out mediocre developers.

This may sound super critical, but developers who have this type of thing – how controls work, why each control exists, what they mean, and how the DOM works – is what will allow them to be better in the long run. This is especially true when it comes to emerging technologies like Web Components. Teaching them to think in this way will provide foundational knowledge no matter what UI frameworks they eventually wind up using.

Finally, the job market they wind up entering is very likely to require accessibility knowledge in the future. If they develop websites or web-based applications in the province of Ontario, Canada, their work will need to meet WCAG Level AA:

Designated public sector organizations and large organizations shall make their internet websites and web content conform with the World Wide Web Consortium Web Content Accessibility Guidelines (WCAG)2.0, initially at Level A and increasing to Level AA.

If they develop websites or web-based applications for state and local government agencies in the US, their work will be required to be accessible under the ADA.

If they develop websites or web-based applications for higher education institutions, it is well-known among those in higher ed that the DOJ is actively inquiring into the level of accessibility by higher education institutions’ e-learning systems and websites and there have been some resultant lawsuits.

If they develop websites or web-based applications for providers of Advanced Communications Services (ACS) such as cable, television, or media companies (including gaming), their work will be required to comply with CVAA.

If they develop websites or web-based applications for the US Federal Government, their work must comply with Section 508 of the Rehabilitation Act.

If they develop websites or web-based applications for private sector organizations, their work may expose their employers to significant legal risk.. The number of legal cases continues to grow and action in this area shows no sign of slowing down among large organizations.

Not including accessibility from the beginning is implicit consent to incurring technical debt. Untrained students have no choice, really, other than to continually increase this technical debt out of sheer ignorance.

Computer training that includes accessibility can boast market differentiation

Given the above, those who provide accessibility as part of their core curriculum can differentiate themselves by boasting that their graduates are better prepared to ensure that their work product will be more compliant and more universally usable.

While Hacker You should be applauded for their regular lunch-and-learns, I think that all computer schools should include accessibility embedded in core curriculum. It will create an alumni population better prepared to create interfaces that are universally usable. Their alumni will be differentiated by their ability to consider the user’s needs. After all, if you’re not developing for the user, who are you developing for?

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

Sue Everyone

I hate this post.

I hate the title of it. I hate what it implies. Even more, I hate how right it is.

This will be the 124th posting on this blog. Although my posts and social media postings are rather strongly worded, I think I’ve also been clear that I don’t like selling accessibility through fear (see Selling Accessibility – Negative Factors). I would rather lead. While others in this field seem fixated on "compliance", I would rather present an unbiased list of facts about accessibility and let those facts speak for themselves.

During his keynote presentation at AAATE 2015, Mike Paciello said this:

It was hard to contain my reaction. Mike Paciello isn’t just my boss, he’s also a very close friend and mentor to me, both personally and professionally. I can’t remember a time when he’s spoken in what I’d call “compliance language” – that is, treating accessibility as little more than a regulatory matter we must address in order to stay out of trouble. For those who don’t know Mike as well as I do, his career is dotted with accomplishments in pushing for a more accessible Web. In fact, he authored some of the earliest academic works on the topic not long after the web was born. And there he is, on stage with a slide projected on a huge screen that says: "Sue Everyone". Holy Shit.

If it was anyone else, I probably would have decided that this wasn’t a talk I wanted to hear and I would have gotten up and left. But it was what he said after that struck me. Mike essentially said (and I’m paraphrasing), “I don’t care what brought you to accessibility, and if it is a lawsuit then so be it.” This resonated with me personally.

My wife and I fought for almost 2 years to get our daughter the special education interventions she deserves. After being deceived, stonewalled, and treated like the enemy by the school system, we decided to get a lawyer involved. It was nothing short of amazing how much the county school system started to care about our daughter. Whereas earlier we had to ask for progress reports, all of a sudden we started getting them weekly. Whereas before we were treated like chumps in IEP meetings, all of a sudden we were respected. Even in the last meeting we had with them, they were trying to fight with us over every little thing. But when I interrupted and said “Holly (our lawyer), I’ve had enough of this shit. Let’s just sue them”. All of a sudden they took things seriously.

So from here on out, I agree. You don’t want to make your ICT products & services accessible? Fine. Don’t. You don’t believe in the rights of persons with disabilities? Fine. Don’t. But when you’re sued and need help, don’t say that people didn’t try to get you to care about accessibility through less antagonistic means.

What happens when you get sued for your inaccessible website

In the United States, the primary motivator for paying attention to accessibility seems to be risk avoidance. While I’d personally rather see people work to make their ICT systems more accessible because they believe in Universal Usability, litigation (or threats thereof) is what truly gets the discussion (and budget) moving for accessibility. Some argue that its the only way to get things done and they’re quick to point out recent accessibility lawsuit settlements and new “collaborations” between companies and disability rights organizations. Throughout my career, I’ve dealt with a large number of companies who are or have been sued. I’ve done work for plaintiffs and defendants and when you hear the back stories of how these lawsuits happened, each one tends to have the same characteristic history for how they got there. To say accessibility lawsuits are preventable is an understatement. By the time a story about an accessibility lawsuit reaches the media, a whole lot of behind-closed-door meetings and phone calls between both parties have failed to come up with a mutually agreeable resolution. This lack of resolution ultimately turns into a lawsuit.

How to deal with threat of a lawsuit

While each story is unique – and I’m not about to disclose details – most of the cases I’m personally aware of involve a series of silly missteps and failures to take the situation seriously. The plaintiff’s lawyers didn’t just pick the defendant’s name out of a hat. The most active lawyers in this type of action do their homework first and have gathered hard evidence that disabled users’ needs have gone unmet and their complaints to the defendant have not gotten results. In other words, your website didn’t get you sued, your inaction did.

But it isn’t just your inaction that got you here. Your organizational culture and lack of quality processes contributed heavily. This is probably the single universal trait among all organizations that have been sued for accessibility, and it can often be traced up to the C-level executives. Ignorance around accessibility is one thing, but your culture is probably more broken than that. Chances are your organization’s approach to quality, usability, and project/ program management are broken as well. You can probably even verify this by having conversations with your Human Resources personnel, as you’ve likely lost employees due to their frustration at the company’s lack of process.

Ultimately, you are going to end up fixing your website

It is never too early to begin addressing accessibility. Being proactive is far better than being reactive and that’s never more true than when you’re dealing with a legal threat. When it comes time to address these matters in the written settlement, the terms will call for WCAG 2.0 Level AA as the standard of measure for success. Get started on that now, not when the settlement is signed because the settlement will also dictate a date for you to reach that goal.

To paraphrase my former co-worker Elle Waters: "Do you want to do this on your budget and timeline or the plaintiff’s budget and timeline?" This is extremely important. If you wait too long to address this it will be expensive, painful, and extremely disruptive to all other work. Do it now.

You will never be successful in accessibility without fixing your culture and processes

Getting to the settlement is one thing but then you have to meet its requirements. If it is your culture that got you here it’ll be the culture that keeps you from being successful. Chances are, you’ll be told to get an accessibility audit and to fix the things found during the audit. Your settlement will probably also call for requirements that you get your staff trained in accessibility. That’s only the beginning. Broken processes have lead to very serious roadblocks to meeting settlement requirements. In fact, a well-crafted search on Google will turn up one organization that has been sued 9 times for accessibility. Poor program management, poor leadership, and poor processes will mean that accessibility suffers alongside other quality domains.

Chances are there’s nothing in this blog post you haven’t already heard before

At almost every client I’ve had, there’s been at least one person inside the company – either through passion or because it was their job role – advocating for accessibility. That internal person has been saying the same things I’ve said above and elsewhere on this blog for years and haven’t gotten any traction. Suddenly you get sued and I show up to do training and I’m saying what they’ve been saying all this time.

Start paying attention to this person because if not, they’ll eventually get angry about being ignored and quit to work for an accessibility consulting firm. In fact, that’s where a lot of accessibility consultants come from.

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

On Certification

At CSUN 2012, the ATIA, Microsoft, and other companies laid forth a proposal plan to create a professional organization around the Accessibility profession. Among the topics of discussion on that day was certification. The next day I posed the question on this blog What does it take to call yourself an accessibility expert?. Cyndi Rowland of WebAIM posted an overview of concerns about a month later in an excellent post titled Accessibility Certification: The Devil is in the Details. In her post, Cyndi also references other blog postings by Sharron Rush and Léonie Watson. Since that time, the IAAP has plodded onward with its plans, including their plans to create a certification.

Do we need a certification?

Large companies and government agencies have a legal obligation to ensure ICT systems are accessible to employees, customers, and citizens. Meeting this obligation requires that the organization employ IT staff with extensive skills and knowledge in accessibility, but the requisite level of knowledge is rare. Validating experience level of employees/ potential employees is difficult when executives and HR personnel also don’t know much about accessibility. But is the answer to this question “an exam”?

On September 8, 2015, Glenda Sims of Deque will be presenting a talk during the Accessibility Summit titled “Accessibility Professional Certification”. In the description of her talk is this: “Is there a way to establish an exam that could reliably weed out impostors from experts?”. Is this the goal of a certification? To “weed out imposters”? This sounds a bit like Leave Accessibility to the Experts Please. Certainly there are a lot of cases where unqualified people are working in Accessibility. But am I crazy to be offended by the idea that they’d be called “imposters” who need to be “weeded out”? Or, perhaps that’s exactly what needs to happen.

We’re reaching a point in technology where it is evolving at a breakneck speed and that requires an accessibility professional to not only understand the special use cases of technology for people with disabilities but also requires them to understand the technologies themselves. Many people who had traditionally been able to work in this field are now faced with out-of-date knowledge, to say the least. You can no longer “fake it until you make it” without doing a severe disservice to your employers, customers, and end users. Instead of “weeding out” those who lack the advanced knowledge necessary in today’s tech industry, I vote that we seek to mentor and educate others. I think pushing a certification is a backwards approach at solving a much bigger problem than so-called “imposters”.

What is the worth of certification?

In order to have any worth, a certification must meet 4 criteria: Validity, Reliability, Fairness, and Defensibility.

  • Validity: Does the test measure what it is intended to measure?
  • Reliability: Will different test sessions against the same test-taker yield the same results?
  • Fairness: Is the test free from bias?
  • Defensibility: Have professionally recommended guidelines been used to create the exam?

The above topics are far more in-depth than is necessary here, but they are important to consider when determining if a certification is worth having. Frankly speaking, I don’t see anyone (other than possibly Paul Bohman) on IAAP’s Certification Committee who may have any experience in this area. There are additional names listed on the IPD Committee that provide hope, and I may just be ignorant of the existing skillsets behind these efforts. Regardless, there’s nothing on the IAAP’s site which indicates any effort at pursuing or documenting their approaches to address Validity, Reliability, Fairness, and Defensibility. During her presentation, Glenda will discuss IAAP’s future inclusion of Dr. Reed Castle, a specialist in Psychometrics, to assist the IAAP. It is unknown the extent to which Dr. Castle will be involved, but I hope the IAAP closely heeds his guidance because that will help considerably.

The IAAP Certification page states:

The IAAP proposes to align its requirements for CEUs with the standards created by the International Association for Continuing Education and Training.

“Aligning its requirements”, however, is not at all the same as becoming accredited as a CEU provider under IACET. Furthermore, there’s no discussion of becoming accredited as a certifying organization under an independent body such as ANSI.

As an “Accessibility Professional” myself, I would find holding a certification useful if it increased my ability to gain employment by virtue of having it. In other words, the certification has to be valuable to the potential employer. The potential employer must feel that the certification exam validly and reliably measures skills and competency in accessibility. The potential employer must believe that the exam itself was rigorous enough to truly prove that the certificate holder really knows what they’re doing. In other words, absent any other obvious differentiation between two applicants, the applicant with the certification should have an advantage over the non-certified applicant. Due to the current lack of publicly available information on the IAAP certifications, its hard to say whether this will be the case.

What about those “imposters”?

While I disagree with the language, I don’t disagree with the sentiment that accessibility has a pretty huge ignorance problem. There are people working in accessibility-related job roles who are seriously under-qualified for their jobs. There are so-called “thought leaders” in web accessibility who have never professionally designed or developed a website. But this isn’t unique to accessibility. It happens in virtually all professions that don’t require professional licensing.

The mission of the International Association of Accessibility Professionals (IAAP) is to define, promote and improve the accessibility profession globally through networking, education and certification in order to enable the creation of accessible products, content and services.

What the accessibility community needs isn’t a certification, but rather education, and IAAP’s messaging going all the way back to 2012 suggests to me that they’ve gotten this backwards. While some people may believe we should “weed out” those “imposters”, I’d rather see those “imposters” become educated. If there’s any value at all to IAAP’s efforts at creating a certification, it is that it should lead to the development of a body of knowledge that can help bridge the knowledge gaps that exist. The more rigorous the certification process, the more such a body of knowledge will be necessary.

At every accessibility consulting firm I’ve worked at, the ability to recruit quality staff was extremely difficult. I can guarantee that every accessibility firm in North America is hiring right now. The workload, when measured against available consultant time, is massive for all of these companies. The lack of available talent will not be addressed by a certification but must be addressed through mentorship and education opportunities similar to those seen among other professional organizations like PMI, SHRM, UXPA, or IAPP. While all of these organizations also offer certifications, they also offer a wide array of educational and mentorship opportunities. In other words, they seek to grow their profession, not “weed” people “out” of the profession.

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343

Five Lessons Learned from the IEP Process

May was a really big month for the Groves family. We got our county school system to agree to place our daughter in a non-public school to address her unique educational needs. She’s never been happier and more enthusiastic about school, which I largely attribute to a combination of better atmosphere and finally feeling like she can be successful in her education.

Throughout what has been a 2 year process, I’ve felt compelled to write about what was happening, but also felt it was too early to talk about. I also didn’t want emotions to drive too much of what I want to say. But this topic, and our experience, is also too important not to share. Over time, my wife and I have joined groups on Facebook, Reddit, and elsewhere specifically oriented toward learning disabilities. Among the most popular topics in these groups is the IEP process. For those who don’t know, IEP is Individualized Education Program which is defined as:

In the United States an Individualized Education Program (IEP) is mandated by the Individuals with Disabilities Education Act (IDEA). Wikipedia

Countless posts appear in these forums discuss the frustrations and despair that parents have with the IEP process. Over and over parents in theses groups complain that their child’s needs aren’t being met by the schools. I don’t know whether that is consistently the case for all of those complaints, but what I can say is that our experiences have been vastly similar to all of the primary themes you see throughout those other parents’ complaints. I want to share mistakes and lessons we’ve learned along the way.

There’s no “we” in IEP.

The first mistake we made was believing the school staff were on our child’s side. This was not the case and we were incredibly naive for believing so. The school Principal and/ or Assistant Principal are employed to administer the business of the school and manage the school’s personnel. That’s why they’re referred to as Administrators. They may have a background in education but their responsibility is to achieve the mission of the school, not your child. They will tell you that it is their duty to look after the well-being of all of the kids in their school – and that’s fine – but that is not the same as looking after the specific needs of your child. In short, they’re not on your side, they’re on the school’s side. Know this and remember this at all times. Don’t be fooled by their claims to the contrary. The only people truly on your side are you.

The special educators are, at least in my opinion, much more likely to care about your child’s specific needs. People typically don’t choose to specialize in special education if they don’t feel empathy for children with special needs. The problem is that they’re responsible for every child with special needs in their school. In a school with possibly hundreds of children, there may be only a couple of special education staff on hand and they have to handle all of the children in the school who have special needs. As is often the case in the realm of accessibility, this specialized staff is often spread thin. And, as before, while they may be more likely to care about your specific needs than anyone else, they also have their own individual goals to achieve with respect to all of the children they’re responsible for. They’re also unlikely to buck the system to advocate for your child.

Understand your rights and responsibilities

All children in the United States are entitled to a “Free and Appropriate Public Education” – whatever the heck that means. The subjectivity in that phrase is probably the source of a lot of confusion and frustration surrounding the IEP process. For the most part it means that your child is entitled a free education by the public school system and that the quality of the education must meet the quality that all other children receive. For children with special needs, this latter point can be pretty hard to define, but that’s what the “Individualized” part of “Individualized Education Plan” aims to address. Children with special needs must be given the necessary adjustments to their education necessary to allow them to learn.

Given the above, you have the right to expect any & all accommodations necessary for your child to learn. You have a right to expect that the school will define measurable goals to track your child’s success. You have the right to revisit the substance of the IEP as necessary to adjust goals or adjust the plan to ensure the goals are being met. You don’t have a right to expect anything extraordinary for your child.

As the parent, you are ultimately the one responsible for making sure that the school is doing what is necessary to ensure the success of your child’s IEP. Never assume that they are doing everything they should be doing or even what they said they’d do. You can – and should – ask for regular progress reports including objective measures toward your child’s goals. Missing IEP goals is an excellent reason to demand an adjustment to instructional times or approaches.

This isn’t what you do, so find someone who does this stuff

While I might know a lot about web accessibility, I don’t know anywhere near as much as I needed to know when it comes to special education. As a consequence of my ignorance I was far too willing to trust that the school knew what was best for our daughter. When it became clear that our daughter wasn’t successfully learning under her IEP, our ignorance became our #1 enemy. We had no idea how the process was supposed to work and no knowledge of what sorts of accommodations were appropriate or possible for our child.  Considering the volume of information out there on the web, we expected to be able to learn about this rather easy but it just wasn’t the case especially when it came to our county’s specific processes. Our school and our county wasn’t terribly forthcoming with this information and when it came to accommodations they claimed they were doing all they could. The best thing we did was hire an advocate. In our case our advocate was also a lawyer with a lot of experience and success working with our county.  She knew far more about special education, our county’s processes, and the law.  Unfortunately, affording a lawyer is out of reach for a lot of people. Don’t feel dissuaded by this, because there are often local advocacy groups, foundations, or disability rights organizations that can provide assistance and some attorneys may take on pro-bono work.

Get support for you

My wife is incredibly strong, organized, and assertive and together we make a great team. In addition to each other, we also have people we can turn to for emotional support. My boss, Mike Paciello and my coworkers at The Paciello Group have been extremely supportive. This stuff is very emotionally draining. If you don’t have your own support network, you need to find one. You are not alone in this and there are a lot of other people, possibly in your own network of friends or neighbors, who have gone through this as well. Reach out for support when thins get too stressful.

Never give up

If your child needs an IEP, chances are they’ll need one throughout their education. You owe it to your child to never give up in your efforts to ensure they get a proper education. The benefits of becoming educated speak for themselves and it is crucial that children who learn differently are able to do so.  Do whatever you can to make that happen and know that you must keep fighting no matter the setbacks you may face along the way.

My testimony at the CSUN 2015 Access Board Hearing: Make Haste

My name is Karl Groves. I’ve been involved in Web Development, Usability, and Accessibility since the late 1990s. Living in the Washington DC area, and working in accessibility my professional career in this field has always involved Section 508.

In 2006 I was excited to hear about the Refresh process. As a web developer, the advent of technologies like Asynchronous JavaScript blurred the lines between software and web and the rapid changes in mobile computing meant that the technologies that drove the old standards were quickly made obsolete. The Refresh was exciting to me because the standards could be made more relevant.

The TEITAC committee’s membership included representatives from industry, disability groups, standard-setting bodies in the U.S. and abroad, and government agencies, among others. Members were selected from applications received in response to a Board notice published in April of 2006. In the spirit of international cooperation, the Access Board also included representatives from the European Commission, Japan, Canada, and Australia.

In 2008 I was also excited to hear that the TEITAC committee had delivered their report.

[long pause]

2008.

[long pause]

2008

The same year this nation saw its first Black President. Since that time, we’ve seen the overthrow and creation of governments in the middle east. The US Economy dove into and crawled out of a massive economic crisis.

Congress approved and implemented the Affordable Care Act – including all of the years of partisan fighting and surviving a challenge at the US Supreme Court and to date 7.3 million people had enrolled through the marketplace and paid their premiums.

Osama Bin Laden was successfully brought to justice for 9-11

Barack Obama was re-elected for his 2nd term.

And the Section 508 Refresh has still not made it to Final Rule.

Why is it that we can see the creation and implementation of the most sweeping change to our nation’s healthcare system in roughly 20% of the time it has taken to get to this hearing?

NOT having a new Final Rule has resulted in chaos within the compliance space at the Federal, State, and Local levels as well as higher education institutions. While only the Federal Executive Branch is required to adhere to Section 508, these others have often adopted Section 508 and use it to guide their own ICT procurements. It has resulted in chaos for contractors who are told by their public sector clients that they have to conform to grossly out of date standards while their private sector clients want conformance to WCAG.

I’m pleased to provide my voice to this process and want to encourage you to the best of my abilities to make haste. There will be plenty of people today who will say that the new standards aren’t enough. Incorporating WCAG by reference means, to many, that it doesn’t go far enough for persons with low vision or cognitive disorders. As the father of a child with severe learning disabilities, this resonates with me. But we must remain aware that the “perfect” is the enemy of the good. We must commit ourselves to the pragmatic understanding that what the Refresh proposes now is far far better than what currently exists in Subpart B and Subpart C of the Section 508 we now have. The lack of a final rule is, in my opinion, a failure on the Access Board’s part to achieve its mission to protect citizens with disabilities.

You must not delay this process any longer. You must make haste. Finish what so many people have worked so hard on. Make haste toward an actual Final Rule.

Thank you.

I’m available for accessibility consulting, audits, VPATs, training, and accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343