Intro to accessibility

Last Wednesday, May 9, 2012, was Global Accessibility Awareness Day. According to the website it

is a community-driven effort whose goal is to dedicate one day to raising the profile of and introducing the topic of digital (web, software, mobile app/device etc.) accessibility and people with different disabilities to the broadest audience possible.

I took the occasion to make some more inroads into my own awareness of web accessibility. Julius, a new colleague of mine, helped me set up Orca. It is an open source screen reader for Ubuntu.

Unfortunately, we didn’t get very far because my voice over didn’t want to play nice. So we concentrated on testing a site with the WAVE toolbar. That’s quite a nifty tool for me because I can see where there might be problems on a page and where accessibility could be improved.

I tested the newly created Mahara user manual to check how it fared. It is written in reStructuredText and published through yet another open source tool, Sphinx. WAVE pointed out areas of concern but also things that worked in favor of accessibility. Fortunately, mostly everything was well because I had made sure that figures had an alt text and inline images immediately take on the short name of the substitution as their alt tag.

There were three items that needed improving:

  1. The search field did not have a label and thus a person relying on a screen reader might not know immediately what to do there.
  2. The images of so called admonitions like “note” and “warning” were placed as background images in the stylesheet and thus would not be read aloud. That means that a person listening to a screen reader would not know that a section was coming that was highlighted but would read it as if it were regular text.
  3. One thing I just realized when I looked at the output by Fangs is that my manual arrow ( -> ) comes across as “dash greater than”.

I fixed the first issue, and the search now has a label instead of text below it when it is already too late. For the images in the admonitions, I’ll have to talk to a front end developer to come up with a good solution. The third issue can be fixed by finding a nice looking Unicode symbol of an arrow that I can use in reStructuredText. I don’t know why I hadn’t done that right from the start. :-( However, I’ll have to check how to include the Unicode encoding for the LaTeX PDF build. The arrow looks nice in HTML but not yet in LaTeX.

Then the last step will be to propose the changes for the search box and the admonitions to the community for inclusion in a future release of Sphinx.

Open source project contributions

Unless I want to add a news item to the web site of the company I work for, Catalyst IT, I do not visit the site. That was already the same for the universities where I worked because such sites are usually geared towards the general public, but not the people working there. Thus, I sometimes stumble upon hidden gems or am reminded of cool pages.

Recently, I was reminded of the page where all our open source project contributions are listed. Currently, this list has 142 open source projects listed to which current Catalystas have contributed in the past or presently. This can be small 1-5 person projects or big ones like Koha or Moodle, projects that were created for a very specific purpose and are now defunct or projects that are continuously maintained.

That’s an impressive number of projects and may actually not be all because we pull the projects and contributors from Ohloh. If a project is not registered there, our site won’t know about it and also if developers have not added their Ohloh username to our internal wiki, our web site cannot pick it up.

With more people joining the company, this list will hopefully grow more.

 

Like being in a candy store

Yesterday was ANZAC Day in New Zealand and it was flanked by two Mahara-related events for me:

  1. MUG (Mahara User Group) online meeting at 6 a.m.
  2. Eportfolios in focus webinar at 10 p.m.

For both I was asked to give a presentation on new features in Mahara 1.5 which we released last week. The time slot available in the MUG meeting was a short one whereas I had 45 minutes altogether in the evening webinar to present some new features and also answer questions of users.

So many things to try

So many things to try

While preparing both presentations, I was very torn between a number of features that I wanted to highlight as there are so many that are really cool. So it was like “I want this and this and this and this” like a child in a candy store. Fortunately, all the features I presented are built into Mahara by default. It’s just that I had to make a tough selection for the presentations.

I was happy to have had the opportunity to talk about some new features and share my enthusiasm for this new version of the open source ePortfolio system Mahara with others.

Both were recorded. Once the link to the Eportfolios in focus webinar is available, I’ll post it.

If you want to find out about these and many other new features in Mahara 1.5, you can for example:

Mahara user manual on Launchpad

… or a new project on Launchpad was born.

On Friday, 20 April 2012, after the release of Mahara 1.5 had been out of the way successfully, we started to have another look at offering the Mahara user manual for translators to work with. I will write more on producing the manual at a later point.

Sphinx, the software we use for the documentation, allows for internationalization. It is also quite easy to generate the translation files. All you need is a one-line command in which to specify the source and the output directory:

$ sphinx-build -b gettext source potfiles

It took a couple of minutes until all files were processed and pot files generated that translators need. That was the easy part. What we haven’t found out yet is what to do with screenshots that should also be translated. The Sphinx documentation doesn’t mention them at all and my post in the Sphinx discussion group hasn’t resulted in any replies so far. Probably, because Sphinx is most often used for code documentation and the code examples wouldn’t need to be translated. ;-)

