Ideajam – accessible?
The day after my last post, I just happened to visit Ideajam after I’d been doing some testing in Firefox with Javascript disabled. It completely threw me. Very little of the site worked and most of the text was missing.
Notice how all the login options and promote options are missing.
Ideajam is a valuable resource for the Lotus community, but it’s also a commercial product. So a commercial decision seems to have been made to implement alternative language support as expediantly and flexibly as possible through rendering the page using Javascript. Although this works, it’s not the ideal solution. Ideajam also makes heavy use of javascript to improve the user experience using AJAX calls to handle votes, dynamically generated tag clouds, etc. It clear that the developers made every effort to make the user experience pleasurable.
But it throws up a complicated question, what is accessibility?
I think there are two different approaches to accessibility.
The first approach is to view accessibility as making the website easier to use for the majority of users through the use of javascript to handle the simple interactions. Ideajam is clearly developed using this model.
The second approach views accessibility as designing websites that ensure that ‘no one is left behind’ by making the site work without javascript. Often these sites are government, educational or charity websites. Designers in the second category often have to make design compromises so the needs of a small minority of users are supported.
I obviously have to take this second approach, but have tried to be pragmatic adopting a ‘core’, ‘plus’ and ‘core plus’ design model.
The ‘core’ model
The core model is used for areas of the system used for teaching and learning. This includes module websites and core university support information. The core model adopts the ‘no one should be left behind’ model. Everything works without javascript. About 90% of StudyNet functionality falls under this category.
The ‘plus’ model
The ‘plus’ model provides us with the extra flexibility to develop interactive facilities using client side javascript interaction handling, and we use this model in social areas where the students’ educational experience won’t be effected. We try to ensure the functionality works for as many users as possible, but will cut corners and develop client-side solutions.
The ‘core plus’ model
The core plus model is when we make the decision to develop both the server-side and client side interaction.
Often we have to make a decision as to whether it’s worth doing the work twice. i.e. developing front-end using javascript to handle interactions and also having to do the work a second time handling the interaction through a series of server posts. More often than not, we take the decision that to only develop the more longwinded server-side interaction and this obviously compromised the interface for the majority.
ideajam as a ‘core plus’ development
Using ideajam as an example, it could be developed under a ‘core plus’ model. Multiple language support would almost certainly be rendered on the server side under the ‘core’ model. If the tag cloud can’t be generated quickly server-side, then we would develop it under the ‘plus’ model since the tag cloud isn’t essential functionality. For the vote buttons we’d probably adopt a ‘core plus’ model – links would be standard hrefs calling a server-side agent, but for users with javascript, the agent could easily be designed to handle AJAX calls without significantly increasing development time, so we’d also add handlers to make the AJAX vote. You would then have an ideajam that covers both accessibility approaches.
