Karl Groves

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

Quick Tip: Text Characters as Visual Separators

I’ve been running into these pretty frequently lately so I figured I’d throw something together about it: text characters as visual separators.  As much as I’d like to say modern development practices have grown beyond such things, it apparently hasn’t.

<ul>
<li>Foo</li>
<li>|</li>
<li>Bar</li>
<li>|</li>
<li>Bat</li>
<li>|</li>
<li>Baz</li>
</ul>

The above code structure, obviously scrubbed to protect the guilty, was used to provide a visual separation between links in a website’s footer. Screen readers will likely announce the number of LI elements an then read the list. Depending on the specific screen reader and the user’s settings, it may or may not announce the pipe characters. If it doesn’t announce the pipe characters, users will still be expecting 7 items, not 4. In the grand scheme of things, this probably isn’t the worst thing you could do, but it also betrays a lack of skill, especially considering how super easy it is to do this right:


<ul>
<li>Foo</li>
<li>Bar</li>
<li>Bat</li>
<li>Baz</li>
</ul>

li{
    list-style-type: none;
    display: inline;
    margin-right: .3 em;
}
li:not(:last-of-type):after{
    content: ' | ';
}

See this at: http://jsfiddle.net/karlgroves/8wXa8/

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

US DOJ Intervenes in NFB et al. vs. HR Block Case

From the US Department of Justice’s ADA office:
The Justice Department announced today that it seeks to intervene in a lawsuit against HRB Digital, LLC and HRB Tax Group, Inc. (“Block”) in federal court in Boston to remedy violations of the Americans with Disabilities Act (ADA). The department’s proposed complaint in intervention in the lawsuit, “National Federation of the Blind v. HRB Digital LLC and HRB Tax Group, Inc.”, alleges that Block discriminates against individuals with disabilities in the full and equal enjoyment of its goods and services provided through www.hrblock.com.
The complaint is online at http://www.ada.gov/hrb-proposed-complaint.htm

The above message was posted to the WebAIM Discussion list yesterday, November 26, 2013 by Bevi Chagnon.

The history of Web Accessibility litigation is an interesting one, made more interesting by the fact that the first notable lawsuit regarding web accessibility took place 14 years ago and yet the DOJ has yet to issue specific requirements regarding the legal requirements of the public web. This lack of clarity has not stopped the somewhat steady stream of accessibility lawsuits in recent years. The DOJ has consistently stated that their position is that the Web is a place of public accommodation and that, by law, the ADA does apply. Effectively, their position has been that despite the lack of a revised Final Rule, all websites must be accessible. This latest lawsuit is just another in a series of recent actions where the DOJ is demonstrating this.

What does this mean?

As my friend and former co-worker Elle Waters likes to say, “Do you want to spend your money [on web accessibility] on your budget and timeline or on a budget and timeline dictated by someone else?” What is clear – and made more clear with each new lawsuit – is that reduction of risk makes a clear business case for accessibility.

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

Issue Reporting: How to ensure your issue report is successful

Issue tracking systems employed by development teams can often be configured in a variety of ways, but they almost always have the same basic configuration that asks for essentially the same information. When creating an issue in an issue tracking system, the following guidance should be followed to ensure that developers can quickly and accurately fix the issues reported to them.

Summary (may also be referred to as “title”) – This should be a high level description of the issue, including where it exists.  Because this field is usually a single line text input, it must be very concise and clear, such that anyone reading it can understand what the problem is immediately: “Registration form: Text input elements have duplicate ‘id’ attributes.”

Description – This would be where you’d enter a bit more long-form description of what this issue is about. In other words this provides the details on specifically what is the problem, where is the problem, why it is a problem, who is affected by it, how bad the problem is. Also include existing code and recommended changes to the code.  If specific code examples can’t be supplied, use a text description.  Always provide specific information on how to fix the issue. There’s no such thing as too much detail here as long as it is relevant to the specific issue you’re reporting.

For example:

Text inputs for “E-mail address” and “Desired Username” have the same value for their ‘id’ attributes. The value used for both ‘id’ attributes is “email”, but the “Desired Username” field’s label points to a nonexistent ‘id’ of “username”. This is likely a typo but will mean that users of screen readers may input the wrong text for one of these fields and may repeatedly fail validation while trying to figure out which field is which. All text inputs must have a <label> element with a ‘for’ attribute that matches the ‘id’ attribute value of the corresponding input. The ‘id’ attributes must be unique.