Focusing on the actual text for the moment, my colleague Richard, who also works on the Mahara project, convinced me that it would be the best to use the POT files, even if we haven’t figured out the screenshot translations yet, instead of the translators working with the original files and translating those. The latter would basically mean that the English translation would be forked as anything can be changed in it. Whereas if the pot files are used, updates can be made more easily and the translators are spared most of the code and really only see the strings.

In order not to confuse the documentation translations with the actual Mahara translations, we set up a new project on Launchpad and called it Mahara user manual. ;-) Richard helped me with the initial setup linking one of our existing Mahara groups and thus making some default settings which got us off the ground more quickly. In the beginning, we only set up Launchpad for the translations, but while playing around with the setup, I also activated additional features. I continued the setup yesterday and now the Mahara user manual project has:

  • bug and feature tracker
  • space for questions
  • translations ready to go
  • downloadable files
  • announcements
  • milestones and releases
Mahara user manual overview page on Launchpad

Mahara user manual overview page on Launchpad

(The screenshot says that the project was created on 19 April 2012, but that’s UTC and not NZ time. ;-) So It really was on 20 April 2012.)

I also officially released the 2 existing versions of the manual: 1.4 and 1.5. I can still update the manual whenever I have time, push my changes to the server and update the documentation to Read the Docs, the service where we publish the manual. But in case some people do want to work with the PDF or Epub versions, I might put those files up for download in intervals. Of course, they can always be accessed on the download page for the manual on Read the Docs. Furthermore, this gives me a snapshot of the manual at these times.

There are still a few things that need to be looked into. Chief among them:

  • integration of localized screenshots
  • automatic creation of the POT files
  • setting up the localized directories and the translation export to git

Still a bit of work, but we are getting there.

If you are a user of the Mahara manual and find things:

  • that you would like to see added
  • that are missing
  • that are incorrect
  • that are explained too difficult
  • that need another screenshot

… or anything else you’d like to say, please head over to the Launchpad page and leave a bug or wishlist report or ask a question.

Hot off the Internet: Mahara 1.5

A little over 10 months of work on many fronts:

resulted in the release of the open source ePortfolio system Mahara 1.5 this nice New Zealand evening. You can view some highlights from new features and bug fixes as well as contributors and sponsors of this release in the release notes.

It was great working on this release at Catalyst IT. This is the first Mahara release in which I have commits: 3.4% in the grand scheme of the release. I helped out correcting language strings. Not everybody needs to be a developer to be able to contribute to a software project.

But actually, these commits were my smallest contribution. The product that I’m most proud of is the updated user documentation for Mahara 1.4 and the documentation for 1.5. Thus, when we released Mahara 1.5 today we also had a full documentation available. :-)

Although I say “full documentation”, I will update it infrequently correcting things, adding small bits and pieces that are missing, hopefully also putting references to online videos etc. I hope we’ll also figure out how to translate the documentation. The text itself shouldn’t be the issue as Sphinx allows for that, but the screenshots might be trickier.

But right now, I am just happy.