Month: July 2017

Accessibility and HTML5: Semantic Elements and More

A div for everything and everything is in its div… If you’ve been working on websites for a while, you’ve no doubt had a few that seem to be just div after div, where the div explosion serves to place or style each part of the page as needed. The problem is, a div by itself doesn’t tell the user (or, more to the point, the user agent) anything about what the div contains, and the styling is likely to be lost on someone using a screen reader. In HTML5, we have the semantic elements, which generally act like divs – they’re block elements that contain other elements – but also provide meaning; each tag describes what it contains, which allows a user agent (such as a screen reader) to handle it appropriately. We still use divs, when no semantic element is appropriate, but they should no longer be the first choice. The semantic elements include: <nav> encloses a navigation block; this will often contain a list of links, but not every list of links needs to belong to a nav. Screen readers may be able to go directly to the nav section or skip it if not needed. <main> is for the main content of the document; it should contain only content that is unique to that document, not content repeated across multiple pages. User agents will often...

Read More

Lack of accessibility: my experience

We’ve been talking about guidelines for making websites accessible in general, and how to make them screen reader accessible in particular. Now let’s get away from the how and look at the actual impact of this work. Here are a few times when I’ve been impacted by a lack of accessibility. Some years back, someone lent me an instructional video for West Coast Swing. The instructor was trying to explain how to dance in time with the music, and you were supposed to listen to the beat while he pointed up and down, which would have been great – except he also SAID “up” or “down” each time, so I couldn’t actually hear what he was trying to point out! When Netflix started doing streaming video, there weren’t any captions. Many people complained (including myself) and Netflix told us that they were in the process of adding them. A few years later, they added streaming captions…for the first five seasons of Lost. When listening to podcasts, it’s not unusual to have people sometimes speaking over music, which makes them harder to understand. When I’ve been to conferences, speakers often show video with no captions. In many cases, these aren’t even difficult things to fix. The dance instructor could have simply pointed rather than speaking, there’s no reason to have music on in the background when recording speech, and of...

Read More

Testing for accessibility: Web Content Accessibility Guidelines

What makes a website accessible? The answer, of course, is that a website is accessible if it is usable by all people, regardless of disability. When building a website, however, we need something a little more concrete; we need a way to test whether the website is accessible, without having to have people with a hundred different impairments actually testing it. That’s where the Web Content Accessibility Guidelines (WCAG) from W3C come in. Following the guidelines doesn’t guarantee that your website is usable for everyone, but it’s a good starting point for handling the most common accessibility issues. The guidelines help insure that all users can both access the content and navigate the website. How important is the WCAG standard? Many countries require that their government websites follow the WCAG standard (the US uses Section 508 guidelines, which are expected to require AA WSAG compliance, described below). Last month, a federal court ruled that having an inaccessible website is a violation of the Americans with Disabilities Act (ADA), and the Justice Department has successfully sued companies (including Carnival and Wells Fargo) over lack of accessibility (both physical and online). The ADA requires that places of public accommodation be accessible to the disabled, and websites which directly sell goods or services, or connect to physical locations which do, have been ruled to be places of public accommodation and thus subject to the...

Read More

When to say “I don’t know”

Many years ago, I taught middle school math. One day a student asked me a (non-math related) question that I didn’t know the answer to, so I told her that I didn’t know. She then got annoyed with me because apparently, teachers are supposed to know everything. I was reminded of this recently when seeing comments about hiring people because they weren’t afraid to admit in an interview that they didn’t know something. Apparently this is somewhat uncommon, which suggests that an awful lot of people are trying to BS their way through interviews. Of course, nobody wants to hear “I don’t know” to every question, but assuming that you’re qualified for the job you presumably can answer most of them. This applies to working as well; I’d much rather you tell me that you don’t know how to do the task you’re assigned than pretend you already know and get in over your head. So, here are some acceptable ways to say “I don’t know”: I’m about 80% confident that this is the answer, but I’d have to double check to be sure. I haven’t worked on that functionality, but Jim would know. Let me conference him in. I can’t give a firm deadline for when the project will be completed because we’re waiting on feedback from QA. I’ll follow up with them and see when they expect...

Read More

Making your site screen reader accessible

One of the things I’ve been working on lately is ensuring that our web apps are accessible, which primarily means that those with visual impairments can use them. Partially that means making sure to use high-contrast colors and large buttons, and partially it means the webpages work well with screen readers. Screen reader compatibility largely breaks down into the following: Is the entire page keyboard accessible; can the user access all functionality and information without using the mouse? Does the screen reader tell the user everything he needs to know about what’s going on on the page? Does the screen reader avoid throwing gibberish at the user?   Is the page keyboard accessible? Can all of the page functionality  be used without a mouse? This means more than just being able to tab to all fields (although that’s the obvious first step). Other things to consider: Is there any information that’s only available when hovering over an area of the screen? Unless this is a field that can be tabbed to (in which case a screen reader will read the tooltip), that information may not be available to keyboard users (or mobile users). If there is a popup window, does focus return to the main page when the popup is closed? Similarly, when clicking a button, does focus go away? If focus is lost, a keyboard user is stuck. Will...

Read More