Moodle
  1. Moodle
  2. MDL-27843 META: Accessibility compliance for 2.x
  3. MDL-30847

contextual help menu is not easily accessed by screen reader users

    Details

    • Testing Instructions:
      Hide

      You will need a screen reader (like NVDA - www.nvda-project.org) to test this issue

      1. Start the screen reader
      2. Login into Moodle
      3. Go to My profile settings -> Edit profile
      4. Walk through the page elements with the tab button, when you reach a help button and you focus over it you SHOULD read / hear "expanded subMenu link"
      5. Click the help icon, you SHOULD hear (NVDA with default config.) the help message
      6. Repeat the same process with JS disabled, you SHOULD also be able to hear the help message, including if you disable JS through browser settings are the help content it's opened in the same moodle window you are in

      The behaviour must be the same for all moodle help buttons.

      Repeat the process in a visual browser and verify that everything works as expected

      Show
      You will need a screen reader (like NVDA - www.nvda-project.org) to test this issue Start the screen reader Login into Moodle Go to My profile settings -> Edit profile Walk through the page elements with the tab button, when you reach a help button and you focus over it you SHOULD read / hear "expanded subMenu link" Click the help icon, you SHOULD hear (NVDA with default config.) the help message Repeat the same process with JS disabled, you SHOULD also be able to hear the help message, including if you disable JS through browser settings are the help content it's opened in the same moodle window you are in The behaviour must be the same for all moodle help buttons. Repeat the process in a visual browser and verify that everything works as expected
    • Affected Branches:
      MOODLE_21_STABLE, MOODLE_22_STABLE, MOODLE_23_STABLE
    • Fixed Branches:
      MOODLE_22_STABLE, MOODLE_23_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-30847_master
    • Rank:
      33847

      Description

      When opening the help window, there is no notification that something has opened. It just says there is a link there and focuses on to the close graphic, which has no alt text. There are some simple ARIA attributes that can be added to this window to solve this problem.

        Issue Links

          Activity

          Hide
          Michael de Raadt added a comment -

          Hi, Greg.

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

          Show
          Michael de Raadt added a comment - Hi, Greg. Do you have a reference to information relating to ARIA attributes?
          Hide
          Greg Kraus added a comment -

          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.

          Show
          Greg Kraus added a comment - 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.
          Hide
          Greg Kraus added a comment -

          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.

          Show
          Greg Kraus added a comment - 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.
          Hide
          David Monllaó added a comment -

          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

          Show
          David Monllaó added a comment - 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
          Hide
          Rajesh Taneja added a comment -

          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.

          Show
          Rajesh Taneja added a comment - 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.
          Hide
          David Monllaó added a comment -

          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.

          Show
          David Monllaó added a comment - 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.
          Hide
          Rajesh Taneja added a comment -

          Patch looks good David,

          Feel free to push it for integration.

          Show
          Rajesh Taneja added a comment - Patch looks good David, Feel free to push it for integration.
          Hide
          David Monllaó added a comment -

          Thanks for reviewing Raj

          Show
          David Monllaó added a comment - Thanks for reviewing Raj
          Hide
          Eloy Lafuente (stronk7) added a comment -

          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

          Show
          Eloy Lafuente (stronk7) added a comment - 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
          Hide
          David Monllaó added a comment -

          Rebased

          Show
          David Monllaó added a comment - Rebased
          Hide
          Dan Poltawski added a comment -

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

          Show
          Dan Poltawski added a comment - Thanks David, i've integrated this now (22, 23 and master)
          Hide
          Tim Barker added a comment -

          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".

          Show
          Tim Barker added a comment - 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".
          Hide
          Tim Barker added a comment -

          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.

          Show
          Tim Barker added a comment - 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.
          Hide
          Jason Fowler added a comment -

          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

          Show
          Jason Fowler added a comment - 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
          Hide
          David Monllaó added a comment -

          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.

          Show
          David Monllaó added a comment - 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.
          Hide
          Tim Barker added a comment -

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

          Show
          Tim Barker added a comment - Squeezed in because it passes DanP's golden rules, but not a complete fix and there is more we could have tested and done.
          Hide
          Dan Poltawski added a comment -

          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!

          Show
          Dan Poltawski added a comment - 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!
          Hide
          Lawrence N added a comment -

          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()

          Show
          Lawrence N added a comment - 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()

            People

            • Votes:
              5 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: