Web Accessability
How often have you heard developers spouting cliches such as "best practices" and "accessibility" and "web standards" in a bid bolster their position. Certainly many developer, myself included, do indeed try to create web sites that are both compliant and accessible. A recent task I undertook to develop a web site for the blind and visually impaired, left me humbled at how difficult it can be to put into practice those cliched paradigms.
When referring to best practices, who's best practice is it that is being put forward? And web standards seem to more and more created by software development companies than any central governing body, and the subject of accessibility is given great lip service, while at the same time being pushed further and further from those who need it most.
In a recent discussion with a developer I was told "a person who was deaf and blind cannot use the web anyhow". I was aghast. This was an otherwise sane developer who I revered as source of goodness for all things related to accessibility, yet, like so many others, the words are not backed by actions and these developers fall into guru status.
So who to turn to when accessibility issues are paramount in a developing a site or application? The answer is quite simple, the client. Having discussed issues with well regarded developers, and applying all my worldly knowledge on the subject, it was rather meager compared to the information gathered from those who will ultimately use the site.
During most projects, a spec is provided and the developers can work freely based on the needs of the client. The developer is expected to know how to put together a functioning site, graphics, SEO and all the other bits and pieces that go along with web interfaces. It is only when the interface is change, and mostly removed, that the hard work begins.
A simple date select form for use entering events into a database for the visually and hearing impaired is no longer a little javascript pop-up that allows the user to enter a date and time. A form text field is not viable also. Only a series of drooping menus, one for each of year, month, day hour, and minute were the requirements to meet the needs of people with impaired vision. Along with this, a validation class to to avoid malicious use was required and date formatting to put the date into the database. Suddenly, what had previously been a simple form, had turned into a small project of its own.
Only by closely liaising with the people for whom the site is intended, can the real accessibility issues be tackled front on. Issues of captcha's which pollute many Internet sites cause constant annoyance to those without accessibility issues, but for the visually and/or hearing impaired, many sites lock them out. It is these same developers who again and again show up on mailing lists and forums and spout cliches about these issues to other programmers, yet, their own practices fall well short of compliance.
By adopting what I call "Client Centric Development" and inviting the client into the design phase of the project at an early stage, many issues of accessability can be resolved before they arise. But it cannot stop there, by keeping the lines of communication open and rather than telling the client how the site will look, sit back and listen, and a new world of previously IN-imagined accessability issues will be laid out.