Over a million developers have joined DZone.

An Interview with Jeremy Sydik - Designing Accessible Websites

· Web Dev Zone

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

I recently finished reviewing Design Accessible Websites by author Jeremy Sydik and as I was reading the last couple of pages I thought to myself, "I have to get an interview with this guy". The book covers such a wide variety of topics and I had some burning questions I knew would be best answered by the man himself.

I contacted Jeremy and sure enough he was glad to do the interview. Below is a transcript of that interview. Enjoy!

Tell us a little more about yourself and the work you do at the Nebraska-Lincoln's Centre for Instructional Innovation.

My role at CII touches on a wide variety of areas. Part of our work includes the Building Accepting Campus Communities project, which exists to assist disabled students in their transition to university academic life. Specifically, I've done work on a tool called Accommodation Solutions Online, which is a system to match students to services, techniques, and technologies to fit their individual accommodation needs.

Another part of our work is in developing theories, techniques, and tools to educate learners, particularly through the use of technology. I split my time on this front between developing the technology for our ThinkAboutIt system for teaching critical thinking, which we have recently been using in collaboration with the Penn State Medical Centre to train medical students to give better presentations. On the educational psychology front, we have also been working to help develop online educational content for teaching teachers as part of a project we're doing with the people at Pearson Education.

At the core, I'm most interested in the dynamics of how we communicate with computers, how we communicate with each other through computers, and how this interface can be improved for the users of systems.

The obvious next question is that which makes up the basic underlying message of the entire book, Why be accessible?

I'd like to believe that my underlying message is actually how to think accessibly. I give some reasons to be accessible early on in the book though. First up, in many parts of the world there already is or there will soon be a legal mandate, this is not the most positive way to approach accessibility, but it's certainly a very real issue.

More positively, accessible content is smart business, it just doesn't make any sense at all to say, "Oh, there's a large group of potential customers, but it might take some work, so we'll just ignore them", not if you LIKE to be in business at any rate. We also see the web landscape beginning to shift again to include browsers that are part of consumer electronic and mobile devices. The principles of accessible development also help us keep our options open on this front as well.

Most importantly, when we write content, it’s about communicating with people... this makes accessibility the right thing to do, we want to reach anyone who wants to listen, and it just doesn't make sense not to.

From the ten principles mentioned in the book I would like to touch on two points, the first being 'Avoid making assumptions about the physical, mental and sensory abilities of your users whenever possible'. Would you like to expand on that a little?

It is really the fundamental principle of accessible design. There are so many different types of people out there using so many different kinds of hardware and software that there really is very little we know about the visitors to our site. As web developers, we often think about parts of the software and hardware side of this in terms of browser variants and plug-in supported media types. That's not UNIMPORTANT per se, but we're not writing our content for software and hardware, we're writing it for PEOPLE, so it's essential that we look at the variation of their needs even before we start talking about their technologies.

The other point I wish to touch on is 'Design your content for semantic meaning, and maintain separation between content and presentation'. Can you clarify for us what, from your point of view, it means to design content for semantic meaning.

There are really two parts of this, one from the user side and one from the developer side. From the perspective of taking care of our guests, staying semantic is all about not using elements in an unexpected way, this means avoiding tables for layout, block quotes to create indentation, and so forth. From the development standpoint, it means designing your CSS classes for meaning, instead of calling that div "pinkblock42", call it "calendar-of-events". This serves two purposes.

First, it keeps you from thinking TOO visually when you design your markup (this takes effort, it's not instinctive for sighted developers to think in terms of not having sight, it'll take practice) second, and this is a side-effect benefit of accessibility, it makes your content more maintainable. When the customer decides their new favorite color is puce instead of pink, you don't expose your self to "dead name creep".

You touch on a point that I very strongly agree with in the book, 'It's their web - We're just building in it'. What is one common area where developers make the mistake of taking over and try to force a user into doing things their way.

I think it's probably more often the rule than we realize. Some of the things that jump to mind are unexpected pop-ups, awkwardly short timeouts, captchas, assumptions about software availability for PDF, Flash, Word Ddocuments or something else. These are all forms of pushing the user into acting to your expectations.