Existing Code:

<label for="email">Desired Username</label>
<input type="text" name="username" id="username" />
<label for="email">E-mail Address</label>
<input type="text" name="email" id="email" />

Recommended Code:

<label for="username">Desired Username</label>
<input type="text" name="username" id="username" />
<label for="email">E-mail Address</label>
<input type="text" name="email" id="email" />

Platform – This information is most needed if there are specific platform issues to consider during debugging. If you’re unsure whether that’s the case, just include it to be on the safe side. Include your operating system & version, browser & version, and assistive technology & version.

Steps to Reproduce – This should include what it takes to see the problem first hand.  This is really useful for stuff like focus management issues, but not so useful for basic stuff like form labels, alt text, or table headers which can be clearly articulated in the description, especially if you’re including code samples.

The following format is preferred:

Steps to reproduce:

  1. Go to Page X
  2. Activate the link labeled “Help”
  3. A dialog will appear titled “Get help from Y”

Expected Result:

  1. Focus would be shifted to the first actionable item in dialog
  2. Focus would remain in dialog only, until dialog is closed

Actual Result:

  1. Focus shifts to the first actionable item in dialog
  2. As they tab through, the user can gain focus on items outside of the dialog

By clearly and accurately describing the issue you’ve experienced, you can help the development staff understand the issue and guide them toward making a fix. Unclear, confusing, or incomplete issue reports only tend to delay repair while developers try to discover what the actual problem is. The better your report the more likely it will be fixed soon and accurately.

I also highly recommend reading Contacting Organizations about Inaccessible Websites

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

Taking Accessibility to the Mainstream

For years I’ve been saying that accessibility people need to branch out to the mainstream. Preaching to the converted doesn’t really help much when it comes to increasing mainstream adoption of accessibility as a way of thinking. Developers typically don’t have any depth of understanding when it comes to accessibility. Developers need to know … practical ways of using and having users benefit from accessibility techniques but how can they get that information if we (the accessibility community) aren’t aggressively trying to get it out there? For this reason, I’ve been trying to do exactly that. As a speaker and writer, I’ve been trying to reach out to more and more mainstream audiences. Conferences like CSUN and the various accessibility camps are great, but the ability to impact mainstream development communities will only happen by taking the message directly to those communities instead of waiting for them to come to you.

So, how has it gone? So far, it has been hit & miss. For instance, I’ve been attempting to talk at the local U(x)PA chapter for years (since 2006, in fact) with no success and other IA/ UX organizations and meetups have gone much the same. The same goes for local Refresh Groups and developer meetups. At the same time, I’ve been honored to take part in events like the Digital 360 Conference and ParisWeb both of which have a general development focus and include accessibility as part of the main conference. While the rejections (or non-response, as the case often is) can be frustrating, the successes are super-fulfilling. For instance:

J’avoue que certaines conférences sur l’accessibilité à #parisweb m’ont ouvert un peu les yeux. Surtout celle de Karl Groves
Nicolas Florian

Roughtly translated by Google Translate, the above says “I admit that some conferences on accessibility # ParisWeb opened my eyes a little. Especially that Karl Groves”. If I can impact even one person this way every time I speak, all of my efforts will be worth it. The frustration of rejection and non-response are washed away every time someone walks away with new insight and knowledge regarding accessibility. I plan on continuing to press for more inclusion of accessibility in mainstream development circles because of this and hope all of you will join me.

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 End User Uber Alles or, you got your reality in my idealism

As a web developer, one of the biggest sources of frustration is developing a website that works across the wide array of user agents and operating systems the visitor may be using. The web standards movement was supposed to "fix" that. It did make good progress and then CSS3, HTML5, and HTML5 multimedia and mobile devices sort of tripped that up. Luckily there are people out there creating tools and techniques to help us keep up and find workarounds for things like spotty support for new features. This reduces frustration somewhat. That is, until you add accessibility into the mix. Then you have to add assistive technologies onto your list of concerns. In addition to understanding the various differences in browser support for CSS properties, HTML elements, and DOM methods/ properties, you now have to concern yourself with the differences between types, brands, and versions of different assistive technologies. Like browser vendors, assistive technology vendors each have their own direction, their own goals and plans that may not agree with other vendors of similar products. Like browser vendors, assistive technology software also sometimes have bugs and missing or incomplete features. Like browsers, developers must make an informed and rational decision regarding which assistive technologies, brands, and versions they plan on supporting. Just as you shouldn’t be expected to support all versions of all browsers on all operating systems, you also shouldn’t be expected to support all versions of all assistive technologies on all operating systems.

