Hi, Greg.

Do you have a reference to information relating to ARIA attributes?

Here's my super-brief ARIA tutorial. ARIA (Accessible Rich Internet Applications) is a set of non-obtrusive attributes that can be applied to HTML elements that add additional semantic information not otherwise available through standard HTML elements. They add semantic information about document structure, how interactive elements operate, and defining how live updating sections of pages behave. Note: ARIA attributes will usually cause your code to not validate. That is OK.

• Document Structure Example

This is a common way to define the navigation area of a page.

<div id="nav"></div>

The problem is this does not provide any semantic information defining the function of this section. By adding the ARIA role attribute

<div id="nav" role="navigation"></div>

this tells assistive technologies this is the navigation section of the page. Users can then easily just jump to the navigation portion of the page. For more information on ARIA document landmarks look at these two blog posts.

http://accessibility.oit.ncsu.edu/blog/2011/06/30/using-aria-landmarks-a-demonstration/
http://www.paciellogroup.com/blog/2010/10/using-wai-aria-landmark-roles/

• Live updating sections of pages

ARIA provides numerous ways through "live regions" to define areas of a page that have live updates. This is necessary because screen readers aren't always aware of changes to the page after it has been parsed initially. There are specialized live regions like "timer" (for clocks) and there are also ways to make generalized ARIA live regions. Defining a live region does two things. First, it lets the screen reader know to watch a certain portion of a page for changes and to alert the user when the change occurs. Second, it lets you define how important a change is so the user will receive the appropriate amount of information. For example, an error message is critical and needs to be heard immediately, but a countdown timer does not necessarily need to be re-read by the screen reader after every single second ticks off.

I hesitate to put this out there because it is very much a work in progress, but here is a sample page I am making that demonstrates all of the different type of ARIA live regions.

http://accessibility.oit.ncsu.edu/training/aria/live-regions.html

I would look more at the "alert" and "general" examples.

• Interactive Elements

I'll leave this one for now since there isn't much in Moodle that falls directly into this area. The biggest thing I can readily think of is AJAX editing of courses by dragging and dropping items around the page.

Here is the W3C's information on ARIA.

http://www.w3.org/WAI/intro/aria

I find the "Authoring Practices" to be quite helpful.

This is really just scratching the surface and doesn't even answer all of the ARIA issues raised in these bugs. I'll go through the bugs and add some code samples for how to use ARIA.

Since Moodle uses the YUI library, there is a lot of ARIA already built into it. You just have to add in a few extra libraries provided by Yahoo. The main thing YUI ARIA adds to the page in this case is giving additional information about complex UI elements, like modal windows and tab panels, so that screen reader users know how to interact with it. Here is an example.

First, pretend HTML5 does not exist yet. In the pre-HTML5 world, if you wanted to make a slider (the control where you move a "knob" back and forth to increase and decrease a value) you would code something like <div id="slider-control"></div> and you would have lots of CSS and images and hundreds of line of JavaScript code to make it work. To a screen reader it ends up just being a bunch of images that it doesn't know what to do with. If you add this simple ARIA attribute <div id="slider-control" role="slider"></div>, now a screen reader says, "Oh, I know what this collection of images, CSS, and JS is. It's a slider." A screen reader knows how to deal with a slider so the control instantly becomes much more usable to the screen reader user. (There are a few extra things you need to do to, but this gives you the big picture.)

With YUI, most, if not all of the controls, have an optional ARIA library you can also call that will add in all of the necessary ARIA attributes and other necessary JS code to make it significantly more accessible. For instance, if you use a tab view from YUI (http://developer.yahoo.com/yui/tabview/) they also provide an ARIA enhanced version of it (http://developer.yahoo.com/yui/examples/tabview/tabview-ariaplugin.html). Again, this is important because without the ARIA information, the tabview is just a collection of unrelated HTML, CSS, and JS to the screen reader. Since screen reader applications know what a tabview is from desktop applications, by using ARIA to indicate this collection of HTML, CSS, and JS is really a tabview, the screen reader now knows how to interact with it.

Hi,

I've added the 'aria-haspopup' attribute to the help link. The close button behaviour has been changed by http://tracker.moodle.org/browse/MDL-28235

Thanks David,

Patch makes sense, as it reads this as "subMenu link". But once help is open, it focus on "X" close icon and no information is read.

It will be nice to have a same behaviour as Activity chooser, which adds typesummary to activity choice element.

Thanks Rajesh, the activity chooser is a form, label tags can only be used inside a form so the same approach doesn't work; a way to avoid this restriction is usign the ARIA attributes "aria-labelledby" or "aria-describedby" in the close link referencing the id of a container, but the help content is obtained through an AJAX petition, so when the close link is rendered the content is not available.

Using ARIA roles seems the best option, alert and alertdialog roles (http://www.w3.org/TR/wai-aria/roles#alert and http://www.w3.org/TR/wai-aria/roles#alertdialog) I had doubts about which one is more appropiate, because with JS help overlays we are providing the link to close the overlay, but we are also focusing the user in the close icon, on the other hand alertdialog should be modal, and that's not the case, so the provided patch uses alert role. I've also seen the status role (http://www.w3.org/TR/wai-aria/roles#status) but I've discarted it because the user is explicitly clicking on the element and this doesn't seems to be the purpose of the status role.

Patch looks good David,

Feel free to push it for integration.

Thanks for reviewing Raj

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

TIA and ciao

Rebased

Thanks David, i've integrated this now (22, 23 and master)

In 2.4 I hear "Help with description graphic sub-menu link" when I tab to the field. When I click on the help text all I hear is "click alert".

Failing this. Although it works in Chrome, it doesn't work in others when clicking the help:

Firefox = "alert"
IE9 = "link"
Safari and Opera = Moodle doesn't work at all with screen reader. Probably because of the screen reader.

Jason has a proposed fix for Firefox and IE9.

adding aria-live="assertive" when the help tip is shown should trigger the reading of the help tip, then setting it to aria-live="off" when it is hidden

Hi,

I've tried the different approaches we have discussed here in HQ with aria-live, AJAX problems... and non of them worked, the problem is related with HTML tags, Firefox is cleaning the contents inside HTML tags and the help files contents are HTML, most of them wrapping all the help content in a <p>, so as long as Firefox works this way I can't unfortunately find a way to do it work.

The attributes and the ARIA roles are well specified, but we can not control all the screen readers implementations.

Squeezed in because it passes DanP's golden rules, but not a complete fix and there is more we could have tested and done.

Congratulations, you've done it!

Thanks, this change is now in the latest weekly release!

Join the crowds of people tomorrow from 8am and download this Moodle release from your local apple store!

Applied the patch for the 2.2+ version (we are running 2.2.4+) and clicking on the category and any links now gives us the following error (caused by lib/outputrenderers.php) file

====

Coding error detected, it must be fixed by a programmer: PHP catchable fatal error

More information about this error

Debug info: Argument 4 passed to html_writer::label() must be an array, null given, called in /var/www/html/moodle/lib/outputrenderers.php on line 1237 and defined
Stack trace:
?line 365 of /lib/setuplib.php: coding_exception thrown
?line 1548 of /lib/outputcomponents.php: call to default_error_handler()
?line 1237 of /lib/outputrenderers.php: call to html_writer::label()
?line 70 of /lib/outputrenderers.php: call to core_renderer->render_single_select()
?line 210 of /course/category.php: call to renderer_base->render()