mahara-contributors team mailing list archive

[Don Presant <750301@xxxxxxxxxxxxxxxxxx>]

I see this as a big problem waiting to happen, especially for large
educational Mahara implementations.

I recently lost a potential contract here in Canada, because the federal
government has stated that accessibility is a basic requirement. They
were recently successfully sued on an online accessibility issue.

It's only a matter of time before a blind or quadriplegic student
somewhere, excluded from participating in Mahara, successfully sues the
provider for violation of his/her human rights, with costly and
disruptive consequences.

What would it take to scope this properly so a price tag can be attached
to it and funding can be sought? My feeling is that money to redress the
issues should be easy to find, and all would benefit.

It should be as simple for the user as selecting language.

For reference, see:

The W3C specification:
http://www.w3.org/TR/wai-aria/

The new standard in Canada for government web sites:
http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?section=text&id=23601

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
https://bugs.launchpad.net/bugs/750301

Title:
  Accessibility / Screen Reader Issues - various

Status in Mahara ePortfolio:
  Triaged

Bug description:
  A student who is entirely dependant on a screen reader (in this case
  WindowEyes) has been through Mahara 1.3.3 and raised a number of
  accessibility issues as follows:

  1. TinyMCE editor
  It is essential to be able to turn off the TinyMCE editor as screen reader users cannot use this editor. 
  A plain text input field works fine (as per education and employment etc)
  Already a wishlist here: https://bugs.launchpad.net/mahara/+bug/548225
  But needs to be user choice.

  2. Files upload
  Disclaimer Check box not obvious.
  Once file 'Browsed' and uploaded, no notification to indicate upload process having completed. Other aspects appear to be in the wrong order for the student.

  A suggested process path would be:
  Add a File > Browse > Select > Disclaimer > Upload > Upload Complete dialogue > Storage Space remaining warning.

  3. Local Language. 
  More a note to self, but advice to others. If changing Language strings, ensure you also change all instance's to cover ALT text. We use the word "CV" instead of Resumé. Screen readers read Resumé phonetically as "RE-SOOM"
  Lang files need to include ALT strings.

  4. Add and Delete Buttons: ALT text just says 'add' or 'delete' When there are many 'adds' and 'deletes' on a page it is not obvious which resource you are adding or deleting. 
  ALT should say something like (eg) "Add Educational History" or "Delete Educational History BA Hons Business"

  5. Creating a View;
  The student can create a view, but from that point on cannot make any use of drag and drop - partly because the student does not use a mouse and partly because there is no indication where anything has been dropped. Suggested use of radio buttons - process would be pick an artefact > pick a location to put it.

  
  It is possible that some or all of the above can be wrapped up into a single 'screenreader' or accessibilty' editing mode with toggle link in the header somewhere. 
  I also note that there are some workarounds that could potentially be adapted from discussions around ie6 versions or ipad versions.

  It is recognised as quite a challenge to offer a very visual tool to a
  non-visual user, who would still like to present themselves to a
  visual audience.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/750301/+subscriptions