None of this would be necessary if everyone just followed standards. Sadly that’s no more the case for assistive technologies than it is for browsers. I was reminded of this today, in fact, when doing some research on text alternatives for images. The way text alternatives should behave is described in The Roles Model – 5.2.7.3. Text Alternative Computation from WAI-ARIA. This describes "how user agents acquire a name or description that they then publish through the accessibility API" and it provides an order-of-precedence for the various bits of programmatically determinable text that can be used. The order of precedence should be:

  1. aria-labelledby
  2. aria-label
  3. alt attribute
  4. title attribute

What I found was a bit different and inconsistent across assistive technologies. This is definitely not a complete list of all scenarios or assistive technologies. There are also complex interplays between different browsers and Accessibility APIs, but it still illustrates the point that relying on the ideal behavior is as unrealistic when it comes to assistive technologies as it is when it comes to browsers.

When it comes to making design and development decisions, how likely are you to implement new HTML5 or CSS3 features without fallbacks? How likely are you to say, "Well, screw IE users for not supporting the <meter> element. I’m using it anyway!" Not at all, right? But you might be willing to come to that conclusion when it comes to box-model issues on IE6. These are the same types of considerations to put into assistive technology support. We must aim our efforts at the goal of achieving the greatest common good.

Thinking about this reminded me of the HTML Design Principles. "The principles offer guidance for the design of HTML in the areas of compatibility, utility and interoperability. "

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.
HTML Design Principles – Priority of Constituencies

This sort of sentiment could be used more than in just the design principles of the HTML5 specification. This should be how we handle all design and development topics – with the user first. The goal of any web design and development effort should be to ensure that we use HTML and CSS features in a way that the broadest reasonable range of people can use the system. Sometimes that will mean that users of certain brands or versions of assistive technologies will have a less-than-ideal experience. Some users, who choose to use software that doesn’t support modern technologies need to understand that their decision to use such software is impacting their enjoyment and productivity on the web. Other users may need to address their issues directly with the makers of their assistive technologies.

This does not absolve us developers from the responsibility of providing the broadest possible usability for all. That was the original reason for my research yesterday into text alternatives. What I found, in this particular cases, is that although there are multiple ways of providing a valid text alternative that should be supported by all modern screen readers, there’s only one approach that ensures usability for all users on all assistive technologies for all browsers on all operating systems. The tried-and-true ‘alt’ attribute. Modern browsers and assistive technologies can use aria-label or aria-labelledby, but such an approach doesn’t provide support for Voice Dictation Software or software/ user-agents that don’t support WAI-ARIA.

These are the types of decisions we make every day as web developers. Do we use the new shiny, or the tried-and-true? We need to answer that question from the user’s perspective, not from the development perspective – with the user taking preference.

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

Some thoughts on automated web accessibility testing

My feelings about automated accessibility testing have vacillated throughout my career. My introduction to accessibility was through automated testing. As a new web developer I began applying to jobs with US government contractors shortly after 508’s grace period ended. I was rejected several times because my work failed a test by Bobby, the most popular accessibility tool at the time. Later, as I got to understand more about accessibility and the amount of subjectivity in determining what-is-or-is-not accessible, I came to believe that only a human can perform this function. The pragmatic reality is actually somewhere in between.

I feel like we live in an exciting time in history where the technologies of the Web are evolving more rapidly than I’ve ever seen. The many new types of web-enabled devices, many uses employed for web-based technologies, and many new and emerging input and consumption modalities present numerous challenges for developers and organizations. Luckily it seems that there are plenty of enthusiastic and creative people attempting to address those challenges by creating toolsets, frameworks, and processes to make development quicker, easier, and more robust. One specific area that is particularly interesting is in automated testing and automated build systems and frameworks. Some systems, such as Jenkins can handle automated testing and building. Some companies have built their own systems, using numerous open source projects that exist for such testing, making it easy for any development team to take advantage of automation.

