Forum .LRN Q&A: Accessibility improvements for 2.4

Hi all,

In the scope of one of our project, an(other) evaluation of the accessibility of dotLRN has been carried out by experts. They provided us with recomendations to improve this aspect where it's necessary. This evaluation has been done on dotLRN 2.3.

Below, I detailed the issues and the recommendations as they have been described by the experts, I've added a couple of comments too. I know that this arrives a bit late since we are near to release dotLRN 2.4 (or so I hope) but maybe we (aDeNu group at UNED) still have time to implement some of them if the community agrees.


Those are proposed to be implemented on head.

- Forms (can be done providing an alternative template):

  • the "required" indication is outside the label tag. This means that the word is read by a screenreader in "normal" mode but not in "forms" mode which is required for completing forms. Recommendation: place the word "required" within the label tag.
  • When there's an error submitting the form, the error message appears near the bottom of the field that caused the error, which screenreader users would not be aware of straight away. Recommendation: place an error message also at the top of the form indicating where the error(s) is.
  • The red color used to highlight errors may not be perceived by everyone. Recommendation: provide an additional indication of the error: perhaps use the word "error" to precede the error message.
  • The help messages appear after the field and therefore are read after the field. The user has to go back to fill the field. Recommendation: put the help prior to the input fields

- Dates format: those displayed as, for example, "04/16/07" are announced as numbers rather than dates by screenreaders. Suggestion - 16 April 2007 - using the words rather than the numbers helps in accessibility (a.k.a usability for all).


- Provide an accessibility page with explanation on how to switch between CSS, the list of the access keys and the max font size available. Consider putting the CSS switcher in the control panel instead at the top of the page.

- The "skip to main content" has to be visible always

- Improve the color contrast of the portlet headers (user and class portal). Those headers use a background image that is a gradient, the problem is in the lightest part of the gradient. (Dave already changed the class one). Probably using a plain color would be easier to meet the color contrast requirement.

- CSS: change absolute size to relative ones. When an user uses screen magnifier, some elements are lost on the right side and therefore are missed by the user, besides it causes a horizontal scroll which is annoying.

- breadcrumbs: would be useful to precede them with the text "You are here" esp. for screenreader users, because the purpose of the list is not obvious. The text can be made invisible using a style so will be only read by screenreader.

