Now, as you may have gathered, I work in academia…. which means the public sector.
When I build a web service, I have two sets of customers:
- I have the people who are funding the service, my organisation, and the people who define the service guidelines: they expect a certain level of functionality; a certain level of reliability; and that the service enhances their reputation(s) with it’s good looks and slick behaviour
- I also have the people who will be using the service, mainly staff & students of HE and FE organisations. JISCs new policies are also rolling out services to the schools sector, and some services (depending on the funding streams) are even open to the general public to use
This presents an interesting challenge:
If my customer base is “anybody”, I cannot discriminate against anybody – which means that the basic functionality of the service needs to be universally available (given the restrictions of the web protocols)
- The core interface must work irrespective of platform, browser, or ability of the user (within reason)
I have no problems with additional features being available to visual browsers, in a point-and-click interface… heck, if you want to have a Virtual Reality interface, with 3D rendering and swooping’n’flying – go right ahead SO LONG AS THE BASIC FUNCTIONALITY IS AVAILABLE WITHOUT IT
If you want to write, and maintain, two interfaces – go right ahead SO LONG AS THE BASIC FUNCTIONALITY IS AVAILABLE IN ONE
I’m sorry – but unless I have a service that works for “anybody”, I’m discriminating.
Accessibility is not about getting what you want looking good for you. Accessibility is about making it available for “anybody”.