By James Edwards

The Art of Accessibility

By James Edwards

Some designers and developers object to having to cater for accessibility. The argument I’ve heard most often is that the demands of accessibility are too restrictive, limit creativity, or undermine design aesthetics. In other words, accessibility limits artistic freedom, and that’s unacceptable.

I could try to refute that on the grounds of practical ethics — the aesthetic preferences of one are simply not important, when stacked up against the functional needs of another.

But there’s another way of looking at it, less likely to be seen as an accusation, and perhaps more strongly resonant with the nature of the creative mind; and it’s this — a restriction is also an inspiration; an issue is an idea.

Playing psychological tricks on ourselves

It’s said that necessity is the mother of invention — you never really look for something until you need it. If we think of accessibility requirements in terms of the need for invention, then each of us as developers have the chance to be the mother! The requirement of accessible web-development is to build the sites and apps we want, without creating [needless] barriers to particular groups of users. And this doesn’t have to be a problem to frustrate us, when it can be an opportunity to elevate us.

Child psychologists are often great proponents of reverse-psychology. If the child is bored because they can’t think of anything they want to do, then give them something they don’t want to do, that’s tedious and un-enjoyable. You can bet it won’t be long before they think of something more fun!

We’re all children at heart, and we can use psychological tricks on ourselves to deal with creative barriers. If a requirement of accessibility says you can’t implement feature x because of conflict y, let your child-mind complain, oh, but I really wanted feature x!. Then your rational-mind can jump-in and say, okay. so how can we do that without causing conflict y?.

An easier way to deal with that would just be to shrug and forget it, like oh well, we just can’t have feature x, or maybe, conflict y will just have to hang (after all it only affects a minority, and everyone knows, minorities don’t matter!). Bad developers are always telling their clients what they can’t have. Good developers are looking for ways to make things happen anyway. View accessibility the way an artist views the nature of their medium; after all, what is art, but the resolution of a challenge?

Would Michelangelo’s David be regarded as such a masterpiece, were it not so rare and difficult to produce a work like that? Would Isambard Kingdom Brunel still be held in such historical esteem, had he not produced so many innovative solutions to the engineering challenges of his day?

Nothing worth doing is easy.

A parable of headings

Many years ago, when I was developing a commercial drop-down menu script, I wanted to make it easier and less confusing for screenreader users to navigate internally within the menu-content list. A large, complex and multi-nested list of links can be quite slow and disorientating to use in such devices, when there are so many links, and the device gives little or nothing in the way of inner structural cues (eg. most give no information about the nesting of lists, when they start or end).

The solution I eventually came up was to use internal sub-headings, for example an <h3> wrapped around each of the top-level links. Most serial-devices have a “headings list” or “headings-reading mode”, which allows the user to jump around the page using the headings as targets. So lacing the list with headings provided a degree of random-access, to each of the main branches in the menu tree, via this mode of navigation. And it did so in a way that was appropriate and semantically correct.

Later, I developed this technique into the more general use of headings as an aid to navigation for screenreaders, text-browsers and other serial devices. By lacing a page with headings that describe and preface sections of content, users are able to find their way quickly to sub-sections of any page. I referred to them as meta-headings, but they’re now more commonly known as structural labels.

You can see them being used right here on this page. If you disable CSS, you’ll see how primary sections of content — such as the site navigation, search box and footer-links — are preceded by structural headings that describe their function or content; together they describe the overall content-hierarchy of the page (which you can see in Opera using View->Style->Table of Contents). They allow the user to jump instantly from one section to another; it’s easy to see how useful that would be in a linear-access device (like looking for clips on a DVD rather than a video-tape). But the random-access mechanism itself already exists in the technology, we’re just playing to that, by providing it with data.

The point is…

As useful a technique as this is, it’s not the real point I wanted to make. The point is, it stemmed from a mind-state which viewed accessibility as a challenge, not a burden. If I’d simply shrugged at the original issue, and just said well that’s as good as it gets, then I’d have never found that solution, and never have developed it into such a simple and invaluable way to improve accessible in-page navigation. (Not that I’m the only person to have thought of it; but the point is there nonetheless!)

