My concern is based on almost 25 years of personal experience in this field – of first hand exposure to, and awareness of the insidious creeping and ultimately robust systemic discrimination. Most barriers don’t tend to arise by intention, but DESPITE the best intentions and actions of designers and developers trying to do good. It’s usually not in the large decisions when setting out, but in the myriad of day to day technical flesh-outs and implementation choices made under timeline and resource pressures that seemingly harmless pieces are put into place that ultimately have such devastating consequences to some individuals with disabilities.

An exception to this general characteristic of small-over-large, adhoc-over-planned capability for making barriers can be illustrated by the above Principle #2 (Paraeto). Accessibility issues will often make it to the ‘In Basket’, however in practical real-world situations, the inbox is never empty (there’s almost always things to do than time and/or resources to do them) and by the time these issues have risen to the top, the moment (timeline) has passed where real substantive strategic and design choices could have been made that positively affect the smaller but multiplicated choices downstream. That is why so much accessibility work is retrofitting and patch-work. Although 1 or 2 people might understand the initial specific, clarified intention of (for example) “Design for the 80%”, the reality is that the overwhelming majority of downstream designers and developers – lacking the context that currently exists – will not share this understanding. Upstream decisions as stated (rather than as intended) create the context for downstream decisions. Unless done at the start – when foundation and fundamentals are put into place – ‘doing’ accessibility is difficult – at least more difficult than, say, visually-oriented design (which, I’m sure you’ll agree, generally predominates in the world of design). Just as Mark Twain said (I think) that the longer I work on a book, the shorter it gets, the longer a downstream visually-oriented designer works on her site, the higher the probability that the accessibility part will get to the top of her to-do tray – the reality however being that she probably won’t have the time to ‘edit’ her site to be usable to that other 20% (the disabled 20%). In her eyes (or those of her boss) that work represents diminishing returns.

Transformative Shift in Perspective:

Leisa, despite your much appreciated recognition that ‘disabled persons R us’ (whether us with a broken arm, or us older), when it comes to developing most technologies and systems (web apps and CMSs included) the reality is that without specifically targetted focused and explicit modeling (through personas, use cases, etc.), persons with disabilities ARE peripheral to the focus of development which means that they will not be within the 20% area of focus (to generate the desired 80%).

The challenge that I am throwing out with the proposal to explicitly move persons with disabilities into this 20% circle of focus (unusual though it may seem) is to identify what would be pushed out, and comparing whatever that is with what it is being replaced by.

From what little I have learned so far, it appears to me that usability is right up at the top of Drupal 7 development priorities. This implies to me at least the addition, if not direct focus, on ‘human-centricity’. If I am correct in this assumption, then what better way of making Drupal’s administration clearer and more understandable to human administrators than to design it so that a person with a learning disability could quickly get up to speed and use it…. to have effective ‘just-in-time’ reminders so that a person with memory impairments could use it… to have the states of partially completed processes preserved so that an easily tired person with multiple sclerosis could stop, take a rest, and then pick up where she left off after… to ensure that a person who is blind and can’t ‘drag and drop’ can, nevertheless still reorder their widgets using the keyboard or voice recognition and screen reading feedback … so that, for example, everyone else can just use their telephone…?

Leisa I hope you (and anyone else reading this) see this for how it’s intended – as a conversation meant to inspire a more human-centric approach than what has resulted in the past. If we continue to do the same thing the same way, we’ll continue to get the same result: marginalized persons with disabilities and in many cases, predictable mediocrity – although given the quality of Drupal’s community and software, I highly doubt the latter. In fact, it is this very quality that excites me… trying to imagine the true transformation that could result from the sustained focus of this incredible community of designers and developers towards a truly (disability-related) human-centric bulls-eye.

Thanks

Bill

I agree that ‘design for the 80%’ might seem to imply that people with accessibility requirements fall outside of this 80% but that’s not the way we see it at all, hence the importance that we’re placing on accessibility in our design considerations and getting Ann involved early in the design process.

The way I see it, almost any of us can very quickly develop requirements for ‘accessible’ websites – as easily as a broken arm from a ski accident, developing RSI, leaving our glasses at home or – the thing that is inevitable for all of us – getting older!

So that places accessibility requirements firmly within the auspices of ‘designing for the 80%’ from our perspective.

Thankfully, well architected IM/IT design and accessible IM/IT design are mutually reinforcing as W3C discovered with the establishment of it’s Web Accessibility Initiative. It turns out that accessible IM/IT not only ensures inclusion of persons with disabilities, but a ‘disability dividend’ also results – increasing the quality and ‘future-proofing’ of mainstream technologies. As to the opposite direction, in my opinion the extremely high quality of Drupal’s architecture gives it a considerable head-start down the accessibility road. This is a key reason why we have selected Drupal as the infrastructure for the new site that we are developing.

As your well crafted listing may imply, it can sometimes be easy for developers and designers to get lost in the weeds of accessibility’s technical details and/or get mired down into debates without a compass to remind them that these details are ‘hows’ and that the important things relate to the ‘whys’.

