Now there really isn't just one thing that he does - in addition to training, delivering seminars and writing, he runs his own web development company, spends a lot of time as a web accessibilty consultant, and writes at his blog. And that's all between spending time with his family. He's a father of three, and husband to one...
Derek: Substantiated fact, actually. After university I taught high school science and computers for 4 years. For a number of reasons I decided it was time for some changes. I put my background in education to use right away with a number of freelance training contracts in desktop applications and then web development courses. Doing that training lead to more contacts that wanted me to develop for them instead of just teach them.
Derek: The short answer is "whatever my clients need me to do that is accessibility related."
The long answer is that my time is divided unequally between training developers, managers, content creators in accessibility, performing various size accessibility audits and assessments of web sites and applications, strategy and process work, and finally, hands-on work retro-fitting and building web sites and applications.
Derek: When I was still teaching high school I spent quite a bit of time buildling online resources for my students. I found it ridiculously frustrating that things that I was doing in one browser wouldn't work in another - this was 1997-98 and I was upset at IE for being so forgiving and Netscape 3.04 Gold for being so strict. These were the days when Netscape would not display your page if you had a missing </td>. That lead me to validation, which lead to web standards in general (though it wasn't called web standards back then). Working with students of all abilities got me interested in multiple intelligence theory and I was intrigued at how that might apply to learning resources on the web and how I could create materials that would help everyone. Accessibility followed naturally from that.
Derek: Absolutely - it is the foundation of web standards and the base upon which accessibility is built. Simple things like using headings and lists where appropriate can contribute significantly to making the web better for all users.
Derek: It isn't so much tabindex that I don't like, it's just that in most cases it simply isn't needed. What we see happen often is the implementation of "rules" that someone has seen somewhere without considering context. It is funny because the checkpoint that actually refers to tabindex essentially says "specify tab order via the "tabindex" attribute or ensure a logical page design". Often people seem to forget about the logical tab order that almost always exists and is reasonable. In fact, I'd say you have to work pretty hard to actually need to go outside the logical order that naturally exists within standards-based sites. Further, when people do implement tabindex, often it breaks expected interaction because the order is either non-intuitive or it is completely out of line with where you think you are headed next.
That's right - go check your blog or your contact forms right now. Try to use your own comment form using only the keyboard. See how upset and frustrated you get when you are in the comment area and you hit tab to go to the preview or submit button and all of a sudden you are back at the top of the page. If you are going to use it, use it correctly. Not using tabindex is better than using one that breaks expected interactions for people.
Derek: I don't use them, actually. I've got very little in the way of navigation on most sites that I build, so I've honestly just not bothered.
If you are going to use skip links, then I generally recommend that skip links (like all other links) should clearly identify their target. Which of the following more clearly defines the target: "skip navigation" or "skip to main content"? Plus there are the reports that "skip to content" is read by many screen readers with the emphasis on the second syllable, so it sounds like a link phrase meaning "skip to happy"
Derek: You could also use (in CSS terms) a different font-weight, or a different border-bottom style, or you might try something adventurous and creative like Colly's Ticked Off Links. Incidentally I didn't like that technique for links in the body of the page at first, but I found it very easy to get used to and much less obtrusive than you might think. Mike Davidson uses it in the body of his blog posts and it works much better than I thought it would.
I'm all for other ways of noting the difference, and hopefully as time goes on someone else will come up with creative ways of solving that problem. I'm sure someone is working on an extension or add-on for a browser right now that will help.
Derek: Unfortunately <link> relationships aren't used by very many people. We talk about semantics when it comes to marking up information within our documents but we often fall short when it comes to marking up information about our documents and how they relate to other documents. Add to that new link relationships (a la XFN courtesy of Eric Meyer, Matt Mullenweg and Tantek Celik) and you have some pretty powerful ways of expressing relationships.
Here's some thoughts on how I'd love to see it used:
I guess I just see it as potentially the most useful element we have at our disposal in terms of establishing relationships between one thing on the web and another. It could do so much more for us than associating our stylesheets with our documents.
Derek: To some degree. Many of the things we do in the name of accessibility are based on mythology. We make some fairly standard assumptions when doing accessibility work, and many of them may be unfounded.
That sounds harsh, but let me explain with a quick example. Consider a simple technique like adding title attributes to links. Despite the fact that we may use the attribute correctly, the effectiveness of doing so is unknown. Yet we take it for granted that it helps.
We don't have a clue how many screen reader users have their software configured to read the title attribute in the first place. It is quite possible that a title attribute could be read in place of or in addition to the link text. Or it might not be read at all. Without at least some research, we'll never know. While the onus is also on the user to know how their software works, things like enabling title attributes to be read is a very minute detail. I suspect that most people using screen readers can do some customization of their settings, but it may be that configuring title attributes to be read just isn't done. Again, we simply don't know, and it would be useful to find out.
The limited research that does exist isn't always helpful to developers. Most people are becoming more aware of web accessibility. There are many developers out there that want to do the right thing, but they don't necessarily know how. Because there are technical details that impact on accessibility, we need to see more from research studies than just screen shots. As developers, we need to be able to look at the actual pages that were used, or relevant code at a minimum so that we have a better understanding of what solutions have been tried, and how we might improve the accessibility of web sites and applications.
We are all making educated guesses right now -- I just think we need more data that we can use to make more informed decisions about the techniques we use. We all know there is more to accessibility than just considering people that are blind or visually impaired using screen readers, but take a look at the title attributes in screen readers example again.
What if we found that 60% of screen reader users aren't configured to read the title attribute, and that the 40% that are configured to read title attributes have it setup such that the title attribute is read out in place of the link text? Would that change the way you used the title attribute on links? And how (if at all) would that change over time? These are all questions that need to be asked and at least partially answered.
Copyright © Web Standards Group 2012