don't try to solve all potential access­ibility issues yourself.

leave some to assistive technology at the user‐end.

Surfing around reveals loads of sites with some degree of accessibility issues, approaches and claims, and a million times more sites with next to zero attempts at improved accessibility and no or faulty claims. Which sites that are reasonably accessible to people with various disabilities and problems, does not seem to split at the apparent divide.

Many reasons for that, as that most sites are not all that challenging from an accessibility standpoint, and that not all “improved accessibility” solutions are well thought out and well supported by software/hardware at the user‐end.

Some web site developers seriously try to solve as many accessibility issues as possible for as many end‐users as possible. That's good, but from where I see it they are in for a life‐long challenge with limited chance of total success.

Maybe they should aim a little lower, focus on the main issues, and leave fine‐tuning of details for the various disability‐combinations to developers of assistive solutions at the user end.

independently chasing the perfect solution – won't work.

Arriving at the “perfect” solution does not count for much, as it will tend to fail in competition with other “perfect” solutions and the enormous force known as “status quo”. Unless one has the means to make everyone else in the trade go along, failure in the form of limited adoption is almost guaranteed.

Makes sense that a few dedicated committees, along with dedicated assistive technology developing groups, take care of the heavy lifting. Much better than relying on a multitude of more or less functional and at times pretty complex and/or messy solutions spread around on millions of web sites.

Committees rarely ever arrive at better solutions than individuals do, but chances for wide range penetration/adoption are somewhat better. At times, when committees take guidance from the real world, their solutions are not too bad either.

Letting dedicated project groups design solutions for specific end‐user groups with defined challenges and needs, is the next step. It is somewhat like designing application and tools so end‐users can do what they want with a web site, any web site, only in most cases a bit more challenging than the average app/tool.

Chances are dedicated project groups know more about how to provide real solutions for real problems at the user‐end, than can be expected of the average developers and designers responsible for churning out web sites day in and day out. If such dedicated groups also put their knowledge to good use, chances are they can transform most inaccessible web site solutions into accessible ones, at the user‐end.

take the web as it is, and crunch the numbers.

The norm is that appearance and “WOW factors” dominate in web design, and as a consequence most web sites do not work all that well – not even for the people who designed and coded them. It is too much about looks and “smart solutions”, and too little about content and functionality.

So be it; more and more end‐users develop “appearance and WOW factor blindness” – same way as they have developed “ad blindness” after having been bombarded with ads for years. Ignoring disturbances is the norm, no matter how and for what they are implemented.

The “state of the web” as a whole, is unlikely to improve much in the coming years. That is the web assistive technology developers has to work with whether they, and we, like it or not. Thus, one should be able to expect assistive software/hardware to be developed to a point where it will work with the existing web and not be in need of tailored code/pointers in web pages.

Simply put: if humans can ignore disturbances and read some logic into mixed and messed up web documents, then software algorithms can be applied that will achieve the same. Designs may be disassambled and/or destroyed in the process, but design as such is mostly ignored by end‐users anyway so no big deal.

I am not arguing against improved coding approaches like WAI-ARIA for web sites. That is all good, albeit a bit late. Same goes for the evolution in markup and styling languages and programming capabilities.

I am saying assistive technology should not need additional web page code/pointers beyond what is already found on billions of web sites, in order to resolve the most complex solutions for some end‐users.

I am also saying that the more code web site coders are given to use on sites, the more sites will intentionally and unintentionally be launched with flawed code that mess up rather than solve real problems for groups of end‐users. More than enough weak sites already, and giving the same designers and coders more to play with is unlikely to improve things.

The more power in the form of accessibility options that can override the work of web site designers and coders – when and as needed, that are implemented at the user‐end, the greater the chance for working web sites for all.

When the day comes that browsers and assistive software/‍hardware can handle any web page/​site, and modify suboptimal content and functionality into something that works reasonably well for individual end‐users regardless of their capabilities, we are closer to the open web.

sincerely 

Hageland 07.dec.2012

last rev: 12.dec.2012