That doesn't mean we can't do any these things, but we need to consider what's a realistic expectation for our audience and what we can do without or provide in an alternative form. At the end of the day, we're really talking about a specific part of usability.

In general, most of the common web design patterns we see are ad-hoc "it worked for me" solutions. I think we really need to reconsider this and start looking at the formal usability of our designs in order to provide better experiences for ALL of our users, including those who need specific accessibility features.

A big issue for me is to convince people, especially in large companies, to take the whole notion of usability, accessibility and standards seriously. Can you provide some suggestions as to how one can or should approach these situations to start changing this mindset?

In large companies, you'll usually need to, in one way or another, chase down the bottom line. Obviously, one approach is to make it clear how accessibility opens your company to a wider consumer base that has the potential of increasing profitability. The dark flip side of this is to open concern about the legal implications of NOT being accessible and the value of not giving all of your profits to legal counsel.

There's yet another side to all though. I speak about a story in my chapter on photosensitivity about seizures caused by the early advertising for the London Olympics. At that point, London Mayor Ken Livingstone had a couple of harsh comments:

If you employ someone to design a logo for you and they haven't done a basic health check, you have to ask what they do for their money Who would go into a firm like that again and ask them to do that work. This is a pretty basic thing

Now... who wants their company to get THAT kind of PR on the world stage? Me personally, I'd rather try to be known as the kind of developer that tries their hardest to be welcoming to my guests and considerate of their needs.

Can you expand a bit on the topic of not getting WET? What are common areas where developers run into these problems and what suggestions can you offer on how to overcome this challenge when trying to create multiple access paths to the same content?

The "WET Dilemma", Writing Everything Twice, is a nod to Dave Thomas and Andy Hunt's "DRY Principle", Don't Repeat Yourself, from the Pragmatic Programmer. There's no way to COMPLETELY avoid repetition when you create multiple access paths, there's obviously a little bit of repetition in producing a video AND the captions that go with it.

What I'm specifically addressing is the old practice (and I shouldn't say old because I've seen it already at least once in 2008) of maintaining two "separate but equal" web sites, the "primary" site and the "accessible one". All right, here's the problem: First of all, this means maintaining two sites in parallel, this doesn't really happen for long. Sure the new content MIGHT get produced for both sites but updates and revisions commonly do NOT. Second, this comes back to the user as guest, what message are you sending by telling your users with accessibility needs that they need to use this other "good enough" version of their site?

You talk about what is happening in the rest of the world with regards to the implementation of accessible guidelines and the fact that some countries are adopting these as enforceable laws. What is your take on making accessibility a requirement by law?

I'll admit I have mixed feelings about "accessibility as law". Ideally, I’d like to believe that developers will come around to accessibility because it IS the right thing to do and because it DOES make good business sense. In reality, though, that's unlikely. It's not the "sexiest" part of web development so it's never going to have the natural draw that other aspects of development do. It's going to take the more subtle aspects to win them over and, at the end of the day, like all civil rights issues (and accessibility IS a civil rights issue) a legal nudge is often needed to get things moving in the right direction.

Lastly, how do you see the future of the web and accessibility in particular? What are your hopes?

It sounds a little cynical, but I expect the future of the web and accessibility to be much like the past has been. In general, we see a series of waves where the web evolves and the accessibility follows. The two have never really gone hand in hand and I don't expect to see this to change much. The one factor here may be the demographics of our visitors.

For certain in the U.S., we have an aging population and with an aging population come certain accessibility needs. As this happens, we may see the consumer demand drive inclusion of accessibility concerns embedded in technology development for the web. Ultimately, I hope I'm wrong about this and that accessibility becomes a more present concern among developers, but I think this will take some time, as I said earlier, often usability isn't even the focal point that it should be yet.

Any final words you want to leave us with?

I usually leave with the same words. Have fun! A lot of people get beaten down by the accessibility issue and terrified of making mistakes. I'll say I've never heard of everything falling apart over accessibility because someone made an honest mistake. When something honestly goes wrong, you fix it, you apologize and you learn and move on.

The important thing is to remember that we work in a fantastic field and get to play with terrific technologies. Keep playing with them and creating great things. Just remember to bring everyone you can along for the ride.

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.

Topics:

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}