At the core of this is the DRY principle – Don’t Repeat Yourself. In programming, DRY is all about not duplicating functionality, because doing so adds to maintenance issues, logic conflicts, refactoring issues and, when left unchecked, ultimately a great deal of entropy. But DRY also applies to human effort, processes, and overall efficiency. We see demonstrations of the DRY principle everywhere in history going back to the invention of metal casting around 3500BC. The idea of creating a process that allows us to do something one time and having a way to duplicate that process repeatedly just makes sense. It also just makes sense to have a process or tool which will do something entirely differently but have the same outcome. To this day, workers on the line at General Motors auto plants who come up with a newer, faster, better, or safer way of building a car get a hefty bonus, depending on how well they improve the process. This has resulted in numerous innovations in safety or efficiency. This is why automated web accessibility testing makes so much sense to me.

Those who are quick to criticize automated web accessibility testing may not understand this idea of not repeating effort. Or, maybe they disagree with the idea that automated testing is effective. I believe that these feelings are well-founded because the toolsets they currently have at their disposal have made them feel that way. If the idea of automation is to replace human effort and the tool actually adds more effort or if the tool doesn’t do its job properly, then the natural conclusion is that automation is a bad idea.

In the manufacturing of physical products, the final manufactured products are tested to ensure a specific level of performance against pre-defined criteria. In some cases, the criteria are internally developed. In others cases, such as electronic products, the standards are external. Depending on the type of product the standards often include things like safety, reliability, accuracy, longevity, robustness, and sustainability. Naturally, testing and measuring equipment are tested for things like accuracy and sensitivity.

From a business perspective, the manufacturing processes themselves are scrutinized as well to ensure that the process is safe, accurate, reliable, and efficient as possible. In terms of efficiency, the business wants to make sure that the process is cheap and quick. Delivering a good product that’s cheap to make and sells for a lot is every manufacturer’s dream.

What do we make of the above few paragraphs? Whatever process we employ, we need to make sure that the process is fast, reliable, and accurate. The end result must be something that delivers high value. But what do we see when it comes to automated web accessibility testing tools? Often we see the opposite. Often the tools add a layer of complexity and a disruption in process that makes actually using the tool more trouble than it is worth. Reports are often littered with false positives that have little relevance or importance. I’ve been discussing problems with automated website accessibility testing tools for years – even issuing challenges to vendors to improve the usefulness and usability of their products. The reality is that the present model for automated testing suites like Worldspace, Compliance Sherriff, AMP, etc. is fundamentally broken. They will never eliminate the ways in which they disrupt the modern web development and QA workflows.

This does not, however, mean that automated web accessibility testing itself is bad. On the contrary. I believe strongly in it and my belief gets stronger every time I think about it. At last year’s CSUN, I presented a session titled Choosing an Automated Accessibility Testing Tool: 13 Questions you should ask. I now think that there are really only three things that warrant consideration:

  1. Flexibility and Freedom. These tools exist for one reason only: to work for you. Every single second you spend learning the UI, figuring out how to use it, or sifting through results is a second of development time that could go into actually improving the system. The tool must be flexible enough to offer the freedom to use it in any environment by any team of any size in any location.
  2. Accurate. Developers of accessibility tools want to find every single issue they possibly can. This unfortunately often includes things that are, in context, irrelevant or of low impact. They also may require an additional amount of human effort to verify. This is a disservice. Tool vendors need to understand that their clients may not have the time, budget, or knowledge to sift through false positives. The user should be able to immediately eliminate or ignore anything that isn’t an undeniable issue.
  3. Understandable The user of the tool needs to know exactly what the problem is, how much impact the problem has, where it is, and how to fix it. Overly general, overly concise, or esoteric result descriptions are unhelpful. If a tool can find a problem, then it can make intelligently informed suggestions for remediation