While working on the Government of Canada’s Web Accessibility Testing Service, I would often meet government developers arriving, carrying armfuls of technical documentation and standards, ready with all kinds of questions. After guaranteeing to address each of them at the end of the session, I would then invite them to sit with our testers (one who was blind and using a screen reader, and one who was a high-level quadriplegic using voice recognition technology) as they attempted some tasks that any typical Canadian would, on the site of the developer’s department. It was amusing to watch as, being public servants of good will, they would be very helpful to the tester explaining, for instance, how he could find a particular link, or fill in a specific form – until I would reach over and turn off the monitor. That’s when the real learning would begin – and the standards and documentation would begin to make sense.

Of course these are 2 unique individuals experiencing 2 specific disabilities, and the reality is that people experience disabilities that range in type, quantities and complexity (Helen Keller was but one example). But they do illustrate the need to design for ‘edge cases’ rather than mainstream… which brings me to your principle #2:

“Design for the 80% ”

I will not pretend to know what, exactly, is meant by this principle at this point and therefore will assume, for the purposes of my remaining comments, that it refers to designing for 80% of users of Drupal 7 (whether in the roles of administrators, content suppliers, or surfing visitors). If, as is likely, I am mistaken and the 80% refers to something else, then I apologize in advance and hope that my comments will, nevertheless, be useful or of interest anyways.

If it does (refer to designing for 80% of users that is), then I believe that this might be a mistake. It’s not that I don’t understand the principle: 20% of your clients bring you 80% of your business; 20% of your inventory bring you 80% of your profit; 20% of your carpet’s area contains 80% of the dirt… 20% of the design effort of Drupal 7 will bring satisfaction to 80% of Drupal users.

This approach is devastating to persons with disabilities. (At least this approach unmodified: read on).

It has been – and continues to be – a recipe for marginalization of some of the most vulnerable of the population – a population that, nevertheless constitutes the largest minority group of all… and one that continues to grow with the playout of demographics and other factors. Ironically, a population that contains people for whom the web provides empowerment, a population who tends toward a higher than average rate of web usage – despite its barriers.

May I suggest an alternative – although more challenging – approach? If there is no getting around it, and this principle MUST be applied (i.e. aiming at 20% for 80%), then I’d like to suggest that design – especially usability design – be AIMED at the 20% OF THE MOST DISABLED of the population.

(…pause, while disbelief plays itself out…)

The more you think about this, the more sense it makes. While you’re designing for these ‘edge cases’ the most creative, most innovative, most future-proofed, most human-centered, most standards-based, highest quality architectures rise to the top:

Web applications, websites, or for that matter, pretty much most systems / services / infrastructures that are usable by people who experience various disabilities are definitely more usable to people who don’t – and often are usable by other technologies. A video captioned for people who are Deaf can, for instance, be searched by software. A website that can be used by a person who is blind is almost, if not totally, usable by someone using a mobile device. A website that can easily be used by a quadriplegic using voice recognition or morse-code or scanning-based sip and puff switch technology is definitely easier to use by everyone else (think, for example, word prediction).

For any of you who are still skeptical (I admit that this may appear non-intuitive at first to conventional thinking), here are some other examples of where the ‘disability dividend’ contributed wholly or partly to the initial development, or enhanced quality of key mainstream technologies.

Cheers

Bill Shackleton

Segway:

Dean Kamen developed the iBot wheelchair noting that “…after more than 200 years of manufacturing wheelchairs, they still could not go up a curb…”. The technology he developed for his superior wheelchair went into the development of the Segway.

Telephone:

When he turned 70, Alexander Graham Bell stated that “recognition for my work with the deaf has always been more pleasing than the recognition of my work with the telephone.” Much of what he learned in this work helped him with his invention.

Keyboard:

The first typewriter proven to have worked was built by Pellegrino Turri for his visually impaired friend, the Countess Carolina Fantoni da Fivizzono. The commercial production of typewriters began in 1873.

Computer:

As a person with severe learning disabilities, Herman Hollerith incorporated ideas from Jacquard’s loom and Babbage’s Analytical Engine to create an electromechanical information machine that used punched cards. His Tabulating Machine Company became IBM.

Transistor:

The first practical use of a transistor was a reliable, powerful, flexible, smaller, cheaper, cooler-running and less power-consuming hearing aid.

Records & Tape Recorders:

The 33-1/3 RPM record and the tape recorder were invented and developed to enable the blind to listen to books.

Music Keyboard

Inspired by Stevie Wonder – his first customer for his Reading Machine for the Blind – Ray Kurzweil invented the first synth keyboard using acoustic sound

excellent to have all these vital points all collated together – something properly practical to go on
Will refer anyone interested to this page …
Thank you

Webchick: It isn’t under any particular license, because I didn’t even think about it (but it’s definitely something I’ll think about in future).

I’m very happy for it to be part of the handbook and released under the same license.

All this stuff is great advice, thanks for taking time to share!