History is replete with examples of problems giving rise to inspired solutions, some so useful that they far transcend their address of the original problem. Technologies and materials designed for the space-program are now found in countless domestic products (like smoke-alarms, drinks-containers and toothpaste). What was once intended to provide post-apocalyptic military intelligence went on to revolutionise how the whole world does business (you know that one!). And perhaps most poignantly, a system originally designed for soldiers to communicate covertly at night, was developed into a writing system that millions of people who are blind rely on (braille).

If life has taught me anything, it’s that problems are always easier to solve when approached with a positive attitude.

And if all I can do by writing like this is to help spread an attitude of enthusiasm and pride, then I consider that a job well done. It seems like people don’t talk about web accessibility as much as they did a few years ago. Certainly, I’ve stopped thinking of it as such a major deal, but that doesn’t mean it’s solved, or gone away. It’s just become another ‘thing we do’ — just another part of what it means to be a professional web developer.

  • Iza Bartosiewicz

    Well put, James. Your article reminded me of what Chris Heilmann said in an interview a couple of years ago:

    Developers think, I can’t use the cool, new technologies because they’re not accessible, rather than looking at these technologies and making them accessible. So it’s like people don’t see an accessible interface as an opportunity to make a cooler interface, but as something that is dumbing down what you really want to do.

    From Designing accessible websites

    • Iza Bartosiewicz

      I don’t know how the above comment got separated from my first post and how it appeared without the quote marks and the appropriate attribution. It comes from an interview with Chris Heilmann

      Sorry Chris, it wasn’t my intention to make it look like I said it! :-(

  • mattymcg

    Great stuff James, and a bit of a history lesson thrown in for good measure. I wish I had the middle name of Kingdom. :)

  • lol, I’ve always kinda wished my middle name was “Danger” — cos then I could really say “danger is my middle name” :D

  • Matthew Fedak

    I am a php web developer but like html too and always try and make sure I use headings correctly. If you install web developer tool bar for Firefox there is a blue information icon which underneath has a list of options. The one you need to look for is “view document outline”. It opens a new browser tab and shows H tags on that page. If there is a necessary gap or jump between one level of H tag to the next it inserts the missing tags in red as a “missing heading”. Using this method on my site for example you will see there are no missing headings but on this wikipedia page there are some missing h4 and h5 headings.

    • mongrel13

      Excellent tip! Thanks.

  • Carlton Barnette

    Great reminder of what we’re all here to do! Design and development are not about us, and often times not even about the client, but about the people who will be using and interacting with the site. I think many of us forget that, and the reason why is understandable. I think some of us think of ourselves as freestyle artists when we really should be thinking of ourselves as creative engineers. We’re here to solve problems for the client, but in a creative way. The solving of the problems should always come first, with the creativity being the icing on the cake.

    I think the other problem is the way a lot of designers and developers are taught their craft. My partner and I have purchased and taken quite a few courses here on Sitepoint, and one of the things your courses seem to constantly remind us of is designing for optimum functionality. Your teaching styles all seem to marry the two, or you don’t let us dwell on how cool something looks without beating the accessibility challenges into our heads. That’s a good thing, and something we greatly appreciate!

    But I think some designers and developers have been taught from a different point of view where accessibility was not expressed as being particularly important. In that case, the cycle is likely to go on and on unless it is broken by teachers who know that creativity is only one part of a bigger picture.

    Anyhow, this is a great and a great reminder of what my job is really meant to be. If I tell a client no, it will be because their wants aren’t practical from a functionality perspective, not because of how I did or didn’t “envision” the goal. And I’ll strive to come at such challenges from a new perspective. After all, doing so only makes the Web better and better for all of us!

  • Michael Spellacy

    Well said, James and a great reminder to all. I’d also like to add that being mindful of accessibility is simply the right thing to do. Would an architect even consider designing a building without accommodations for handicapped individuals? Nope. The same goes for the web. Maybe even more so. Thanks again!

  • Laura

    Great article. There’s a nifty toolbar for Firefox for accessible coding called WAVE: . It’s very handy for evaluating a web page’s accessibility.

  • Ralph ERMISCH

    Dear James,

    I am not a web developper or designer, but I always learn a lot from your and other articles published in SidePoint.

    Thanks a lot for this interesting article.


  • Dave C

    I used the same technique for structuring my content and thought I’d done something cool. Then I read
    “There are occasional instances where content should be made available to screen reader users, but hidden from sighted users.”

    “In general, content should only be hidden from sighted users and made available to screen reader users when content is apparent visually, but not apparent to screen reader users.”

    “This should be implemented with discretion and only where necessary.”
    “occasional instances”, gave me the impression I’d done something wrong.

    • Those are good general guidelines, sure, but they’re not the whole story.

      “In general, content should only be hidden from sighted users and made available to screen reader users when content is apparent visually, but not apparent to screen reader users.”

      And that’s exactly what we have here. You don’t need a heading that says “site navigation” before the top navigation bar on this page, do you? It’s totally apparent to you that’s the site navigation, just from looking at it. But in a screen reader environment — or for that matter, in a text browser — there are no such visual cues, it’s just a list of links.

      The heading provides orientation information to help identify its purpose, as well as providing the random access via its headings-mode that’s the main point of it. Both these things are valuable to screen reader users, but of not value at all to sighted users, who already have those cues and random access.

      I guess I’d extend that guideline, to say, not just “content” in a literal sense, but “information” in a general sense. Some kinds of content are tautological when placed in context — that’s why images which are immediately followed or preceded by a caption should have null (empty) alt text, because what you’d put in the alt would be what the caption says.

      • Dave C

        “There are occasional instances where content should be made available to screen reader users, but hidden from sighted users.”

        I already have a million and one things to know as a web developer. I work on my own and the kind of clients I have wouldn’t know or probably care about accessibility. But I try and do the right thing.

        That’s difficult when Accessibility can’t seem to make it’s mind up. I’m all up for a technical challenge, but any time I think of feature I seem to see an accessibility guideline that says “No, you can’t do that”. This is a good example.

        “occasional instances”. So these guidelines aren’t quite right, okay. If/when someone else tells me that screen reader-only headings are wrong, at least I’ll have this to refer back to.

        We’re supposed be doing navigation skip links right? No, looks like it’s now been decided that’s wrong. Text enlargement widgets? No, seems that’s wrong now too.

        My theory is that Accessibility is actually a secret society who’s stated aim is to help humanity but who’s real aim to frustrate people who don’t have unlimited time.

        However I agree a positive attitude is good, so I shall continue to try.

      • Mate, it’s not a secret society, it’s a loose affiliation of developers and users trying to arrive at best practice. Advice changes over time, because we learn over time what works and what doesn’t.

  • Sharron Rush

    What a great attitude, thanks! Over here at Knowbility, we’re with you all the way. That’s what our Accessibility Internet Rally (AIR) is all about! For more than 10 years now, we invite teams of designers to learn about accessibility and beauty. Once trained they compete by making the coolest snappiest most highly interactive sites possible (for nonprofit groups no less) – and oh yeh, the winner is the coolest, most ACCESSIBLE one. It’s a blast and AIR winners have gone to work for Google, Apple, frog design and such – accessible design is good design!

  • AnilG

    What if it’s not a choice between the aesthetic preferences of one and the functional needs of another, but it’s actually a question of the functional needs of the majority against the functional needs of a few, and not because we can’t meet both, but because of resource constraints?

    I don’t see how it can be cost/effective to spend hours working through accessibility implementation when resourcing is so constrained as it is. Web dev in general always seems to take longer than the business is willing to understand.

    I can’t afford to spend my spare time (I don’t have any) working on additional accessibility features that aren’t even in the requirements list and I don’t see how the business can be expected to fund features for an audience they don’t even know if they have.

    Your parable seems to demonstrate this quite well, too. How long did it take you to work through the challenge you set yourself? And who paid for that time? And did they know they were paying for it?

    • mongrel13

      I would like to mention one other thing: federal law mandates accessibility. A little practice with these tips should make them more automatic and taken for granted. Further, anything that makes any site more accessible for everyone is not just the usual association with PC; I like to think of it as Plain Courtesy.
      By the way, the post was excellent and makes me pleased to be part of such a thoughtful community of designers and developers.

    • John Faulds

      The large majority of accessibility enhancements aren’t time intensive, it’s just a question of modifying what you already do a bit, adding a heading here, an attribute there etc.

      It might take time to learn all the little things you can do, but it’s just like anything else in web development: you don’t stop learning, and you don’t have to learn it all at once. It can be something that you learn a little bit more about as you go along.

      Once you know the techniques, they just become part of your normal workflow and take no longer to do than any other task.

    • Iza Bartosiewicz

      … working on additional accessibility features that aren’t even in the requirements list…

      AnilG, I understand your concerns, but if you are developing websites for human beings, accessibility is not, and should never be considered, ‘an additional feature’.
      Professional web developers have to deal with project constraints, but they should make an effort to enlighten their clients about the benefits of accessible design. There are many articles on this subject with examples that go beyond the obvious benefits for people with disabilities (e.g. accessible sites are more mobile-friendly). And the most sensible (and cost-effective) way to achieve accessibility is to include it as part of the development, making it a requirement not a feature.
      Some businesses may not even be aware that they might miss out on potential customers and risk getting sued if they continue treating accessibility as an add-on.
      However, it’s sad that, when it comes to accessibility, it is easier to find information about businesses that got sued, than about those that enjoyed a considerable return on investment. I’m familiar with only one case where a company achieved ROI of 100% in under 5 months. We need more good-news stories like that!
      Besides, accessibility shouldn’t be treated differently to security or privacy requirements. Which business would be willing to skip these because they cost too much money and the chance of someone hacking into their systems is reasonably small?

    • There are several points to pick up on here.

      Firstly, there’s no such thing as “accessibility features”, there is accessibility, and there are features; but accessibility is not a feature, any more than usability, design or database architecture are features; they’re core requirements, plain and simple.

      How long did it take me to work through that challenge? And who paid for that time — well in that particular example, I paid for the time. I spent my own development time in making a better product, which in turn yielded better sales. You wanna hear return on investment? Because I took the time to make that menu accessible, instead of the same old DHTML crap that every else was doing, I came up with a product that made me 1/4 million dollars over the following 5 years.

      But more generally, do my clients know that they’re paying for me to spend hours improving accessibility when I could just let it go hang and save them money and time? Yes, absolutely they do, and that’s why they come to me; because I produce better results.

      Professional services cost money. You can spend a couple of grand and get me to build some proper, accessible templates for your new site; or you could spend a tenth of that and get generated front-page templates.

      And web dev, in my experience, does not take longer than the business is willing to understand. In my experience, delays in projects are usually caused by the client’s tardiness in approving designs or providing content. I can’t claim to be perfect — I’ve had projects run over time, and budgets come in too high, sure; but for the most part, I have a history of clients who are delighted that I went the extra mile to produce proper quality content, and amazed that I was able to turn it around so quickly.

      There never ever comes a time when you say “well I’ve run out of time so I can’t make this site accessible”, because I don’t build sites that way. Accessibility comes in right from the start, right from the baseline, and generally doesn’t take much more time or much more effort to get right. It’s all just simple things.

      • AnilG

        I appreciate everybody’s replies. I wish I could have a quick start tutorial on all the ‘quick’ and ‘easy’ accessibility practices that I can put in ‘right from the start’ and as a change and increase in my awareness of the way I build web pages. The next SitePoint tutorial? There is one already?

        I’m not opposed to accessibility and I’m sure more of us would love to know how to use accessibilty to generate a quarter of a million dollars but I’m flat out over here running a job and family. Fitting in extra code to make IE work is about all I can manage.

        One thing. I can understand what you’re trying to say when you say accessibility is not a feature, but you can’t say it’s a requirement if the business just doesn’t respond when I ask how many extra days do they want me to spend to make the site work for blind people? I can’t even float that idea without affecting my credibility in the meetings I’m used to experiencing.

        Maybe you can make all your web sites fully accessible with no extra time investment but I can’t, and your article indicates that you certainly haven’t in the past either.

      • Sphamandla

        Thanks for the valid pointing out those points

      • That’s very frank of you, and I appreciate it very much. I think I’m pretty good at what I do, but it’s taken years to get to this point, and a great deal of time and hard work. I haven’t had a family to look after, or any real responsibilities, so I’ve had the freedom to throw myself into work and training that a lot of people just don’t have.

        But there is such a tutorial, that can give you a grounding in quick and easy things you can do to make your sites more accessible. It’s called Dive Into Accessibility:

        You could also try Joe Clark’s book “Building Accessible Websites” — it’s a little out of date now, but still has lots of useful relevant stuff in it.

        At the end of the day, I’m not one of those puritanical developers who say that you have to get everything 100% accessible or else you’re not doing it right; I don’t believe that. There are always constraints, always compromises, and sometimes you do have to favour the majority and let a few details fly, just to get the thing out of the door. I guess when I write about accessibility I try to frame it in terms of ideals — this is the best we can aim for — and aiming for it is important, even if we don’t always achieve it. (and 100% accessibility is impossible anyway!)

      • AnilG

        Yes, thanks, James. I do find the ‘holier than thou’ approach to accessibility hinders communication. It’s difficult to discuss the cost / benefit of introducing accessibility when I feel that just asking the question would elicit outrage and censure.

        Thank you for the link. Funnily enough when I followed it I found I had already bookmarked it, but clearly never had the time to actually read the material. Hopefully after this conversation I’ll be more likely to find some time for it.

        I must say just trying to summarise the facts that I’ve learnt from your article here it sounds like getting up to speed with accessibility takes “years of hard work” but I still can’t see where a clear case for the benefits has been argued. It sounds like you’ve done this out of personal motivation and returns have been purely serendipitous.

        To try to offer something in its favour it occurs to me that an accessible website is more likely to degrade gracefully when browser features or JavaScript are not available.

        Thanks for your effort and the references.

  • Luis Cunha

    Some time ago, i attended two weekend classes on web acessibility. I feel its great to do acessibile websites, but the truth is, most developers with a deadline don´t bother to make acessible sites. Here in Brazil Federal Govt enforces federal institutions to follow electronic govt procedures, but there are still a great number of websites with low acessibility.
    Sure, its not easy do achieve this goal, there is a number of details to watch out, from element semantics to acessibility on tables.

    Good post, would like to see more abut this topic !

  • Chris Kourou

    Really nice post.
    Positive attitude is the key.
    Looking accessibility from another point, you can also see the benefits for non-disabled users. TTS technology is today used for dialog interfaces in phone banking systems for example. Isn’t that a technology originally developed with blind users in mind? Didn’t we benefit from it?

    Not to mention that there are situations, under certain circumstances, that we use (or at least we would like to use) devices as a disabled user. For example using your mobile while driving (I know it’s illegal) or doing something else that requires your atteniton is like a blind person using it. So why not provide accessible solutions for them? We could use them too!

    There are plenty of examples out there with technologies originally designed for disabled users that transformed to benefit everyone.

  • Kathy

    Does everyone know the Oxo story?
    From wikipedia:
    OXO was founded by Sam Farber, an entrepreneur in the housewares industry. Noticing that his wife Betsey was having difficulty gripping ordinary kitchen tools due to a slight case of arthritis in her hands, he saw an opportunity to create more comfortable cooking tools that would benefit all users. After years of research, the first group of 15 OXO Good Grips kitchen tools was introduced to the U.S. market in 1990.
    Me again:
    If you don’t do much in the kitchen, Oxo is now a high-end housewares supplier. A year ago I cut myself badly struggling to open a tin can. When my friends arrived for dinner, one suggested that I invest in an Oxo can-opener. It cost $15 but is a joy to use.

  • Flo Nelson

    Thanks for the great article. Easy to implement and looking at the page without the css, I can see how helpful it would be.

  • Dave C

    Yes, mate, Accessibility *is* a secret society, but it’s not one for
    which you need a funny handshake, instead you need the holier-than-thou mindset -noted elsewhere here; you need that “we’re on a path to save humanity and we’ve decided things have changed and what you’ve done is wrong”-type mindset. Accessibility has a good cause buried deep down but it doesn’t really do itself any favours when it’s quite patronising, and it often is.

  • Donna

    If the DOJ broadens the definition of the Americans with Disabilities Act to include websites, as all indications point to, accessibility won’t be something you can laugh off as the domain of elitists or snobs or “holier than thou” folks — it will be the law. So if you get your act together now and learn how to do it instead of sitting around insulting the people who know how, you could stand to make a lot of money when the law changes and every business who thought they could get away with shutting out people with disabilities is suddenly scrambling to comply.

    • Dave C

      Oddly, America isn’t the centre of the universe.

    • mathdizo

      Hello, that’s interesting – we have a similar law here in the UK, but it’s ill defined (because Accessibility largely boils down to opinion). So, in terms of legal-compliance, it basically amounts to some simple rules

      – your core site can’t be flash-only
      – your core site should work with JS turned off

      That’s really all they can legislate for. Any indications of where the DOJ ruling is likely to point, do you think it’ll be similar?

      • Sorry, but you’re mistaken.

        Accessibility does not “largely boil down to opinion” — there are many judgment calls involved, yes, and opinion is divided on many of the details. But the fundamental requirements of accessible web development are proscribed very clearly in the Web Content Accessibility Guidelines. Now at Version 2, WCAG defines in detail the kinds of accessibility barriers that are faced by different groups of users, and describes the principles and techniques required to overcome those barriers.

        In the UK, the requirement of “premises” to be accessible is legislated by the DDA – the Disability Discrimination Act 1995. The principles of legal-compliance are then described in BS 8878, which talks about what sites must do in order to comply with the law, and contains guidance for managers when commissioning applicable professional services.

  • Dan

    Thanks, enjoyed the article. In New Zealand only Government sites have to be accessible by law. This leaves an unmonitored wasteland where developers of commercial sites can decide to incorporate accessibility features, or not, depending on how conscientious they are, or not, and whether they or their stakeholders consider it necessary, or not.
    Personally I like to make sites accessible. Simple stuff like good semantics is standard development process these days, but I usually budget in a thick layer of overhead where complex interactivity is concerned, or where a stakeholder is suggesting an off-the-shelf component that probably hasn’t been written with accessibility in mind. This kind of accessible development is usually more time consuming because there are no hard and fast rules.
    Like other commenters I often hear lines like ‘this site doesn’t need to be accessible/compliant’, ‘the client doesn’t care’, ‘blind people would never use this site’, ‘there’s no budget for it’, ‘this is due yesterday’ etc etc.
    Sometimes I roll over and play the game and deliver a substandard product that ticks all of their boxes but none of mine, but I usually feel really dirty afterwards. So usually I’m led by my conscience, which says that I have to do it properly or not at all. Whether that is my calling or 12 years of conditioning by the accessibility zealots, who knows? At the end of the day, I would rather build an accessible web complete with wheelchair ramps and braille pedestrian crossings, than a place that only some people can navigate. And as I get older and my sight fails, my hands start to shake, and I can’t afford to keep my hardware up to date anymore, I hope that my efforts as a developer will start to pay dividends by helping me with my own web-user accessibility issues.
    Also I like the tone at the start of the article. Here’s a musical take on it:

Get the latest in Front-end, once a week, for free.