- accesskeys: it is recommended to use numbers instead of letters to avoid clash with browser and environment access keys (see


- review the alternative text of the icons or better, put those icons in the CSS
- the form to go to a date lacks of a label.
- mini-calendar, week view and month view tables are not marked up as data tables. headers should be used to associate weekday with day.
- day schedule: the current day could be the table caption. a new row of headers could be added to identify the content of the columns such as "time" and "event". The times could also be coded as table headers.
- add-event form: reorder the fields of the date (according to the locale of the user). Use labels.
- not readable in HC mode (no CSS for that mode, we'll have to write one and find a way to make it switch too)
- Days in the calendar are announced as "link 1", "link 2", "link 3" which is not meaningful. Recommendation: add title to be read as "link 1 April".

File storage:

- portlet and folder-chunk: not all columns of the list have a header.
- Contrast of the filename is not sufficient (light grey on light blue)


- portlet: not all the columns of the listtemplate have a header.


- portlet: the summary of the table is "data for $course_name" (probably the default set by listtemplate when no summary is provided). The summary should be meaningful.
- SCORM player:

  • There appear to be 5 frames although only two are actually visible. This issue also affects screenreader users and voice recognition users. Recommendations: If possible remove the two non-visible frames. If this is not possible provide frame names that will be meaningful to students. Do not include the word "frame" in the name of the frame because the screenreader will include that word.
  • The expansion images in the menu frame have no alt text. Recommendation: provide an alt text that reflects the change in status.

dotlrn portlet:

- The "(--|++)" links are read as "dash dash plus plus" by a screenreader. anyhow, the purpose of those links is not obvious. Provide a text link or a meaningful title, don't just use ASCII chars. The best thing would be to use icons with their alt text.


- Recommendation: In the list of threads, mark up the subjects as headings so that a screenreader user can navigate from one thread to the next. (I don't think that template::list allows that)

- The "reply" and "forward" buttons appear before each message in the screenreader "read order". This is not useful because a screenreader user would have to navigate back past the message in order to get to these buttons. Recommendation: place these buttons after the message in the read order.

- At the beginning of each reply the arrow which has the alt text "plus" is not meaningful. Recommendation: change this alt text to "expand message" or "collapse message" depending on the status.

Thanks for reading until here. Looking forwards to your comments.

Posted by Dave Bauer on
These all sound pretty good. I think all could be classified as "bug fix" level of work, and be applied to a bug fix release say dotlrn 2.4.1.
Posted by Emmanuelle Raffenne on
I will spend this week working on those accessibility issues. I was hoping to include those for dotlrn packages in the 2.4.0 release since it still is in alpha and core is not released yet. I'll bring it up at honchos meeting.
Posted by Dave Bauer on
Good point! If its just dotlrn packages, and are bug fixes. The only question is how much testing is required.
Posted by Emmanuelle Raffenne on
They are mainly changes in the markup and CSS so the testing would be to check that it's still valid html strict, the layout is correct in the most used browsers, say IE FF Safari Opera?, and the CSS are valid.

Since the list is long and I have only 1 week, I won't have time to do all of it but I'll try to do as much as I can.

Posted by Don Baccus on
We'll discuss this at honchos, but my thinking is to do as much as you can, and after one week we can discuss releasing .lrn 2.4.0 beta1 (assuming we can release core this week!) or spending more time if necessary.
Posted by Raúl Morales Hidalgo on
I'm re-ordering assessment portlet for our install, I'll keep in mind to comply with your above points. I'll post my changes on the forums later this week.
Posted by Michael Cordova on
About forums, I've already done some of those changes... an even more. (I'm writing a long list of new enhancements... I'm slow, but I hope it could be finished soon).

I've uploaded some screenshots to file-storage: Forums Enhancements. For instance, the "reply" button after the message on message-new-reply sample.

About headings for message titles, is possible, just with a "title pretty". I've use bold on titles to highlight new messages (and new responses to messages, I mean, you can see if a thread has news even when it's collapsed)

About the collapse and expand message, I've done in a different way, although I'm not happy about my change, the actual "collapse" function should be replaced (I think) to meet the the main idea is what you said.

I've added a lot of catalog keys, I mean, there are new keys, of course, but I've also reviewed the actual i18n and found a few plain text strings that I've added to catalog.

Another issue about validation, not only on forums but elsewhere, is html id's: AFAIK it's not recommended id's to be only numbers, so, I have replaced id="12345" as id="messsage-12345", and I added some id's to divs that hadn't anyone, for instance, somethink like... id="collapse-wrapper-12345", id="collapse-button-12345", and so on.

Posted by Emmanuelle Raffenne on
Hi all,

Here is a list of what I've finally done and committed at the 5-4 branch so it will go into .LRN 2.4:

- Forms

  • put the "required" indication inside the label tag
  • moved the error message at the top of the widget
  • highligh the form element causing error


  • Provided an accessibility page and moved the stylesheet switcher there (STD/HC)
  • The "skip to main content" is always visible
  • Added a "You are here" before the breadcrumbs. The text is invisible and will be only read by screenreaders
  • changed accesskeys of the main tabs to use numbers


  • Put the icons of the "select view" bar into the CSS
  • Added a label for the date in the form of mini-calendar
  • Improved mini-calendar, day, week and month views: added headers and associated them with days. Used current day/week/month as caption
  • Created a HC stylesheet for calendar
  • Provided better link titles

- File storage:

  • Added column headers where they were missing
  • Improved contrast of the filename in the folder-chunk

- Assessment:

  • Added column header where they were missing

- dotlrn main portlet:

  • Provided a meaningful link title for "(--|++)"

- Forums:

  • In the list of threads, marked up the subjects as heading
  • Moved the "reply", "forward" etc. buttons after the content of the message in the read order
  • Improved the alt text of expand/collapse icon of the messages, added a title to the link and made both change according to the display status (collapsed or expanded)
Posted by Emmanuelle Raffenne on
I forgot something in Calendar: fixed the display of events over different timezones and languages (was broken).
Posted by Michael Cordova on
I'd like to contribute a few changes about html validation.

I've asked OCT for a CVS account by email. Meanwhile, how can I contribute? Shall I post a bug on bugtracker, and then upload a patch?

One more thing, I tried to replace & in url's by amp's "& amp" (without space), in order to avoid validation warnings ( but AOLServer doesn't seem to like that change. The question is, Is that an accessibilty error?

Posted by Dave Bauer on
The URLs should be generated with [export vars] and placed in a tcl variable. The tcl variable should be referred to in the ADP file. In this way, the & will be escaped automatically.
Posted by Emmanuelle Raffenne on
Hi Miguel,

The use of "&" instead of "&" is not an accessibility requirement but a HTML specification. It doesn't invalidate the HTML though, only reports a warning. However it's recommended to have them correctly encoded.

As Dave said, to get URLs correctly encoded, use the [export_vars -base $base_url $var_list].