General developer forum

 
 
Picture of Pau Ferrer Ocaña
Reporting accessibility
 

Hi!

We're working on some accessibility improvements, maybe not all of these items are related to the master version:

  • Adding totally description titles and alts like: MDL-32946
  • Adding missing alts and titles
  • Treatment of one element lists.
  • Header's Hierarchy
  • Use of captions on Table elements
  • Descriptive page titles
  • Labels on all forms
  • External link indicator
  • And some javascript related problems

We've just started that work and we will going to use Moodle 2.4.3 version. We don't know how to report that improvements. I suppose we can start one accessibilty task on the tracker and open a subtask for each of these items.

Can you tell us something about it?

Kind regards,

Pau

 
Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: Reporting accessibility
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

First, I hope you realise how difficult this can be. For example, it is not always appropriate to add an alt or a title to something. That only improves accessibility sometimes. See, for example, the thread Damyon started here https://moodle.org/mod/forum/discuss.php?d=226459

Now, to answer your main question: you fix accessibility issues using exactly the same process as for any other bug. See

 
Average of ratings: -
Picture of Pau Ferrer Ocaña
Re: Reporting accessibility
 

Hi Tim,

Thank you for your answer. We know how dificult is it we already have acessible versions of Modole 1.9 and Moodle 2.2 that's why we're opening this discussion, to try to make things easier. We're following the WCAG recomendations as Damyon says and we have some people using this accessible verions of Moodle with Jaws and some reportings about that.

Recently I learn about the process of fixing an issue on the tracker but now we're talking about reporting 440 small fixes and 290 strings on language system (numbers of Moodle 1.9). The numbers are higher on Moodle 2.2. For this reason I have opened this post, do we have to open 440+ issues on the tracker, can we group them? maybe by topics?

I think that we can discuss some topics first of starting this work.

Thanks,

Pau

 
Average of ratings:Useful (1)
Picture of Pau Ferrer Ocaña
Re: Reporting accessibility
 

Can anybody give us some clues?

Thanks!

 
Average of ratings: -
Picture of Amanda Rubython
Re: Reporting accessibility
 

Hi there,

I've been working with Moodle now for 4 years (I work for Kineo and am good mates with Mark Aberdour who used to be my boss) and I am really interested in gathering best practice on how to make Moodle accessable.

I'm also nearly at the end of a MSC with City University, London in Human Centred Systems - which has featured modules on accessability and evaluation.

I'd really like to get involved in any work going on in the Moodle community regarding accessability so if you need any help with these issues this let me know. I am not a developer but can test or offer advice.

Thanks
Manda

 

 
Average of ratings: -
Picture of Pau Ferrer Ocaña
Re: Reporting accessibility
 

Hi Manda,

Thanks for your support. We're deciding how to report that, maybe we'll work on it for 2.6 so in the next weeks we will report some of the issues, If you like, we can add you as a watcher for that issues.

Cheers,

Pau

 

 

 
Average of ratings: -
Picture of Amanda Rubython
Re: Reporting accessibility
 

Hi Pau,
Thanks for getting back to me and yes add me as a watcher that would great.

Manda

 
Average of ratings: -
ME
Re: Reporting accessibility
Group Particularly helpful Moodlers

Your original idea of one main ticket with sub tasks is what we did with our commissioned accessibility review by Deque: https://moodle.org/mod/forum/discuss.php?d=226761
It works well if all of the sub tasks are related to one overall review. As we found more issues that were outside the original review we opened up separate tickets.

I would recommend performing the review and documenting all issues then creating the overall ticket with sub tasks based on areas of work. The easiest thing is to group like items into one subtask if the patch you are providing affects a single plugin. I would avoid tickets across multiple plugins unless they will save a reviewer time.

We also standardized a ticket format for our accessibility tickets.

*Issue*
Description of the issue.

*Standard Level*
What is the WCAG standard not being met, and link to documentation about the standard and/or its resolution
WCAG 2 (A) []

*Impact*
What is the WCAG severity of the issue

*Example Link*
Link to a specific Moodle instance where another developer can see the issue.
[http://demo.moodle.net/]

*Test Steps*
Steps to reproduce or test the issue. These might be better places in the testing steps of the ticket not in the description.

This format seemed to work well to communicate the issue and focus on where a developer can read about how to resolve the issue. We were not supplying patches however. It was also useful because it may take developers time to review the patch so having all the logic for the fix really helps after a long period of not working with the issue.

I would say it would be really useful to educate others, myself for one, on the resolution of each issue. Providing the logic for how to fix the issue will help to avoid the issue in future development. Also I would say like Damyon's post Tim mentioned if you see a repetitive issue you may want to make a new policy ticket to discuss the proper development practice that should be followed going forward.

 
Average of ratings: -