The Unfortunate State of Professional Web Accessibility

Cross posted from medium.

I see it happen on a regular basis, a client insists that their site is “fully accessible” or “fully WCAG 2.0 AA Compliant,” and it isn’t even close, and I don’t mean “they missed a spot,” or that there is some narrow area that I would have personally handled differently. I am referring to giant, obvious, even basic accessibility issues that still exist on the supposedly compliant site. Usually, the culprit is a web-related services company who added “accessibility remediation” to their service offerings without fully understanding what that meant or gaining the necessary expertise.

Let me be clear, any improvement in the accessibility of a site is good, even if the site is far from “fully accessible.” We do not want the perfect to be the enemy of the good. There are, however, a great many companies offering “complete compliance”, “certified compliance”, “certified ADA compliance,” and “certified WCAG 2.0 AA compliance,” that have in reality, chosen to pay attention to only a fraction of the standards that they are claiming to attain.

To state it in another way, if a company is certifying a website as “fully WCAG 2.0 AA compliant” then they should know every WCAG 2.0 AA success criteria inside and out. They should understand the best practices that are recommended by the W3c and by the web accessibility industry. They should be well aware of common failures for every success criteria and how to spot them. They should know the strength and weaknesses of automated testing and when manual testing and QA are needed (which will be something like 70-80% of the work that they do). They should know what it means to get as close as reasonably possible to that conformance level as a site can get. And they should absolutely be aware that while a high level of conformance is possible, perfect conformance is not.

Here are some of the major accessibility failures I see regularly on allegedly “WCAG 2.0 AA certified” websites.

Text Images

No, you may not just use text images wherever you feel like it. Text images are not accessible. They cannot be resized, or restyled for users that have vision or cognitive issues. That is why they are effectively prohibited where they can be recreated via css and actual text. There are a narrow range of exceptions to that rule for items like logos, and depictions of font families. I see this all the time on these supposedly remediated sites — dozens to hundreds of ads and banners that use images of text. Often the developers of these sites do not even attempt to include all of the text from the image in the alternative text attribute, which violates another success criteria.


If you do not understand the color contrast requirements, then you are missing one of the most basic accessibility requirements. The problem is that there is a little bit of variation in the contrast requirements based upon the size of the text. Some “accessibility remediation” providers seem to have decided that a 3:1 ratio is all that is needed for all circumstances. Sorry, no. For fonts that are smaller than 24px and not bold the criteria is 4.5:1. If your font is bold that change happens at 18.66px — smaller than that and bold still needs the 4.5:1 ratio.

Pause moving content

Does your content move, rotate, animate, or update, for more than 5 seconds? Then you need a pause button. That means that unless it stops moving entirely and never moves again by the 5 second point, then you should have some sort of pause button that stops the movement. Your auto-rotating banner is entirely non-compliant without this. Your animated flash ad in the sidebar is non-compliant without a pause button. Where is it?

Forms need labels

Yes, there are some exceptions to this rule, but those exceptions are there for circumstances where a label would not provide a benefit, or might make the interface more confusing. You can’t just toss your form input labels because your design team thinks a form looks “cleaner” without them. This is such a basic requirement, that it amazes me how often I see sites that completely neglect this, or use some other technique to try and work around it. Placeholder text is not a replacement for labels or instructions, because placeholder text disappears when you type into its associated input.

Focus States

Have you ever tried to navigate your computer with a mouse after the cursor has disappeared. You can’t do anything, because you can’t figure out where you are on the screen. Focus states are the equivalent of the mouse cursor for keyboard users. If you have disabled focus states or overridden the defaults with something effectively invisible, then you have a site that is not navigable with a keyboard, and hence not accessible. Visible focus states are an explicit WCAG 2.0 AA requirement.

Hidden panels that are not properly hidden

So you are casually using your keyboard to navigate through a website when suddenly your focus state disappears, and then it reappears 40–50 tabs clicks later. It probably just disappeared into a hidden menu that was not fully hidden from the DOM. This happens when developers hide an element by using off screen positioning or some other similar technique rather than “display: none” or “visibility: hidden.” The result is that you just failed the keyboard operability requirement, the visible focus states requirement, and the focus order requirement. It’s like a three-for-one failure, and it really does create a terrible experience for keyboard users.

Look Ma, I beat the automated accessibility checker!

Automated accessibility testing tools are very important, however, they can give you false positive results, false negative results, and they really only cover a small fraction of the accessibility issues that need to be fixed. The vast majority of the issues (75–80%) can only be found via manual testing. But that doesn’t stop less-than-well-trained remediation companies from simply trying to beat a specific accessibility tool, rather than developing a full remediation plan. In the process, they often create problems worse than the ones they are trying to fix.

I have seen sites that put “display: none” on their form labels. This accomplishes nothing. It does not provide readable labels or useful instructions to any of your users. But it does fool some accessibility testing tools.

