This talk, once again from Loopconf, is required watching not only for WordPress developers, but anyone who develops for, or writes content for, the modern web. A responsive web is a responsible web, and also an accessible web. Lastly, and I think most importantly, accessibility is everyone’s responsibility.


In the first live edition of "Ask Me Anything", going forward, to be referred to as "WPAMA", Michael from Evansville Indiana asks Amanda how to prevent crowding and overlapping of text, proper use of images, and optimizing the areas of a site built with WordPress, i.e., header right, navigation bar, footer area, etc. Amanda answers these questions in addition to explaining the return to minimalism, why sliders suck, and how site design changes almost yearly, just like fashion trends. But perhaps most useful, her suggestions for reaching out to the very helpful WordPress community to ask for help, especially for us blind implementers and designers who need to find those possessing the skills to provide greater attention to detail. This informative eight minute audio segment should provide something for everyone to take away to make your sites become even more cosmetic appealing, but most of all, highly functional and user friendly.

See Original Post: Ask Me Anything – Live Wednesdays at 8PM Eastern – Twitter HashTag #WPAMA

While WCAG 2.0 outlines specific requirements for contrast between text and background colors, these can sometimes be difficult to test.

Fortunately, there are some basic tests you can use to identify potential contrast issues.

Print the page without color

I know, noone has just a black and white printer. But printing your page without color is an excellent way to find out how it’s going to look when viewed by someone with color blindness. Alternatively, you can temporarily graysccale your site to get the same result. Just make sure you put everything back when you’re done.

Decrease your screen brightness

A second quick way to test color contrast is to look at your page with your screen brightness decreased. This is particularly helpful on mobile devices.

Take off your glasses

If you wear corrective lenses, taking them out of the picture will give you a quick and easy way to find out how a site’s going to look in regard to color contrast. If the contrast is bad, you’ll be forced to squint to get everything. If it’s good, the site will be easier to read.

Resources for checking color contrast

Finally, here are some resources you can use to either check the contrast of your site’s existing colors or to determine a good color scheme to use when designing your site.

The Color Contrast Spectrum Tester

The Color Contrast Spectrum Tester by Joe Dolson wil let you enter a color’s hex value, and then it will provide a selection of contrast colors that you can use to make sure you’re following the WCAG 1.0 or 2.0 guidelines.

Color Contrast Tester

If you want to simply test whether or not two colors are going to mesh well in regard to color contrast, this color contrast tester will let you do that. It asks for a foreground color and a background color, and tests to make sure they meet WCAG 1.0 or 2.0 color contrast success criteria.

What about color theory?

I think it’s important to note that, while accessibility is extremely important, it doesn’t mean that everything else goes out the window. For instance, if you’re a blind person trying to design a site, you need to make sure that your color scheme meets WCAG guidelines, and, if you or your client are aiming for a particular goal, like readability or sales or email subscribers, good design still matters. If you’re a sighted designer, good color contrast and general web accessibility doesn’t mean that what you create has to be ugly. You can still have functional, pleasing design while keeping it accessible and meeting your client’s goals.

Mika Epstein has a post on why you shouldn’t use copy protection to try to protect your content. This of course applies to websites. I think you should go read the post, but the short version is this: It doesn’t work.

If you look at the post, you’ll see some very easy ways to get around said protection: Developer tools. These are the tools developers will need to bring up if we’re going to help you fix problems with your site, especially when we’re answering questions in the WordPress support forums. By disabling right-clicking, (which is what copy protection relies on), it’s harder for us to open those tools. But it’s not impossible.

One of the other methods used in copy protection is disabling copy/paste capabilities. This breaks things for adaptive technology users in all kinds of ways, basically resulting in “We can’t read your content.” If we can’t read your content, we’re not going to visit your site. And we’re going to tell our friends about it. Who will also avoid your site, tell their friends, you get the picture.

Stealing content is not cool. We all pretty much agree on that, content thieves obviously excluded. But given that the standard methods of copy protection don’t work in the first place, people who create websites have a really good reason not to use it.

Nothing can replace the eyes of a skilled professional when it comes to web accessibility testing. This is because so much of determining a website’s accessibility is subjective enough that an automated tool cannot help you when it comes to making definitive judgments about whether disabled people who visit your site and interact with it can actually use it.

But before I tell you why automated web accessibility testing is bad in more detail, I want to tell you what it’s good at, because despite not being a complete solution, there are some aspects of accessibility testing they excel at.

Piles of Code

A good web accessibility audit involves an in-depth, manual look at all the generated source code that makes up a website. Doing this is the best way to find out if problems exist, where they are, why they’re occurring, and how to fix them once they’re found. Doing everything manually is great if the website I’m working on is small. But once websites started becoming larger, web accessibility professionals needed a way to quickly scan through thousands of lines of generated source code to get a basic idea of where things stood.

