Karl Groves

Tech Accessibility Consultant
  • Web
  • Mobile
  • Software
  • Hardware
  • Policy
+1 443.875.7343

The Accessibility & SEO Myth

No, Accessibility doesn’t lead to better SEO. More importantly, this isn’t a good business case argument. It is time to put this one to rest.

In order to formulate a good business case argument, you must be able to prove that Taking action 'X' will have 'Y' consequences and in this case the argument is that improving accessibility will improve SEO. The implication that follows is that this will somehow make the organization more money or otherwise help the organization reach its defined goals, where more visitors equals higher possible achievement of those goals. This is only true if you weigh a handful of accessible development techniques with inordinately high levels of importance.

The Web Content Accessibility Guidelines Contains:

  • 4 Principles
    • Split to 12 Guidelines, which are then
      • Split into 61 Success Criterion

The informative supplemental material for WCAG defines approximately 400 Techniques and Failures. At the time of this writing there are 93 Common Failures for WCAG. I’m of the opinion that saying “Accessibility Improves SEO” is greatly over-selling accessibility.

A Google search for "Search engine ranking factors" displays a number of results featuring leaders in the SEO/ SEM industry that outline the many factors that improve SEO. The vast majority of the identified ranking factors have no relationship of any kind with Accessibility. In fact, even many of the “on-page factors” don’t have much relationship with Accessibility.

Accessibility and SEO intersect in the following places:

  1. Page titles
  2. Headings
  3. Alt attributes
  4. Link text

In the entire list of 400 WCAG Techniques and failures, 21 of them relate to the above list of items. In other words, only 5% of WCAG techniques are correlated with SEO. None of this means that those 21 techniques aren’t important, they definitely are. Titles, headings, and link text are important navigation and wayfinding aids for users. But that’s not the same as claiming better accessibility results in better SEO.

“Better SEO” is not an accessibility business case and this myth needs to go away.

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

The incredible ugliness of political bias and our abandonment of logic & reason

Wise people (namely, Jennifer Groves) often say that you shouldn’t discuss politics or religion in a professional environment. Since most of the stuff I post about on this blog is work-related, I suppose this post is a little unwise. Those who know me on Facebook know that I post a fair amount of political stuff there and would rightly assume I’m pretty progressive, so I’ll try to leave my own biases out of this post.

A few weeks ago Maryland Senate President Mike Miller sent out a survey via email. I’m not sure how I got on his mailing list, especially since he does not represent my district. Still, I think it was awesome. The survey asked for respondents to weigh in on a number of things that will be coming up in this years’ legislative session. I have no idea what will be done with the survey information but I think it is a great idea for legislators to be reaching out to their constituents in this way. Why don’t more people do this?

I decided I wanted to share the link on Facebook. In the 2012 presidential election cycle, there were a few places that political discussions relating to Maryland politics took place but I could not find those same ones anymore and the ones I could find were ghost towns. I found one, however, aptly called “Maryland Politics”. Topics there appeared to be balanced in nature, though one very active participant tended to editorialize quite a bit when posting news items. Still, it didn’t seem too bad, at first. Since the general atmosphere tended to lean more toward my own political tastes, I stuck around. After sticking around it became more and more obvious that this group functioned more and more as the group creator’s own biased sounding board than a venue for actual discussion.

Naive, I know. Politics in this country is ugly and populated by candidates who run around chasing opinion poll after opinion poll, bloviating about whatever is the hot topic of the day that day and issuing reductionist statements that can fit into soundbites of appropriate size and simplicity so that they can be regurgitated by talking heads on the news channels frequented by their target demographic. This idea was parodied with laser-sharp accuracy in a Family Guy episode titled It takes a village idiot, and I married one:

Though clearly more intelligent than her opponent, Lois’ campaign falters as Mayor West proves more politically savvy than she is while Lois bores voters with detailed plans to improve the city, Mayor West garners support simply by avoiding answering questions and acting in a patronizing manner. Brian, observing that “undecided voters are the biggest idiots in the country,” advises Lois to dumb down her campaign. She soon discovers that she can generate support merely by dropping controversial terms such as “Jesus” and “terrorists” in meaningless ways, and by answering questions about her policy plans only by saying “9/11.” She wins the election, and continues to use fear tactics to raise funds for cleaning up the lake.

It seems like a chicken & egg scenario. Are the voters idiots? Are politicians just playing to our baser instincts? As I grow older I feel like we’re careening toward a world where Idiocracy is more like a documented prediction than a comedy movie. I think we should expect more out of our politicians, our peers, and ourselves.