On another occasion, I saw a site in which the “accessibility remediation company” realized that that css icon fonts (Font Awesome in this case) needed some sort of text inside of a link. Screen readers cannot read css icon fonts, and so when they are used for a link, the developer needs to provide some sort of text to the assistive technology users. The developers at this firm solved the problem by using a span element with “display: none” on it, inside the link. The span had the proper text of the link — the names of the associated social media websites in this case. Unfortunately, assistive technology does not read elements that have “display none” on them. So what did this accomplish? It passed an automated accessibility tool, while not actually providing readable text or a functional link to assistive technology users.

Assistive Tech users are not the only users you are trying to reach

Don’t “screen-reader-only” your skip link. Seriously, don’t do it. Think of all the sighted people with mobility issues that really do not want to tab through all of your navigation. Think of them, please. And while you are at it, labeling inputs in a form actually helps everyone understand what your form is for. Please don’t “screen-reader-only” your labels on anything that is not a super simple, very small (like single input) form. I understand that sometimes you are trying to squeeze a little search box into a small area of a header somewhere, it is already obvious that it is a search box, and that a label could be redundant. But did you really just “screen-reader-only” all of the labels on your “contact us” form? Seriously, don’t do that. For those not familiar with the concept of “screen-reader-only,” there are multiple techniques for visibly hiding an element while making it still readable to screen readers. Sometimes, these techniques are both necessary and appropriate, but like any useful techniques they can be misused and misapplied. Remember to consider how those without assistive technology might be using your site. Users with mobility impairments, but not vision impairments are often forgotten in the push to make a site “screen reader friendly.”

Don’t Forget HTML validation

It’s actually really important that your HTML be parseable. Browsers are very forgiving when it comes to developers using poorly formed code, deprecated code, and even misusing their HTML. If you don’t ever try out the validator, you will never figure out that those <style></style> tags are really only supposed to go in the head of your document, not the body. You might never figure out that your CMS is injecting duplicate ID’s into your page. You might never notice that half the attributes you are using on your tables were deprecated a long time ago. Not every piece of software that attempts to read your page will be as forgiving as a browser, and all of your careful efforts to make your site accessible could be in vain, if it turns out to be non-parseable.

Headings have an order

That’s what the numbers are for. H1, H2, H3… They should go in order. They are not there to satisfy the styling plans of your designer. They should be used in a logical way. Your H1 should be closely related to the title of the page, or be a clone the title itself. Each subheading that is not nested inside of another heading will probably be an h2 at this point, subheadings nested inside of h2’s should be h3’s, etc. There are multiple requirements that relate to this, but the most relevant is likely that the structure of your page should be programmatically determinable. If you are using fake headings like bold font in the place of an actual h tag, or mis-ordering your headings, your page structure will not be understandable to assistive tech users.

Use roles and aria attributes correctly

Semantic HTML elements have implicit roles, you should know what those are. Both aria attributes and roles are meant to be used in specific ways, and have rules for how they are used. Some aria attributes are not allowed on specific html elements. Some areas of your page are considered landmarks, and should have appropriate roles associated with them. Sometimes, remediation firms completely muck this up, and even, on occasion, make up their own roles or aria attributes. Seriously, you can’t just make up your own “aria-stuff”.

The bigger picture

There are so many other issues that are necessary to address to make a website WCAG 2.0 AA compliant — i.e “fully accessible.” The things I listed above are actually the very basic requirements. And when a remediation company has misunderstood, or even completely failed at the basics, then I already presume that they are missing the much more complex issues.

If they can’t figure out contrast or form label requirements, I am going to presume they do not know how to support 200% zoom, or that they have not adequately screen reader tested their sites on IOS devices. They probably never noticed how very inaccessible their mobile menus or accordions are. I am also going to presume that they do not have a clue about how screen readers deal with form input validation, or if their forms are even usable with assistive technology.

Imagine, for example, if every single form on a site was completely unusable to non-sighted users, in spite of the fact that the site was “certified accessible,” because it was using an old inaccessible version of captcha. I have witnessed this on multiple sites, and it is tragic. The owner of the site sincerely believes that they are serving all of their users with a fully accessible site, while entirely failing in one of the most crucial areas.

As developers, we have been misusing and abusing our HTML for years. We have developed and propagated css techniques that fail to consider how both third party software, and assistive technology users will interact with our sites. We have almost entirely neglected the concept of keyboard navigation while designing our desktop sites around the interactive presumptions of mouse and trackpad use. And we have embedded widgets and tools into our sites that block some groups of users entirely from using the services offered by our sites. This is why a deep understanding of website accessibility is crucial to not just those developers that specialize in it, but to all developers who work with the web.


Crunch Time!

I just officially withdrew from Texas State. Hooray!

I sincerely believe in the importance of continually educating yourself. “Never stop Learning,” is not my mantra, because I do it automatically. I don’t need it as a mantra. The whole concept of continual learning and growth is deeply a part of who I am.

I am cheering because Texas State is the third institution of higher learning I have attended, and the second one that I found to be completely stultifying. Too often, my courses were an impediment to learning rather than a pathway to it.

Were all of my classes that way? No.

