mahara-contributors team mailing list archive

[Roger Emery <750301@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: mahara
     Importance: Undecided
         Status: New

-- 
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:
  New

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.