Those who are anti-automated testing probably don’t fully have the perspective needed to understand how useful it can be. The primary activity I perform at my job is to do accessibility audits. Even to this day, 14 years after WCAG 1.0 gained Full Recommendation status, I still find easy-to-discover issues like missing alt attributes for images, missing form field labels, and missing header cells for tables. These are things that are super easy to accurately find using automation. In fact today I tested a page that had 1814 automatically detected errors with zero false positives! The detractors against automated testing are very right about one thing: There’s only so much you can do with automated testing. There are a large number of things that are too subjective or too complex for machine testing. But this doesn’t mean that automated accessibility testing has no value. It means that we need to use it wisely. We need to apply the tool at the right time and for the right reasons. We need to understand its limitations and capabilities and use them in a manner that exploits the capabilities as efficiently as possible. At that point, automation will be viewed as the vital part of the developer’s toolset that it should be.

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

Diagnostic.css – Super quick web accessibility testing

In my quest to make accessibility accessible, I’ve created a super-easy-to-use tool that people can use to do accessibility testing. If you can view the page in the browser, you can use this tool. Diagnostic.css is a CSS (Cascading Stylesheets) file which, when applied to a web page, will highlight accessibility errors in the page.

What it Tests For

  1. Deprecated elements
  2. Deprecated and/ or presentational attributes
  3. Inline frames without title attributes
  4. Server-side image maps
  5. Images without alt attributes
  6. Image buttons without alt attributes
  7. Image Map area elements without alt attributes
  8. Items with an img role without aria labels
  9. Images without a valid src attribute
  10. Links without a valid hypertext reference
  11. Fieldsets without legends
  12. Label elements without for attributes
  13. Invalid dir attribute values
  14. Empty TITLE elements
  15. Implicit headings
  16. Meta refresh
  17. Missing lang attribute on the HTML element
  18. Use of accesskey attributes
  19. Empty table header cells
  20. Possible layout tables
  21. Invalidly nested lists

How to Use It

There are two primary ways to use it:

  1. Super-easiest: Drag this link to your browser’s bookmark toolbar – Diagnostic.css. Once it is in your toolbar, all you have to do is go to a page you want to test, and then click the bookmarklet. This will test that page against the latest-and-greatest version of the stylesheet.
  2. Pretty Easy: Download the code from GitHub and do as you wish. Install it on your page as you develop, as a quick sanity check during your own testing.

Caveats

  1. CSS Generated content is not content. Consequently this means that this testing method may not be accessible for people with certain assistive technologies. According to a brief conversation on Twitter with Ted Drake and Marco Zehe, generated text content is available to JAWS and NVDA. I highly doubt that Window-Eyes or VoiceOver users will be able to access the error messages.
  2. This is not comprehensive. There are scores of other tests that could be performed with a dedicated automatic testing tool. As a result, this shouldn’t be the only thing you use in your testing. The intention of the diagnostic style sheet is to do a “smoke test”, if you will, to find some of the more egregious issues quickly and easily.

Diagnostic.css is among the easiest ways one can test for accessibility. That being said, it still does less than two-dozen tests. For more easy ways to test, check out The 6 Simplest Web Accessibility Tests Anyone Can Do.

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

Web Accessibility Testing Tools: Who tests the DOM?

Earlier this year, I put up the Mother Effing Tool Confuser to help those who may be looking for an automated web accessibility testing tool make an educated decision. I’ve recently decided to do some of my own testing to see which tools do and don’t test the DOM. To do so, I used the Complete List of Web Accessibility Evaluation Tools from the W3C. I am limiting my own tool evaluations to those which do a more comprehensive test against WCAG. For each tool available, I tested the Mother Effing Tool Confuser page and, if the tool finds errors, then it isn’t testing the DOM. Simple.

At the moment, the only data I’ve gathered is for Online Services – those which allow you to submit an URL and get a report. For the most part, you can assume that browser toolbars will test the DOM, but I do plan on testing those as well and will update this blog post with that data.

Note, May 29, 2014: When I say “Test the DOM”, I’m specifically referring to assessing the DOM after rendering completely with any relevant JavaScript applied. A more accurate term might be “JavaScript-aware”

Online Services – tested 06-Sept 2013

Online services are those services that allow you to enter the URL for a page you wish to test and the service spits back a report. Several such tools from the W3C list no longer exist. Some services appeared down or otherwise broken and are therefore not included. For instance both the Truwex tool and the online version of FAE returned blank screens when I attempted to use them, so they aren’t listed here.

