Submitted by Jez on Sat, 09/13/2008 - 09:05.
Hello All,
I know that Ajax can cause problems with screen readers, due to asynchronous updates not being detected (by the screen reader).
A good article on the subject can be found here:
http://juicystudio.com/article/making-ajax-work-with-screen-readers.php
The consequences of this can get quite serious (legally, at least in the UK) and it is something I plan on testing in the next week or so.
In the mean time it would be great to get some feedback regarding Mahara accessibility in relation to screen readers.
Regards, Jez
As far as I know, nobody has
As far as I know, nobody has tried using Mahara with a screen reader before.
When we first developed Mahara, we initially decided to require javascript, but accessibility requirements made us change our minds. Starting from about version 0.9, we started reworking parts of the code that were javascript only to work without javascript.
The Views interface works with javascript turned off (although who knows how a screen reader will deal with it!). Many other parts of the system now work with javascript off too. There's a few js-only areas, and Mahara won't let you log in unless js is on, but things are getting better over time.
Hi Nigel, I tried it with
Hi Nigel,
I tried it with Javascript off after reading an old forum thread on the topic (i.e. in the old forum).
As you say, you cannot log on. Also you cannot edit files and groups do not display properly.
Have you any idea how long it will take to make Mahara accessible. How much work is involved?
I would have thought the login page would be easy to resolve, or have you deliberately left this to stop users running into problems later on in their session?
The login page deliberately
The login page deliberately requires javascript to prevent later problems, as you say. It'll be a great day when we can remove that requirement!
The entire files section was written before we decided to go non-javascript, and as such is the single biggest part of the system that would need to be reworked to ensure non-javascript support.
Groups are fixed in 1.1.
As for how much work - well I can't put any kind of reasonable number on it without doing a detailed audit of the system. Off the top of my head though, the main problem is the files area, which could need 3 - 4 weeks of work (it would basically need to be rewritten). Note: 3 - 4 weeks means 3 - 4 weeks at 40 hours a week by one of the core devs ;)
When we work on a new section (or an overhaul to an existing section) of Mahara, we make sure it works without js on. So over time, things are slowly getting better. If you would have tried with 0.9, you would have found a lot more things broken :)
Hi Nigel, I hope I do not
Hi Nigel,
I hope I do not seem over critical here... I think its a great app and I can see you have already made some difficult changes to improve accessibility.
There is a growing level of interest in Mahara within our organisation and people who have tested it so far thing its great!
The biggest hurdle we would have implementing it will be compliance with the various anti discrimination laws we have in the UK, some of which is specifically aimed at the education sector.
I think we could be on a very sticky wicket (legally) if we were to use Mahara in its present form... hence all the questions!
Thanks for your "guesstimate" of 120 - 160 hours, it is very helpful, but what is the cost per hour (please give currency) :-)
Regards, Jeremy
Heh, the questions and
Heh, the questions and criticism are fine! They've got valid justification, and it would be better for everyone if we got it all fixed :)
Our rate is 70 pounds per hour - please contact mahara@catalyst.net.nz if you wish to contract us to do work.
Hello again, I would also
Hello again,
I would also suggest adding more info to the ALT tags. For example, within "edit view" each control is labelled the same, "move block right", "move block down" etc.
Would it not be better if the alt read, for example "move Moodle RSS Feed right" "move Mahara Video Turorial down" etc.
I have not looked... but I imagine that would be a very easy mod as the required labels are already being returned.
Jez
Could you file a bug for
Could you file a bug for this on the eduforge tracker? Seems like a good idea.
Hello again....! Another
Hello again....!
Another thought... for the interim, I am wondering whether it would be possible to add a "no javaScript" field within the users profile, so that javaScript was disabled wherever possible. For example, allowing a user to log on (which currently requries js), but then using the non javaScript version of the "edit view" page.
Do you know how difficult it is to force the use of the non js version server side?
Sorry for asking so many questions... I havent had chance to look at the code properly yet... and I am not really up on js.
Jez
I think the long term
I think the long term solution to this is to have the entire site degrade gracefully. Then users can make that choice in their browser :)
Do you see an advantage to a setting as opposed to the user controlling this through their browser?
Hello Nigel, Not "as
Hello Nigel,
Not "as opposed" to controlling via the browser, but "as well as" for a couple of reasons:
1) During this transitional stage it would allow accessible portions to run without js. So, you could log into the system (which requires js) and use the accessible version of "Edit This View".
2) Longer term, users may generally want to run js in their browser, but not run it in Mahara. It would seem sensible to have this additional option.
Regards, Jeremy
Yeah, I can see your
Yeah, I can see your point... would there potentially be more settings than just "javascript yes/no"? Accessibility is about a lot more than that (of course this depends on your local laws), but maybe there could be other settings that affect the site in different ways too?