Everyone has their biases, whether they admit to them or not. I have my own. But believing in and spreading baseless, deceptive, or wholly untrue allegations is unethical, in my opinion. Each voter deserves the right to understand and assess each candidate and each political issue based on actual facts, logic, and data: Voting records, position statements, recorded statements in the media and on the debate floor. Refusing to consider, discuss, share, or even acknowledge factual information is deception. Ultimately each person needs to determine which candidate fits our own preferences for what makes that candidate the right choice. Thankfully we live in a time when researching this information has never been easier. The for-profit news media is not a reliable source of such information. While my fellow liberals are quick to dismiss Fox News as biased, the other media outlets are just as biased. Even CNN and MSNBC have been accused of conducting a media blackout of Bernie Sanders.

You can and should avail yourself of resources that are better than the news media

(Mostly) Unbiased resources exist, mostly in the form of non-profit organizations who identify themselves as “watchdogs” or “think tanks”. Some of these can still be biased, depending upon who founded them and who funds them. Here are a few things to look out for:

  • If they’re focused on one political cause then obviously their positions and coverage will have a myopic focus on that cause. They will support those who support them and vilify those who do not.
  • If they’re founded by a single person or group of people who lean toward a single political ideology, so will the organization as a whole. Is the board full of ex-staffers from the Clinton administration? That organization will lean to the left. The converse would be true if they’re all from the former Bush administration.
  • If their position papers and blog posts would fit in well with a clearly-biased mainstream media source like Fox or Daily Kos, then they’re biased.

Resources I’d Recommend

Of the above, the Sunlight Foundation is particularly important based on the tools they provide for accessing important data.

Obviously making use of some of these resources involves a little more time and energy than flipping on your favorite news channel. You owe it to yourself to take the time to at least peruse a few of the fact-checking websites to verify whether what you’ve heard in the media is true or not. Come election day, vote based on facts, not rhetoric.

What to do when you get sued… (revisited)

Rather than re-write my post What happens when you get sued for your inaccessible website, I wanted to revisit the topic entirely. A few years ago, I wrote a series of blog posts about the “Accessibility Business Case” Ultimately, I determined that reduction of legal risk was the most powerful business case argument. Recent events are proving me right.

None of this is legal advice. I’m not a lawyer. This is advice based on over a decade of accessibility consulting experience.

Over the last few months, a few dozen companies have been sued for violating the ADA by the same law firm, representing the same plaintiffs. “45 Lawsuits. Hundreds of Demand Letters.”, says an article describing the activity. Regardless of your opinion on whether this type of activity is right or wrong, the fact is that it is happening. The rate of legal action in the United States has increased significantly in the last few years, with some (including myself) who feel that if legal action is the only way to make the web more accessible, so be it.

You’re getting sued/ threatened. Now what?

I’ve worked for both plaintiffs and defendants in many legal cases and have seen some interesting patterns along the way. If you find yourself on the wrong end of a complaint letter, there are a number of things you can do to avoid a long, costly, and potentially embarrassing fight.

Lawyer up, of course

Chances are you if you’re one of those with the most risk, you already have legal staff on hand. If not, it goes without saying that you’ll want to find one. If your lawyer doesn’t have any experience in this area, it may be worthwhile to find one that does.

Do not dig your heels in

If your lawyer says that you should tell the plaintiff to buzz off, find a new lawyer. This doesn’t mean you should roll over and give in to the plaintiff’s demands, but in most cases becoming non-cooperative is the quickest way to wind up in a courtroom. In this recent round of lawsuits, if you peruse the court records in PACER, you’ll find this pattern (simplified below):

  1. Plaintiff sends letter notifying defendant of alleged violations of ADA
  2. Defendant says, in polite lawyerese, “stuff it”
  3. Plaintiff files lawsuit

Everything is downhill from there. History proves this rather well with Target, Netflix, and more. Outright refusal to cooperate is very poor strategy.

Hire a qualified accessibility consultant

Every single settlement – and indeed most of the demand letters – that I’m aware of will call for the defendant to engage an accessibility consultant to assist the defendant in making their website accessible. This is pretty obvious. If your website is allegedly bad enough to warrant a legal complaint, then there are probably systemic issues in the organization. You may have problems in policy and procedure. You may have general quality problems. You may have training problems. You may have any number of problems that require the assistance of a qualified accessibility consultant. Find one immediately so they can help you along the way, and ensure that they’re involved in everything – as a team member, not an outsider.

Get serious about accessibility

There’s really no question about it: Whether or not you wind up averting a lawsuit, you will be fixing your website. If it goes to settlement, fixing the website will be one of the requirements of the settlement. This is where your accessibility consultant comes in. You need to make sure your consultant has experience with policies, procedures, project management, UX, and development. All of these things will come into play during this process and you need to make sure your accessibility consultant can handle that for you.