Amazingly, of those which I could use, only three actually tested the DOM: Tenon, SortSite & Opquast. .

Tool Name Do they test the DOM?
Notes:

  1. Updated November 7, 2015
  2. Included here mostly due to my own curiosity
Tenon Yes
aChecker No
Etre No
Accessibility Valet No
EvalAccess No
Hera No
CynthiaSays No
DaSilva No
TAW No
SortSite Yes
WAVE Yes 1
Opquast Yes
W3C Validator No 2
Validator.nu No 2
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 6 Simplest Web Accessibility Tests Anyone Can Do

What if I told you that the WCAG 2.0 recommendation by the W3C is 36 pages, printed? In addition, “How to Meet WCAG 2.0” is 44 pages and “Understanding WCAG 2.0” 230 pages. Not only that, but the accompanying Techniques and Failures for WCAG 2.0 is 780 pages, printed. There are approximately 400 Techniques and Failures. All of it is wonderful information created by some of the most knowledgeable accessibility folks available. Unfortunately it presents a sort of barrier-to-entry for folks who really just want to know what they need to do to be more accessible. This barrier works both ways: one shouldn’t assume this is easy work. You can’t just flip a switch and have an accessible site. To truly understand accessibility and accessible web development requires extensive knowledge of HTML, CSS, JavaScript, the DOM & BOM, accessibility APIs, assistive technologies, and how people with disabilities use computers. I’ve dedicated my career to it and find out the more I know the less I understand.

What about those for whom accessibility isn’t their career choice? What about those who don’t want to know things like the complicated interplay between markup, DOM interfaces, and accessibility API role mappings? What about people who want to know: “How does my website perform for people with people with disabilities?” Here you go. 6 tests that anyone can do without any development knowledge.

1. Unplug your mouse and/ or turn off your trackpad

Possibly the quickest and easiest way to test your website’s accessibility is to unplug your mouse and/ or turn off your track pad. This would require, naturally, that you use only your keyboard to interact with the site. The test process is simple: Interact with the site using only the keyboard. The ‘Tab’ key will allow you to traverse forward in the tab order. Activating the ‘Shift’ and ‘Tab’ keys at the same time will traverse backwards in the tab order. Pressing ‘Enter’ will follow links, and so on.

  1. Can you interact with all controls, links, and menus using only the keyboard?
  2. Can you see what item has focus at all times?
  3. Does the visual focus order match the intended interaction order?

What does this mean?

A large number of persons with disabilities cannot use a mouse to interact with the web. Users who are blind can’t see the mouse pointer, users who are low vision may prefer the keyboard, users with motor control disorders may be unable to use a mouse, and it may be painful for those with chronic pain to use a mouse. If you cannot answer ‘Yes’ to all the above questions, then the site requires repair in order to be accessible. Keyboard accessibility is required for users who are blind, low-vision, or who have motor control disorders. Keep in mind: the visual focus indication is especially important for general usability and critical for users with low vision or who have motor control disorders. Not all users with disabilities are blind!

2. Turn on High Contrast Mode

In the Windows operating system, High Contrast Mode allows Low Vision users, users with light sensitivity, and sometimes users with Dyslexia a convenient means of improving their ability to successfully use the computer. Windows High Contrast Mode changes the foreground and background colors to create higher contrast. Colors on the site are essentially removed entirely. All background is black and all foreground text is a significantly brighter color such as white or yellow (users can customize this).  With High Contrast Mode turned on, interact with the site.

What does this mean?

According to WebAIM’s Survey of Users with Low Vision, 30% of respondents state they used High Contrast Modes. One of the best articles out there on this topic is Techniques for High-Contrast-Friendly Icons by Todd Kloots. In terms of sheer numbers, there are far more people with low-vision than those who are totally blind, so if your accessibility strategy is built around whether the site works in screen readers, you may want to reevaluate that approach.

3. Turn off Images

To turn off images in FireFox: go to Tools -> Options -> Content -> and then uncheck the checkbox labeled “Load Images Automatically” -> then select the OK button.   In Internet Explorer: go to Tools -> Internet Options ->Advanced -> and then uncheck the checkbox labeled “Show Pictures” -> and activate the OK button.  Other browsers are similar.

