Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-72822

Fix accessibility problems in reportbuilder

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Fixed
    • 4.0
    • 4.0
    • Report builder
    • MOODLE_400_STABLE
    • MOODLE_400_STABLE
    • Hide

      Prerequisites

      1. axe DevTools browser extension

      Setup

      1. Navigate to Reports > Report builder > Custom reports in site administration
      2. Press "New report" button
      3. Set any report name.
      4. Set Report source to "Users"
      5. Ensure "Include default setup" is checked
      6. Press Save

      Accessibility checker test

      1. On the report's Editor tab, run axe DevTools.
      2. Confirm you don't get the following errors:
        • Certain ARIA roles must contain particular children
        • Certain ARIA roles must be contained by particular parents
        • <li> elements must be contained in a <ul> or <ol>
        • Heading levels should only increase by one
      3. Switch to the Audience tab
      4. Add one or two audience criteria (e.g. All users)
      5. Run the axe DevTools again.
      6. Confirm you don't get the above errors.
        • _Note:* You may get ARIA role errors related to the autocomplete element when you add "Assigned system role", "Manually added users", and/or "Member of cohort" but these are related to the autocomplete element itself. So ignorable.
      7. Confirm you don't get the duplicate ID errors
      8. Save at least one audience criterion (e.g. the All users audience)"
      9. Switch to the Access tab. You'll see the users who can see the report (the report audience)
      10. Run the axe DevTools again
      11. Confirm that you don't get the errors mentioned on the Editor part of the test.

      Check focus after performing actions

      1. Click on "Settings > Conditions"
      2. Click on "Select a condition..." and add a new condition
      3. Confirm that after adding the condition the focus in on "Select a condition..." selector
      4. Click on "Settings > Filters"
      5. Click on "Select a filter..." and add a new filter
      6. Confirm that after adding the filter the focus in on "Select a filter..." selector
      7. Click on "Settings > Sorting"
      8. Click on "Enable sorting for column 'Full name'" checkbox
      9. Confirm that after enabling the sorting the focus in on the checkbox
      10. Click on the arrow icon on the left of the checkbox to change the ordering direction
      11. Confirm that after changing the ordering the focus is on the arrow icon
      12. Click on "No aggregation" in the "Full name" column header and select "Count" aggregation
      13. Confirm that after applying the aggregation the focus is on the "Count" aggregation selector
      Show
      Prerequisites axe DevTools browser extension Setup Navigate to Reports > Report builder > Custom reports in site administration Press "New report" button Set any report name. Set Report source to "Users" Ensure "Include default setup" is checked Press Save Accessibility checker test On the report's Editor tab, run axe DevTools. Confirm you don't get the following errors: Certain ARIA roles must contain particular children Certain ARIA roles must be contained by particular parents <li> elements must be contained in a <ul> or <ol> Heading levels should only increase by one Switch to the Audience tab Add one or two audience criteria (e.g. All users) Run the axe DevTools again. Confirm you don't get the above errors. _Note:* You may get ARIA role errors related to the autocomplete element when you add "Assigned system role", "Manually added users", and/or "Member of cohort" but these are related to the autocomplete element itself. So ignorable. Confirm you don't get the duplicate ID errors Save at least one audience criterion (e.g. the All users audience)" Switch to the Access tab. You'll see the users who can see the report (the report audience) Run the axe DevTools again Confirm that you don't get the errors mentioned on the Editor part of the test. Check focus after performing actions Click on "Settings > Conditions" Click on "Select a condition..." and add a new condition Confirm that after adding the condition the focus in on "Select a condition..." selector Click on "Settings > Filters" Click on "Select a filter..." and add a new filter Confirm that after adding the filter the focus in on "Select a filter..." selector Click on "Settings > Sorting" Click on "Enable sorting for column 'Full name'" checkbox Confirm that after enabling the sorting the focus in on the checkbox Click on the arrow icon on the left of the checkbox to change the ordering direction Confirm that after changing the ordering the focus is on the arrow icon Click on "No aggregation" in the "Full name" column header and select "Count" aggregation Confirm that after applying the aggregation the focus is on the "Count" aggregation selector

    Description

      Check every page and interaction in reportbuilder component and fix any accesibility issue that could appear.

       

      Apart from that, we need to address all these comments Jun left on MDL-72588

      Accessibility

      Headings
      1. It would be good to add a heading for the tab panels, even as sr-only headings. This can help screen reader users who navigate by headings to easily reach the tab panel if there's a heading available for the tab panel.
      core/dynamic_tabs
      1. This is pre-existing, but since the ul element has been assigned the "tablist" role, the li element is being seen by accessibility checkers as missing its parent ul element. We should add "role="none"" to this element to override its native role.
      core_reportbuilder/toggle_card
      1. (Also pre-existing) I don't think that the div containing the card body needs to be labelled by its heading. We only need to label these div containers if they serve as a landmark for the page (e.g. they are assigned with an ARIA landmark role).
      core_reportbuilder/local/audience/form
      1. I think that it would be appropriate to enclose the card's title in a heading element (e.g. h3, then styled as h4 or h5). This would also help screen reader users to easily navigate the forms via their respective headings.
      2. Instead of adding the disabled class to the edit-audience and delete-audience icons, it would be better to set the disabled attribute. Keyboard-only users might get confused if they land on these disabled buttons and do not know that they are supposed to be disabled.
      3. It would be more appropriate to render the edit and delete audience as buttons. Rendering them as buttons (e.g. as <button type="button">), especially if you assign them the "btn btn-link" (and optionally "btn-icon") classes, will make it easier for users with accessibility needs to easily click on them as this styling increases the clickable area of the buttons. Keyboard-only users can also activate these buttons using the space key as well.
      4. When adding multiple audiences (e.g. Assigned system roles then Manually added users), duplicate IDs can exist. Unless the form instance div's ID is being used in JS, I don't think it's necessary to have this ID.
      5. There's also no need for the form div to be set as labelled by the title div.

       

      Also we need to address the comment Shamim left on MDL-72952

      1. At the moment there is an accessibility issue on the editor tab. If you click on the 'delete column' icon in one of the columns and then click on the cancel button in the confirmation dialogue, you'll lose the focus. The focus should go back to the element that triggered the dialogue (in this case the 'delete column' icon). We have a similar issue when clicking on any of the 'move' icons. Another issue is that the 'delete column' link does not have the proper focus outline (see screenshot-1). I agree that this is out of the scope of the current issue, but please create a follow-up issue so we don't forget this.

      Attachments

        1. screenshot-1.png
          screenshot-1.png
          20 kB
        2. MDL-72822-checker-step11.png
          MDL-72822-checker-step11.png
          104 kB
        3. MDL-72822-checker-step2.png
          MDL-72822-checker-step2.png
          97 kB
        4. MDL-72822-checker-step6-7.png
          MDL-72822-checker-step6-7.png
          137 kB
        5. MDL-72822-focus-step11.png
          MDL-72822-focus-step11.png
          6 kB
        6. MDL-72822-focus-step13.png
          MDL-72822-focus-step13.png
          5 kB
        7. MDL-72822-focus-step9.png
          MDL-72822-focus-step9.png
          6 kB
        8. MDL-72822-focus-step3.png
          MDL-72822-focus-step3.png
          10 kB
        9. MDL-72822-focus-step6.png
          MDL-72822-focus-step6.png
          7 kB

        Issue Links

          Activity

            People

              mikelmartíncorrales Mikel Martín Corrales
              mikelmartíncorrales Mikel Martín Corrales
              Paul Holden Paul Holden
              Jun Pataleta Jun Pataleta
              Michael Hawkins Michael Hawkins
              Carlos Castillo, David Matamoros, Mikel Martín Corrales, Paul Holden
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                19/Apr/22

                Time Tracking

                  Estimated:
                  Original Estimate - 0 minutes
                  0m
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 day, 5 hours, 10 minutes
                  1d 5h 10m