General developer forum

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

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

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.