Author: William

That Conference Follow-Up

We’ve finished another That Conference! This was my third year attending, but my first time as a speaker. As much as I love the name (I’m going to That Conference next week. Which conference? That conference!) and the location (who doesn’t want to spend the better part of a week at a water park?), as much as I love the opportunity to spend three days focused on learning…I think what I get most out of That Conference is an opportunity to recharge. To recover from burnout. To get excited about programming again. One thing I’ve struggled with is the “hallway track”; I know that many people go to conferences specifically to talk to other developers (often at the cost of even going to the talks!) – That Conference even schedules a half hour break after each session to allow for this – but as someone with a severe hearing loss (and an introvert) I have a very difficult time inserting myself into conversations. This year was easier for two reasons: I met an online friend in person for the first time, and giving a talk provided a ready conversation topic, so I was able to have much more in the way of meaningful interactions than I have in years past. I’ve uploaded the slides for my accessibility talk; there are a lot of extra details in the presenter notes that...

Read More

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