An effective approach to accessibility is going to require full support all the way up to the top of the org chart. The converse is also true in that I’ve never seen an organization be successful with accessibility in the long-term without executive support.

Accessibility Everywhere

When it comes to development, everyone involved must be empowered to contribute to the improvement of the system. Everyone from Project managers to designers, developers, QA, and content creators have an impact on the system’s accessibility and each should be allowed (and expected) to contribute to accessibility efforts. The larger the organization, the less that siloing accessibility will work.

Push hard on your vendors

In the recent activity, all of the defendants are retailers. Most retail websites operate on a handful of major e-commerce platforms and also use third-parties for coupons, gift cards, and similar services. In some of the earlier lawsuit settlements, third-party content was considered exempted from the settlement terms. The reasoning is sound: you can’t be compelled to fix someone else’s stuff. Due to the way that many of these e-commerce products are intrinsically tied to the rest of the business, I suspect that plaintiffs are less likely to have any sympathy with this argument. Back when Target was sued one of their arguments was that their problems were caused by Amazon’s e-commerce platform. So, while some things like your gift card provider might be exempt, blaming your accessibility problems on your choice and use of an underlying platform is probably going to gain little traction. Ultimately that which is served from your domain will be seen as being under your control and therefore the liability lies in your hands. Regardless of how any of that plays out legally, your best approach is to push hard on your vendors to get them to fix their own accessibility issues.


In my opinion, you should consider yourself lucky if the legal complaint comes from Lainey Feingold and Linda Dardarian. Their approach, which they call structured negotiations fosters a more collaborative approach than the typical complaint process. Why this approach is so awesome is that it is aimed at eliminating the adversarial nature you’d expect from a legal complaint. But even if it isn’t Lainey and Linda you’re dealing with, that doesn’t mean you can’t collaborate on a mutually agreeable outcome. If you agree that discriminating against people with disabilities is fundamentally wrong, then collaborating seems a better option than fighting – for everyone involved.

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

The business case for issue prevention: Extreme Accessibility

I originally posted this on LinkedIn. It turns out that LinkedIn is a poor place for me to reach my audience, as my average post gets 10x as many views as this post first got on LinkedIn.

There have long been discussions on the accessibility industry surrounding the business case for accessibility. The Education and Outreach Working Group at the Web Accessibility Initiative of the W3C developed a large set of resources on this topic to which I posted a series of blog posts in response. During that series, I concluded that “Reduction of Legal Risk” had the strongest ROI. At the time, however, I failed to realize what so many others also continue to overlook: accessibility issues are bugs and should be treated that way. Accessibility is unique in that it exists at the crossroads of technical quality and user experience. On the technical side of things accessibility can be seen as a quality domain. Bugs in the code result in user experience issues for specific populations of users. Resolving the bugs increases quality.

It is with this sentiment in mind that gave rise to Tenon‘s mission statement:

To create robust, accurate, forward-thinking software that integrates accessibility testing into all phases of development and workflow. Together we can achieve a more accessible Web.

We meet this mission by providing an excellent service and ecosystem to allow our customers to prevent bugs before they happen.

Remediation takes money and time. Prevention saves money and time

It almost seems too obvious to mention: no bugs means no money spent on fixing bugs. But bugs are inevitable. Given the inevitability of bugs, when the bugs are found and fixed is the critical factor in saving money. How much money is difficult to determine. Back before the web, Barry Boehm estimated the expense of post-production remediation to be 100x the cost earlier in the software development process. This became known as the Boehm Curve. While the “100x” estimation has been questioned by many, what isn’t under question is that late discovery of defects is orders-of-magnitude more costly. The cost of defects is massive.

…although all errors cannot be removed, more than a third of these costs, or an estimated $22.2 billion, could be eliminated by an improved testing infrastructure that enables earlier and more effective identification and removal of software defects. These are the savings associated with finding an increased percentage (but not 100 percent) of errors closer to the development stages in which they are introduced. Currently, over half of all errors are not found until “downstream” in the development process or during post-sale software use. (
Source: NIST)

Defects don’t just cost the money needed to fix them. Simple metrics like raw cost to fix a defect only take into consideration the time it takes for a developer to fix a defect. The economic benefits of avoiding defects extend into and beyond all phases of development including the maintenance phase. In total, the Cost of Quality is the Cost of Conformance + Cost of Non-Conformance and that includes typical development, remediation, maintenance, and user support costs. Many thought leaders in the quality domain focus on these costs alone. Others, such as Capers Jones agree that simple cost-per-defect metrics aren’t quite enough and apply other metrics such as function points.