With images turned off:

  1. Does the content make sense?
  2. Does the content become harder to understand?
  3. Is any content now missing?
  4. Do any important controls disappear?

What does this mean?

Images are good for usability and accessibility. Users with cognitive disorders can benefit greatly from the combination of images and text to understand information. That said, images shouldn’t be required to understand the page and shouldn’t be relied upon for important UI controls. Any text presented in images should be placed in the markup instead, except in the case of branded content like logos or trademarks. Any images which present important content should be given a text alternative and some images are best described directly in the content of the page.

4. Check for Captions or Transcripts

OK, I lied about which of these tests was the easiest. This one totally is easier than anything you can do. If you have media on your site, check for captions, transcripts, and other possible alternatives. Wherever you have media:

  • Are there captions on the video directly or is there a control in the player that turns on/ off captions?
  • Is there an alternative version with audio description or a control in the player that turns on/ off audio description?
  • For videos with a lot of dialog, is there a text transcript on the page or link close to the video player that goes to a transcript?

Other requirements exist for video-only and audio-only scenarios, but the above will cover most media on most sites.

What does this mean?

Its easy to assume that media accessibility only impacts users who are blind or deaf, but in fact accessible media alternatives also benefit users with low vision, users who are hard of hearing, and users with cognitive disabilities. Ostensibly a text transcript is good for SEO but also beneficial for users who wish to be able to search for a specific bit of content in the media.

Note: not only should the media content itself be accessible but so should the player. Look for a future blog post on media player accessibility.

5. Click on Field Labels

Forms are the top method of interacting with websites and the top method of measuring conversion. Unfortunately, by volume, forms-related accessibility problems are among the most frequent issues. Issues with forms tend to fall into three main categories: Missing or incomplete labeling, ineffective error handling, and poor focus control. One extra-simple way to test for the existence of form labels is to simply click on the text label adjacent to the field.

  • When you click on the label next to a text input or textarea, does the cursor go into the field?
  • When you click on the label next to a radio button or checkbox does that select the adjacent option?
  • When you click on the label next to a SELECT element, does that place focus on the SELECT?

What does this mean?

There should be a one-to-one relationship between the label and the control. Unlabeled or improperly labeled controls must be fixed. There’s a lot more to consider when considering the accessibility of forms, but this quick check will at least let you tell if you’ve met a very important accessibility criteria: proper labeling of forms. Without properly labeled fields, none of the other forms best practices really matter.

6. Turn off CSS

Cascading Stylesheets is the preferred method of handling layout and visual presentation of web interfaces. Using CSS properly reduces document weight and increases flexibility for users. At this point that’s sort of old news. From an accessibility standpoint, there are a few things to look out for.

To turn off CSS in FireFox, go to View -> Page Style -> and then select No Style. Doing so in Internet Explorer is also very similar. Go to View -> Style -> and then select No Style. Other browsers are similar as well. After turning off styles check the following:

  • Background images will disappear. Did important content disappear or did any controls, icons, or other actionable elements disappear?
  • Is it now difficult to understand things like error messages or other previously-visual cues?
  • Is content still displayed in a reasonable, easy to understand order?
  • Does any color, including background color remain?
  • Do any text presentational styles remain?

What does this mean?

One of the biggest CSS-related issues I find in testing these days is the use of background images for content or controls. So, if controls or content completely disappear after turning off images, this must be repaired. If any other visual presentation remains with styles turned off, that means that old, deprecated, presentational HTML is still in use. This will mean that these presentational methods cannot be overridden by users who’ve created custom style sheets. According to WebAIM’s Survey of Users with Low Vision, 19% of users with Low Vision users browse the web with “Customized page colors or custom style sheets”.

Bonus: Diagnostic.css

Diagnostic.css is a CSS (Cascading Stylesheets) file which, when applied to a web page, will highlight accessibility errors in the page. It allows testers to do a super-quick automated test on web pages without the need to buy or install a tool.

Just. Use. It. Yourself.

I test websites, web applications, software, and mobile/ tablet apps for accessibility almost all day for my day job. One of the best pieces of advice I can give is to just use the system yourself. Put yourself in the role of a user of your system and actually use it. You’ll be amazed at the insight you’ll get into your system’s quality.

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