This is where automated tools come in. They help by providing a general layout of the accessibility landscape, and they provide a list of things which need further attention in a manual audit. When you’re staring at a page that contains hundreds or thousands of lines of JavaScript, HTML and CSS, (like, for example, the Yahoo homepage or the Facebook homepage), automated tools can be a great help. On large sites, there really is no other way to find all the errors than automating the task. This includes sites that are using a templating system, such as WordPress sites. When conquering these, you’ll need to use an automated tool that crawls the entire site to get the assessment done. When I began working on Utility Pro, running it through an automated tool was the first thing I did in order to find out what I needed to start work on first, and in what priority.

Some errors don’t need human inspection

One of the best examples of errors that an automated tool can save time on is images without alternative text. In cases where there is no alternative text, an automated tool is used to document every occurrence, instead of an auditor manually going through and finding each one. But in cases where images have alternative text, and it’s not meaningful, a manual audit will find these and suggest meaningful text.

An automated tool lays the groundwork for a manual audit

The most appropriate way to use an automated web accessibility tool is not to generate a comprehensive list of pass or fail judgments on the site being tested, but to give an auditor a list of things that need a closer look. A good tool will provide a list of errors with line numbers and snippets of code that’s causing them. This information helps an auditor decide whether the problem really is a problem, so they can then tell the client why it’s a problem and suggest ways to fix it. More importantly, it’s a good way to find patterns of errors, which then helps an auditor determine the best way to help the client integrate accessibility best practices into their workflow.

Automated web accessibility tools can also help find exceptions in an otherwise accessible site. I’ve created sites or added content which contained good markup, but since underlying tools may change what happens to that markup, I’ll run the site through an automated tool and sometimes find errors I hadn’t realized were introduced. So in short, automated tools are great for sanity checks, and make sure that a manual audit doesn’t miss the obvious.

And now, the bad

Most of the bad things that get mentioned about automated web accessibility testing are related to the subjective nature of accessibility. There are also numerous ways to make a site more useable for people with disabilities that an automated tool will never alert you to. Automated tools can offer false positive and false negative results, and they have a lot of trouble with dynamic features, which have become more and more prevalent on the web and are not going away any time soon.

Now for some statistics

While working with WordPress and the Genesis framework, I’ve found that automated tools give me about twenty percent accurate results when it comes to web accessibility best practices. Thirty percent of what the tool finds I can use as guideance for further manual review. That leaves fifty percent that is straight up manual review. That fifty percent includes everything related to forms, and, since automated tools can only test HTML and CSS, also includes JavaScript, AJAX, and any other client-side scripting.

Does this mean you shouldn’t use automated tools?

I don’t mean to suggest by any of the above that you should never use an automated tool. But the thing to keep in mind is that an automated tool is just that, a tool. It can help with productivity, and helps with the accuracy of the final report. They also help with getting started with the basics of accessibility and can help developers and designers begin learning about it. But when using automated tools, in order to get the most milage, you’ll need to be well-trained in accessibility, understand how to read their results, and remember that what that tools tells you is not the final say in determining whether your site is accessible.

One thing that often comes up when performing an accessibility audit of a website, is the lack of the alt attribute when it comes to images. Fortunately, this is something that can be easily fixed, and you can start adding it to your images right now and see an immediate improvement in the accessibility of your site. In this tutorial, I’m going to explain what the alt attribute is, how and why to use it, and how you can do so using WordPress.

What is the alt attribute?

The alt attribute is part of the HTML tag which is used to insert images into web pages. Alt is short for alternative, and it defines text that is displayed as an alternative in case an image doesn’t display correctly in a browser. It also gives search engines and screen readers an idea of what the image contains. For screen reader users, it means the difference between “graphic img1000000000” or something similar and “graphic man holding a football” or other similar descriptive text.

What kinds of images need alt attributes?

You may be thinking that if there’s an image, it needs an alt attribute. However, this is not always the case. For example, if an image is decorative, such as images used solely for creative effect, the alt attribute should be left blank, like this:

In the case of an image that’s used as a bullet, you can use this:
*

Two ways to add an alt attribute in WordPress

If you’re using WordPress, you have two options for adding the alt attribute to your non-decorative images. The first is to manually add it to the tag. If you’re using the text editor, and manually inserting your images, it looks like this:
brief description of your image
If you’re inserting media using WordPress’s built-in media library, this gets a little easier. When adding the details for your image, there is a field that allows you to enter an alt attribute. Adding some meangful text to this field will ensure that your alt attribute is added without much work.

What counts as meangful text and how long should the text be?

The final thing to keep in mind when you’re adding alt attributes to your images is to make sure the text is meangful. For instance, if you have an image of a woman standing at the check-in counter at an airport, instead of labeling that image “woman,” try labeling that image something like “woman standing at airport check-in counter.” Also, keep your descriptions brief. Don’t use any more than fifty characters. If you need to add a longer description, in WordPress you can add this longer description to the caption field. There’s also a caption attribute you can use if you’re adding it by hand.

The alt attribute is an easy way to increase the accessibility of your website and content, and it’s also an easy way to help the search engines and other people get a better idea of what you’re saying with your images. If you’re going to use images as part of your content, (and you should), make sure that everyone can enjoy them. After all, you’ve spent a lot of time either finding those images or creating them yourself. With an alt attribute for each one, you can ensure the widest possible reach for your work.