Beyond development and remediation, there other costs you may be unaware of such as Costs of Acquisition and (missed) Customer Lifetime value. These are metrics intrinsically tied to a business’s profitability. System defects impact these factors as well for cases where the defects impact core system tasks or features used during conversion. Something as simple as an inaccessible “Sign Up” button may completely prevent somewhere from 7-12% of visitors from converting.

Reliable web accessibility business case numbers are hard to come by due to the strong relationships between quality, usability, and accessibility, but it isn’t hard to imagine that the end result is the same, from an ROI perspective, as in the brick & mortar world:

three quarters (75%) of disabled people and their families said that they had done this (75% of disabled people and 76% of parents or carers). Looking at this across impairment, the percentage of people who have left a business can reach 83%. In particular, 83% of those with memory impairment, 81% of those with a behavioural impairment, 81% of people with autism and 79% of those with a learning disability said they had left a business for this reason. (
Source: Business Disability Forum)

Given the significant risk to project budgets and revenue from users, proactively addressing accessibility makes the most sense

The above image shows an annotated version of the famous Boehm curve (Source: Scott Ambler) showing that even in Agile projects, due to the length of the feedback cycle and the increased likelihood that effectively addressing the issue becomes more difficult: “The average cost rises exponentially the longer that you wait because you continue to build upon a shaky foundation”. Nowhere is this more true than in the case of accessibility, where design and platform decisions made early will impact production and issue remediation later.

Extreme Accessibility delivers significant ROI compared to traditional web accessibility approaches

Agile techniques, such as Test Driven Design (TDD), pair programming, and Agile Model Driven Development (AMDD) all have very short feedback cycles, often on the order of minutes or hours. Traditional techniques, such as reviews, inspections, and big requirements up front (BRUF) have feedback cycles on the order of weeks or months, making them riskier and expensive. (
Source: Scott Ambler)

Reducing costs from software defects requires that we shorten the feedback loop for finding and fixing those defects. As indicated in the chart included earlier, the feedback loop is quickest when using Extreme Programming methodologies and this goes for accessibility feedback as well as other quality domains. However, accessibility professionals have shown little ability to fully integrate accessibility with extreme programming practices, which means that accessibility has, in turn, remained overly expensive, time-consuming, and ineffective. Feedback must occur at all phases of product development, with high importance placed on the earliest phases. Instead, traditional accessibility testing occurs in the last stages of the project which means, in turn, that accessibility compliance becomes more costly and time consuming than it should be.

The Extreme Accessibility methodology requires a cohesive approach to testing that involves creating 6 feedback points that feed into the others.

Requirements must be defined in a way that indicate the specific business and user-interaction requirements of what is being developed. These requirements should be separated into definitions of the distinct features being developed and should be done with enough specificity that they can be used as inputs for design, development, and quality assurance feedback points. Any feature that does not make sense when documented will not make sense when used. Therefore this is the first, fastest, and easiest point in the feedback loop. Using a domain-specific language like Gherkin facilitates this.

Design must adhere to the feature requirements defined for the product. Requirement definitions are implemented here and this offers the first opportunity to verify quality of a previous feedback cycle. Applying the principles of Lean UX are especially important here. As before, issues discovered within-cycle should be handled within-cycle as well, to avoid polluting later phases with quality issues.

Development is where the bulk of accessibility issues are created, often owing to a lack of appropriate tooling. Development processes within agile environments have their own unique feedback cycle. Developers can (and should) leverage code-quality tools such as linters, syntax checkers, unit testing, and other automation to check code prior to committing it to revision control. Developers should also leverage the feature requirements specifications as an input to verifying that they’ve met the requirements for the product. Code should never be committed that doesn’t pass automated tests, because letting these defects pass into the next feedback loop will significantly increase cost and risk. It is critical, in this phase, to leverage a tool that can integrate directly into their IDEs or task runners to shorten the cycle for accessibility feedback.

Quality Assurance is a verification step for development’s automated tests and an opportunity to perform manual review. In this phase the same inputs that were generated during requirements and used during development will form the basis for acceptance tests. Automation scripts should use the same tests as those used in development. In cases where feature specifications cannot be fed into automation, QA engineers will utilize those specifications as acceptance test scripts such as with Selenium.

Continuous Integration provides an opportunity to catch regressions in code before it is deployed using the same automation scripts used by development and QA staff. This prevents critical flaws from entering production.

Review provides the ability to gather up those quality flaws that slipped through the cracks, either by virtue of sheer mistake or by knowingly taking on technical debt along the way. The review process should facilitate exploring lessons learned along each cycle in order to improve future iterations.

Though much of the above sounds similar to the “test early, test often” beliefs espoused by others in the field, the specific details – including actionable guidance, job aids and, most importantly, tooling around such process have been discussed as mere concepts. With the creation of tools like Tenon.io this no longer needs to be the case.

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 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.


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.


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


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.