CSS generated content is not content

CSS is designed primarily to enable the separation of document content (written in HTML or a similar markup language) from document presentation. Prior to CSS, nearly all of the presentational attributes of HTML documents were contained within the HTML markup; all font colors, background styles, element alignments, borders and sizes had to be explicitly described, often repeatedly, within the HTML (Wikipedia) The separation of HTML from CSS makes it easier to maintain sites, share style sheets across pages, and tailor pages to different environments. This is referred to as the separation of structure (or: content) from presentation.(W3C)

Cascading Stylesheets is intended to facilitate the separation of content from presentation. Not to add to, modify, or delete content.

Generated content does not alter the document tree. In particular, it is not fed back to the document language processor (e.g., for reparsing). http://www.w3.org/TR/CSS2/generate.html#propdef-content In other words, “Content specified in a stylesheet does not become part of the DOM.” (MDN)

Good Uses of Generated Content

Among the better uses of generated content is to provide supplementary information or presentation to make the content easier to understand. One way to do this is to add icons that add context to things like links and buttons to inform users about the purpose of the link. Chris Coyier has a few good examples at Common Unicode Icons. What makes Chris’s examples (most of them) good is that he combines these unicode icons with either an obvious format or text, or both. For instance:

  <a href="mailto:chriscoyier@gmail.com">
    chriscoyier@gmail.com
  </a>

and

<p class="important">
  REMEMBER: drink slushies too fast.
</p>

(See the output at http://jsfiddle.net/karlgroves/MQqG9/

Many other examples exist that use actual icons. In the first example above, it is obviously an email address he has front-loaded with an icon. In the latter case, he’s front loaded the text with the word “Remember” implying importance (admittedly, actually using the word Important would be even better). By providing an extra icon, visual users get an increased level of usability because they’re more quickly able to understand the nature of the content.

Bad Uses of Generated Content

The problem with CSS generated content is that it is not content. As I mentioned before, CSS generated content does not become part of the DOM. This means this content is not actually available to users of assistive technologies because the relevant object information isn’t passed through the accessibility APIs. One bad example can be seen over at Signify “PDF Bombs”.


/* Add " (PDF)" text after links that go to PDFs */ 
a[href$=".pdf"]:after { 
    content: " (PDF)"; 
} 

/* If file size specified as data attribute, use that too */ 
a[href$=".pdf"][data-size]:after { 
    content: " (PDF, " attr(data-size) ")"; 
}

See it at: http://jsfiddle.net/karlgroves/83C2c/1/.

On the surface, this seems great. This link has been appended with an indication that the content is a PDF and tells us how big the PDF document is. This is useful information, for sure. Unfortunately this information isn’t available to all users because it isn’t part of the DOM. Here’s another example showing a pattern I see a lot of lately:

<a href="https://twitter.com/karlgroves"></a>
a.twitter:after {
    content:url('path/to/twitter_icon.png');
}

See it at: http://jsfiddle.net/karlgroves/dW4LU/1/

In this case we see a link that has no text at all. Instead generated content places an icon there. Because it is generated content you can’t place an alt attribute on the image. As a result, accessibility APIs cannot calculate an accessible name for the link.

What about Icon Fonts?

Icon fonts, such as Font Awesome, place their icons into the interface exactly as I’ve described: as generated content. So <i class="icon-home"></i> creates a “Home” icon via generated content on that <i> tag. Your nifty toolbar that uses only icon fonts is inaccessible. Like all generated content, it is best used as a visual supplement for existing content, not a replacement. For a good example, check out some of Font Awesome’s Examples for Navigation

Conclusion

If what you’re working with is content, it must be part of the DOM. That means using actual content and not CSS generated content. The inclusion of additional icons and the like can be an improvement, in terms of overall usability, but the additional icons must be in the foreground. For instance, here’s the same PDF link added with jQuery: http://jsfiddle.net/karlgroves/avdce/1/. Another approach would be to add off-screen text, which would function like an alt attribute. Here’s the toolbar, fixed http://codepen.io/karlgroves/pen/Ktdem. This method is less ideal in that it doesn’t help users not on screen readers. Either way, understand that CSS generated content isn’t actually content, because it isn’t actually in the document tree.

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