I really enjoyed myself at the last user group. I was all prepared to snore my way through it, but found that I was actually very interested.
The usergroup was about Accessibility – a pretty lonely topic, less popular even than Governance. However, the presenter was a hearing-impaired, blind person who gave a very interesting speech. I was delighted because I wasn’t being forced to hear about another vendor product they say is for everyone and I think has an extremely limited scope… and because the presentation was interesting.
But the most enjoyable part was once the presenter had finished – we started chatting amongst ourselves (there was about 20 people) about what the answer was. How do we make our systems more accessible? What technologies are out there today? Where do we need to be? What are the benefits? Downsides? There were several opinions – Most stemmed from personal experience. From a practical point of view, there were only really 3 things that could be improved – they were:
- The tools that visually impaired people use to interact with computer systems needs to be made better
- The languages that we use to create and “describe” the user interfaces needs to be made better
- The tools that developers use to build the UI need to be made better
The problem with 1 & 3 is cost and motivation. 2 has already been solved – by using XML, people can create dynamic sites that are engaging and accessible. So what’s stopping a proliferation of web sites running XML with an XSL presentation layer? In the past it was bandwidth. XML is a heavy language – there’s no denying it… but these days bandwidth’s cheap and available to most… so it’s not so much of an issue.
The tools we have today do not really facilitate using this type of language or developing in this way (that’s 3). Because visually impaired people are a minority, it’s difficult to get the type of private equity money invested into 1 – and if you do, the market is small and people with accessibility issues are generally at the lower end of the socioeconomic scale, making the potential market even smaller.
The solution seems to be clear – make better developer tools – but an improvement in tools by vendors for something that is not being demanded or mandated is a tough ask (Vendors are looking for the “point of difference” in their product, not the same thing but in a different backend language). In the past, there has been considerable effort put into accessibility when governments started saying things like “We’ll only buy software that meets the following accessibility standards” – in fact, the only reason Windows has them is because governments were about to refuse to buy their OS as it didn’t have it “baked in”. So…
Maybe what we need is some way for governments to say that they’ll only buy development tools that allow them to build web sites that meet accessibility standards with the same speed that they can build non-accessible sites. Hmmm… that’s a bit hard to quantify or measure. What about “We’ll only buy development tools that give developers the choice of creating the presentation layer of their solutions in either native code or a combination of XML+XSL”. That’s better – at least we can measure that.
OK… That takes care of the guts of a web page, but how about the slick UI? What about Silverlight? Well… Silverlight uses XML to represent its functionality. It has limitations, but it’s getting there. What about InfoPath? InfoPath forms are ALL XML, with an XSL skin on them that gives them a rich UI experience in Forms Server. So you can see that we’re close. I mean, we have a language that is regarded as “Self-Describing” – that’s XML. We have tools that can have their toolset extended – in VS2008 you can implement your own intellisense for any language you can dream up. People have implemented CAML intellisense for VS2008. In a corporate environment where the devs are using this particular tool, you could conceivably build a corporate standard for XML and an XSL that maps to the corporate tags. XMLSpy has excellent capabilities, but the learning curve is steep.
So we’re close… we have the capacity to enhance our current tools to meet the need for people with visual impairments. The population is aging, which will only increase the demand for these types of features. We have the language, and the overhead of running a UI layer through XML & XSL is being countered by the increase of available bandwidth to Joe user (even here in Australia, where ADSL1 is still kinda cool). Does anyone else have an opinion on this? Is there a better way to do it? I’m not on a personal crusade here, I don’t know anyone who’s blind, but it seems a bit silly that we’re 90% there and everyone’s looking at everyone else and say “you go first” “no you go first” “no, I insist, after you” etc.
Anyway, just thought I’d get this down to see if there is a better approach. BTW – SharePoint has an “Accessibility” setting that can be turned on and off. Turning it on reduces some of the slick functionality in the UI but it makes it easier for screen readers to interpret what’s going on and let the users know.
Lastly, if you are determined to build an accessible site or app the only true test of whether a user interface / web page is accessible is to get a blind person to try it for you. It’s easy to make something that is accessible, but a lot harder to retrofit it.
Just my thoughts…