I took a great class on ethics, an amazing class on art history that completely changed how I thought about European history, a creative writing class that allowed me to hone my writing and critiquing skills in unexpected ways, and a spectroscopy class that I loved.

However, I could fill volumes with things about my other courses/professors/labs that were frustrating, irritating, depressing, infuriating, and just absurd. One day maybe, I’ll write a book or a series of articles that properly spell out all the absurdities that go along with big universities. I suspect many of those topics have been covered already in books by other authors. Still, I was the 18 year old kid once at UGA blaming myself for not being able to adapt to the university setting. I was that kid who was so proud of her A.P. scores and of her love of math and science, who felt like a failure because she wasn’t getting anything out of her classes.

“You get out of it what you put into it.” I must have told myself that a thousand times. Unfortunately, it is not always true. I actually can’t name a single class at UGA that I believe was worth my time in the two years I spent there. By comparison, Austin Community college reignited my love of chemistry, geology, and math. I still remember the kid I was, skulking at the idea of going to a community college. I was too smart for that, I was going to a ‘real school.’ It seems so naive now.

I hate the idea of all the kids that blame themselves for our ridiculously backward educational model. Someday, I’ll have to write more about it in detail.

Today, I have just over 10 days before the start of Makersquare.

I no longer have time to worry and lament about past wrongs. Now, I am going into a program that I wholeheartedly believe in, run by talented, passionate people that I believe in.  My ambition is to work in a field that has changed the world several times over in my lifetime and yes, I think I will be good at it at some point.

I have finished my assigned pre-work. Now I want to review every bit of it, some of it for the third time. I am going to revisit anything I didn’t quite get the first time, and scan previous lessons for any concepts, commands, or functions that I haven’t yet brought into my practice work. I am going to work a few extra ruby tutorials,  get a firm grasp of how to work with github, make a few more practice web pages from scratch with jQuery/javascript functionality, and try any tutorials that caught my interest in the past. I am even going to rework the command line tutorials to remind myself of any commands I might have forgotten.

I know some of these things will sink in more after I start using them regularly. That is why I haven’t had to revisit the HTML tutorials. I know it because I have used it. I need to be there with everything, and while I realize that Makersquare is going to help me with that, (that is why it is an intensive 40-hour-a-week, immersive program) I want to hit the ground running. I want to excel. I want to minimize the things I have to review and maximize the ‘learning new techniques,’ and ‘working new challenges.’ I want to shorten my learning curve. Now, I am wondering if that is a silly thing to say? Famous last words?

I want to dive in. It’s as simple as that.

A New Approach to Ruby

I have been struggling through the Ruby Bits 1 & 2 courses over at codeschool. They aren’t bad courses, but they get into nitty gritty details that I just do not have a point of reference for. That is the problem with trying to work more advanced topics before you have done enough programming work to understand how and why some of the topics help your code.

I realized that I am approaching this stuff all wrong. I am going after it like it is a college course. You learn x concepts in Ruby, you do a little practice. You learn y concepts in Ruby, you do a little practice. You learn z concepts, you do a little practice. Each set is a little more advanced than the last.

The problem is, too much of it is going in one ear, pausing in a few exercises, and then running out the other. I have worked through the ruby course at codecademy twice and I was still surprised when I came across the next operator not long ago. I didn’t remember it.

I’m trying to shove too much in without a framework for holding on to what I already know.

Continue reading “A New Approach to Ruby”

I got into Makersquare!

That is the good news. The bad news is I really wanted to do the summer course, rather than the fall course. Unfortunately, it filled up while I was studying for finals, and did not complete the application process -it required several interviews and I figured I would have more time once my last week of tests was over. So, I put it off for about 10 days, just long enough for the program to fill up. I am still thrilled to be in the fall program, and that is the reason I have jumped into the computer science tutorials so vigorously as of late.

Currently, I am learning python through Udacity and javascript through appendto. I already got through codecademy’s web fundamentals course (HTML and CSS), and ruby course. I started working on a series of Ruby on Rails tutorials at (you can watch videos in their library for free), and I am trying to read through an online rails tutorial as well. Frankly, the straight programming makes a lot more sense to me than the rails stuff. It seems like a lot of odd words and symbols strung together. But then, I just started. I am hoping to get to Udacity’s HTML 5 for game development course. I need to get some basic javascript down first though, and hence my current work. Ultimately, I am hoping I can combine my passion for subjects like chemistry, and geology into amazing web apps. We will see!

Today’s Learning/ interesting stuff I am coming across in programming

Javascript is “weakly typed.” If I am understanding that correctly, this means that you can switch between data types and the language itself will try to change the data types to match.

In other words it is easy to use data of one type such as an integer as data of another type such as a string, and the interpreter will coerce one of those data types for you so that they can be used together. The trick seems to be knowing how and when a data type will be coerced into a different type. For example if I wanted to add a string to an integer, but really I wanted the string to be converted to an integer and then added numerically to it, this would be very different than the integer converting to a string and then concatenating together. This is important to remember as a distinction in how Javascript is different from languages like python and ruby.