Helping out with Drupal Accessibility
While a coder may not have a great deal of time or indeed the answer to any of the accessibility problems encountered in using Drupal, there are still numerous ways that some minor coding skills can used to massively help out with the accessibility of Drupal.
While this is written specifically with Accessibility in mind the skills are very transferrable and can be used for any initiative you may want to help out with.
Most new development is happening in Drupal 8 at the moment so you will need to get the latest version of that first:
You need to at least have git installed and working to get drupal 8 and to supply patches so I'm going to assume you have that already, if not check out: http://drupal.org/documentation/git for lots of very helpful information.
git clone --branch 8.x http://git.drupal.org/project/drupal.git
if you know you'll also be helping out on Drupal 7 issues you can also:
git clone --branch 7.x http://git.drupal.org/project/drupal.git
Once you have the code you'll need to install the instance of drupal to apply patches to and test the result, so do that next.
Next we need to find something to work on and there is 2 ways to do this.
Drupal Accessibility Groups
Head over to the Accessibility group at: http://groups.drupal.org/accessibility and browse the topics in there, more often than not there are links to various issues that are related to Accessibility which require some extra help to get the issue fixed.
Also look out for the posts marked: "Monthly Accessibility Skype". These are posts that have information and links from the accessibility teams skype discussions, but these posts usually also have links to issue that have some current focus and so may need patch reviews or re-rolls as there is active work happening there.
Filtered issue queue
The second way to find a task is to hit the issue queue. http://drupal.org/project/issues for all issues or http://drupal.org/project/issues/drupal for just core issues, but the way to get issues relating to Accessibility is to actually use the Advanced search by clicking the Advanced search button on the issue page or going stright to: http://drupal.org/project/issues/search (or http://drupal.org/project/issues/search/drupal for core only issues), use the Issue tags field and type Accessibility into that field, you should see that it is autocomplete but you will have to get to at least accessib before you see anything relevant start to appear. Tags that are useful to include are: (accessibility, accessibility a11y, needs accessibility review)
The other filter to use is the Status filter. Depending on the issues you are after you can choose between or select all of:
- tends to suggest a solution has not yet been found
- needs work
- A solution has been suggested but some additional work is required to actually fix the problem
- needs review
- a patch has been supplied and needs someone to test the supplied patch
- patch (to be ported)
- a solution has been filed and patched for one version of Drupal but the other versions have still got the same problem that needs the solution applied
How anyone can help
There have been suggestions that for many issues there are enough developers to fix all the problems, but the biggest sticking point in the issue queue is getting the fix implemented before something gets changed elsewhere. Changes elsewhere within the Drupal software can mean that a valid patch may suddenly start failing automated testing and can not be committed until the developer spends more time fixing the patch (re-rolling) to make it apply again after the changes.
The bottle necks in the issue queue that anyone can usually help with are getting these patches to the reviewed and tested by the community status, so quick jobs that need doing are that can save other developers loads of time:
- applying patches to see that they install correctly and make the changes they say they do and reporting back to the queue any successes or failures. 2 or more tests like this means an issue can be flagged "Reviewed and tested by the community" and are deemed ready for merging into the latest version of Drupal.
- taking existing solutions and re-rolling them after they have failed testing, this could be because of automated testing has failed or because another comment has requested that something else needs changing. More often than not the initial solution is still valid but some code needs to be added/removed or slighty amended to make the patch work again.
- porting patches to other versions of drupal, i.e. a patch created for Drupal 8 may need some slight tweaking to make a similar patch for Drupal 7 or 6. as there might be some slight code differences.
Applying a patch is simple and can be done using git again:
First, I have a look at the patch a try to figure out all the changes that are going to be implemented, how many files will be affected and what pages on my Drupal site might be affected, if possible. I then right-click the patch and choose copy link location, before heading over to the command line and browse to my Drupal installation and typing:
git apply -v [patchname.patch]
If that installs ok, I will then go to my internet browser and have a look around the Drupal site to see that no error messages appear and if I have figured out which pages are being affected by the patch, I'll go there and have a look at how this have changed.
Once I have done as much testing as I can, I'll go back to the issue on drupal.org and report my findings. I would try to do thorough testing, but that's not always possible and even if I only report that the patch installs correctly, then it is something and every little helps.
Re-rolling a patch
This usually involves taking a patch a part and looking at what lines are supposed to be changed and what changes are to be made. It may involve going into the files to be affected and manually changing the lines by hand, but in most cases the patch can be applied and only one or two lines are actually causing the patch to fail. So, applying the patch as above then going in to the code and manually changing one or two lines is all that is required, before created a new patch.
Once the changes are all made you need to commit your changes to your local git
git add -A
git commit -m "Issue #[issue number] by [comma-separated usernames]: [Short summary of the change]."
Then you need create the patch file
git diff > [description]-[issue-number]-[comment-number].patch
Then take that file and post it the issue on drupal.org saying it is a re-roll of the previous patch which failed review.
This is an almost identical process to the re-rolling process, but instead of applying the patch to the current version, the changes have to be implemented to a previous, or later version of Drupal and depending on how far through the development cycle the versions are, then there may be major differences or only quite minor differences between the verisons of code.
Obviously there are more ways to help out, like I haven't mentioned finding accessibility issues and reporting them, actually creating the solutions to issues or running tests on the actual solutions provided, but this post was more of a way to quickly putting some coding skills to use without actually having to create the solution to potentially challenging problems.