Details

    • Testing Instructions:
      Hide

      This issue should be tested in diferent browsers/environments

      1. Modal windows
        1. Go to the frontpage and click Backup
        2. Click the Cancel button
        3. The scope of the focused elements SHOULD be limited to the modal window, you can try it clicking the Tab button several times. Other elements depending on the browser (like the code inspector) could also be focused, the important thing to test is that the main moodle layout can not be accessed
        4. Go to a course and enable editing mode
        5. Click Add an activity or resource (only in 23 and master have activity chooser, not applicable to 22)
        6. The scope of the focused elements SHOULD be limited to the modal window, you can try it clicking the Tab button several times. Other elements depending on the browser (like the code inspector) could also be focused, the important thing to test is that the main moodle layout can not be accessed
        7. Inspect the close button of the panel header, it SHOULD have a 'Close' title
        8. Click on the 'Close' button, if the whole moodle page is long enough to have a scroll the right-side vertical scroll SHOULD be restored
      2. Non modal windows
        1. Go to a course with manual enrolments enabled
        2. Go to the course administration -> users -> enrolled users
        3. Click Enrol users button
        4. The focus SHOULD be on the Assign roles element (only in 23 and master)
        5. If you inspect the HTML of the select element you SHOULD see a label assigned to it
        6. Go to site administration -> users -> accounts -> cohorts, and create a couple of cohorts with any user
        7. Go to a course and course administration -> Users -> Enrolment methods
        8. Add cohort sync method and select one of the cohorts you have created
        9. Go to course administration -> users -> enrolled users
        10. Click Enrol cohort
        11. The focus SHOULD be on the assign roles select element (only in 23 and master)
        12. If you inspect the HTML of the select element you SHOULD see a label assigned to it
        13. Login as an admin and go to the frontpage
        14. Enable editing mode and add the community finder block
        15. Click Search on the community finder block
        16. Browse courses until you find a course with a preview image on the right side
        17. Click on the image, the focus SHOULD be in the close button, so if you click space/enter after clicking on the image the image SHOULD be closed (only in 23 and master)
        18. Click again on the image and inspect the header of the opened panel
        19. The image text SHOULD be wrapped in a H1 tag
        20. Browse courses until you find a course with comments
        21. Click on 'Comments (N)', the focus SHOULD be in close button, so if you click space/enter after clicking on the image the image SHOULD be closed (only in 23 and master)
        22. Click again on 'Comments (N)' and inspect the header of the opened panel
        23. The 'Comments (N)' text SHOULD be wrapped in a H1 tag
      3. ARIA attributes (test with a screen reader if possible) (only in master)
        1. Open a screen reader
        2. Login as admin
        3. Go the frontpage or any course and click Backup
        4. Click Cancel button
        5. If you inspect the modal window you SHOULD see role = dialog and aria-labelledby = moodle-dialogue-N-header-text, where N is a number
        6. Depending on the software and the browser used you would hear the content of the modal window
        7. Try the same with different browsers
      Show
      This issue should be tested in diferent browsers/environments Modal windows Go to the frontpage and click Backup Click the Cancel button The scope of the focused elements SHOULD be limited to the modal window, you can try it clicking the Tab button several times. Other elements depending on the browser (like the code inspector) could also be focused, the important thing to test is that the main moodle layout can not be accessed Go to a course and enable editing mode Click Add an activity or resource (only in 23 and master have activity chooser, not applicable to 22) The scope of the focused elements SHOULD be limited to the modal window, you can try it clicking the Tab button several times. Other elements depending on the browser (like the code inspector) could also be focused, the important thing to test is that the main moodle layout can not be accessed Inspect the close button of the panel header, it SHOULD have a 'Close' title Click on the 'Close' button, if the whole moodle page is long enough to have a scroll the right-side vertical scroll SHOULD be restored Non modal windows Go to a course with manual enrolments enabled Go to the course administration -> users -> enrolled users Click Enrol users button The focus SHOULD be on the Assign roles element (only in 23 and master) If you inspect the HTML of the select element you SHOULD see a label assigned to it Go to site administration -> users -> accounts -> cohorts, and create a couple of cohorts with any user Go to a course and course administration -> Users -> Enrolment methods Add cohort sync method and select one of the cohorts you have created Go to course administration -> users -> enrolled users Click Enrol cohort The focus SHOULD be on the assign roles select element (only in 23 and master) If you inspect the HTML of the select element you SHOULD see a label assigned to it Login as an admin and go to the frontpage Enable editing mode and add the community finder block Click Search on the community finder block Browse courses until you find a course with a preview image on the right side Click on the image, the focus SHOULD be in the close button, so if you click space/enter after clicking on the image the image SHOULD be closed (only in 23 and master) Click again on the image and inspect the header of the opened panel The image text SHOULD be wrapped in a H1 tag Browse courses until you find a course with comments Click on 'Comments (N)', the focus SHOULD be in close button, so if you click space/enter after clicking on the image the image SHOULD be closed (only in 23 and master) Click again on 'Comments (N)' and inspect the header of the opened panel The 'Comments (N)' text SHOULD be wrapped in a H1 tag ARIA attributes (test with a screen reader if possible) (only in master) Open a screen reader Login as admin Go the frontpage or any course and click Backup Click Cancel button If you inspect the modal window you SHOULD see role = dialog and aria-labelledby = moodle-dialogue-N-header-text, where N is a number Depending on the software and the browser used you would hear the content of the modal window Try the same with different browsers
    • Affected Branches:
      MOODLE_21_STABLE
    • Fixed Branches:
      MOODLE_22_STABLE, MOODLE_23_STABLE, MOODLE_24_STABLE
    • Pull from Repository:
    • Pull 2.4 Branch:
    • Pull Master Branch:
      MDL-30899_master
    • Rank:
      33907

      Description

      Modal windows need to be implemented consistently to help ensure assistive technology users can interact effectively with the window.

      Modal windows are a tough problem because assistive technologies don't fully support the ARIA attributes that help define modal windows. Every effort should be made to (1) add ARIA attributes for modal windows, (2) properly set the focus to the modal window, (3) trap the keyboard so users cannot escape the modal window, and (4) put the modal window in a place in the DOM that is easy for screen readers users to find and put a heading 1 as the first item in the modal window.

        Issue Links

          Activity

          Hide
          David Monllaó added a comment -

          This issue is composed by different actions:

          1. add ARIA attributes for modal windows
          2. properly set the focus to the modal window
          3. trap the keyboard so users cannot escape the modal window
          4. put the modal window in a place in the DOM that is easy for screen readers users to find and put a heading 1 as the first item in the modal window

          Points 1) and 2) are easy to archieve, add H1 to headers of point 4) is also easy, point 3 is more complex, moodle is currently using an overlay to create modal windows (confirms, alerts, exceptions, modchooser...) it adds a layout covering all the page to avoid user clicks, but the user can navigate through all the page with the tab button so it's not really a modal window; YUI provides a panel component (http://yuilibrary.com/yui/docs/panel) which has the same funtionality of Y.Overlay adding support for real modal windows + other things. I've talked with Sam about the Y.Overlay -> Y.Panel replacement and is ok as long as the solution is 100% backwards compatible maintaining all the APIs or it goes only in master.

          I've tried hard for having a solution for all the points of this issue also in 22 and 23. The notifiers APIs, current element ids and the UI is all maintained but there are minor CSS changes. The "yui3-skin-sam" skin of the overlay component is not defining "yui3-widget-hd", "yui3-widget-bd" nor "yui3-widget-ft", and moodle "moodle-dialogue-*" styles are cleanly applied, but the "yui3-skin-sam" skin of the panel component defines this classes and they have more priority than the moodle ones, so in order to maintain the current styles I've given more priority to moodle-dialogue classes, my backport concern about this style changes is for 3rd party themes overwritting this moodle-dialogue classes, if they are not specific enough (3 class levels, for example ".chooserdialogue .moodle-dialogue-wrap .moodle-dialogue-hd" or ".moodle-dialogue-base .moodle-dialogue-wrap .moodle-dialogue-hd") their style will be overwritten by yui3 panel styles, I leave it to integrators decision, I've added Mary Evans as a watcher in case I'm missing something else.

          The patch maintains the current lightbox config setting to specify if it's a modal window or not. YUI Panel fixes the focus on the modal window (and does not allow the user to focus outside the modal window) so I've only added a focus() on the dialogs for non-modal windows (lightbox = false) according to point 2) If the notifications (alerts, confirms...) are initiated as non-modal it should be responsability of the client code to set the focus, I've added id tags to the buttons of the alert and confirm dialogs to allow this.

          The actions are split in commits in case there are things that could not be applied to 22 and/or 23.

          For what I've seen working on this issue, moodle displays modal panels and overlays in diferent ways, most of them uses the main notifications YUI classes (lib/yui/notification) but there are others (block community comments, block community images, assign new enrol, enrolment cohort, enrolment manual...) that are implemented differently, this leads to different UI (for example enrol-cohort and enrol-manual are) duplicate code (close buttons management, loading overlays...) and accessibility problems that are hard to manage in a centralized way. Before doing anything else I think that there should be discussion about what to do, I've restricted the patch actions to solve the main accessibility problems, but I'm opening a new issue to discuss if more work should be done to centralize the management of modal windows / panels / overlays and if more overlays should become modal windows for all the advantages they have over regular overlays.

          Show
          David Monllaó added a comment - This issue is composed by different actions: add ARIA attributes for modal windows properly set the focus to the modal window trap the keyboard so users cannot escape the modal window put the modal window in a place in the DOM that is easy for screen readers users to find and put a heading 1 as the first item in the modal window Points 1) and 2) are easy to archieve, add H1 to headers of point 4) is also easy, point 3 is more complex, moodle is currently using an overlay to create modal windows (confirms, alerts, exceptions, modchooser...) it adds a layout covering all the page to avoid user clicks, but the user can navigate through all the page with the tab button so it's not really a modal window; YUI provides a panel component ( http://yuilibrary.com/yui/docs/panel ) which has the same funtionality of Y.Overlay adding support for real modal windows + other things. I've talked with Sam about the Y.Overlay -> Y.Panel replacement and is ok as long as the solution is 100% backwards compatible maintaining all the APIs or it goes only in master. I've tried hard for having a solution for all the points of this issue also in 22 and 23. The notifiers APIs, current element ids and the UI is all maintained but there are minor CSS changes. The "yui3-skin-sam" skin of the overlay component is not defining "yui3-widget-hd", "yui3-widget-bd" nor "yui3-widget-ft", and moodle "moodle-dialogue-*" styles are cleanly applied, but the "yui3-skin-sam" skin of the panel component defines this classes and they have more priority than the moodle ones, so in order to maintain the current styles I've given more priority to moodle-dialogue classes, my backport concern about this style changes is for 3rd party themes overwritting this moodle-dialogue classes, if they are not specific enough (3 class levels, for example ".chooserdialogue .moodle-dialogue-wrap .moodle-dialogue-hd" or ".moodle-dialogue-base .moodle-dialogue-wrap .moodle-dialogue-hd") their style will be overwritten by yui3 panel styles, I leave it to integrators decision, I've added Mary Evans as a watcher in case I'm missing something else. The patch maintains the current lightbox config setting to specify if it's a modal window or not. YUI Panel fixes the focus on the modal window (and does not allow the user to focus outside the modal window) so I've only added a focus() on the dialogs for non-modal windows (lightbox = false) according to point 2) If the notifications (alerts, confirms...) are initiated as non-modal it should be responsability of the client code to set the focus, I've added id tags to the buttons of the alert and confirm dialogs to allow this. The actions are split in commits in case there are things that could not be applied to 22 and/or 23. For what I've seen working on this issue, moodle displays modal panels and overlays in diferent ways, most of them uses the main notifications YUI classes (lib/yui/notification) but there are others (block community comments, block community images, assign new enrol, enrolment cohort, enrolment manual...) that are implemented differently, this leads to different UI (for example enrol-cohort and enrol-manual are) duplicate code (close buttons management, loading overlays...) and accessibility problems that are hard to manage in a centralized way. Before doing anything else I think that there should be discussion about what to do, I've restricted the patch actions to solve the main accessibility problems, but I'm opening a new issue to discuss if more work should be done to centralize the management of modal windows / panels / overlays and if more overlays should become modal windows for all the advantages they have over regular overlays.
          Hide
          David Monllaó added a comment -

          The commits are split according to the 4 described actions:

          • Point 1) According to what Petr point out in the 20 September 2012 dev chat, I've left ARIA attributes additions in a separate patch to include it only in master
            • MDL-30899 moodle-core-notification Adding ARIA attributes
          • Point 2) Focus + close button titles
            • MDL-30899 moodle-core-notification Adding focus to non modal windows
            • MDL-30899 moodle-core-notification Adding close button title for accessibility
          • Point 3) overlay to panel and references
            • MDL-30899 moodle-core-notification Replacing Y.Overlay for Y.Panel
            • MDL-30899 modchooser Changing from overlay to panel references
            • MDL-30899 block_community Changing from overlay to panel references
          • Point 4)
            • MDL-30899 moodle-core-notification Adding H1 to notifications headers
          Show
          David Monllaó added a comment - The commits are split according to the 4 described actions: Point 1) According to what Petr point out in the 20 September 2012 dev chat, I've left ARIA attributes additions in a separate patch to include it only in master MDL-30899 moodle-core-notification Adding ARIA attributes Point 2) Focus + close button titles MDL-30899 moodle-core-notification Adding focus to non modal windows MDL-30899 moodle-core-notification Adding close button title for accessibility Point 3) overlay to panel and references MDL-30899 moodle-core-notification Replacing Y.Overlay for Y.Panel MDL-30899 modchooser Changing from overlay to panel references MDL-30899 block_community Changing from overlay to panel references Point 4) MDL-30899 moodle-core-notification Adding H1 to notifications headers
          Hide
          Rajesh Taneja added a comment -

          Patch looks good, but there are few things you might want to consider:

          1. First commit there is no space between string concatenation (after and before +). You might ignore it as it's the same case in present code. Also, just wondering if -header-text can be -header as id is for h1.
          2. Second commit you have used camel case (closeButtonTitle), it seems fine for now as it goes with current coding style. But it will be nice to open another bug consider refracting this code. Also, can we use close string from editor.php lang file, rather then creating a new string? If not then you might be better off using AMOS to copy it and also create a new issue to probably have one close string in moodle.php.
          3. Third commit id_yuiconfirmyes and id_yuiconfirmno should be unique, probably a good idea to add COUNT to it.
          4. Fourth commit not sure if https://github.com/dmonllao/moodle/commit/5282e29ff2adb2c565a87b0da675b8479a141209#L1R101 id is unique
          5. Fifth commit Inconsistent space, although goes with code around it. So not sure, but personally I will leave a space. Same in https://github.com/dmonllao/moodle/commit/a03e919fb909f8018f46dfee280e50e8e651fb25#L1R12, https://github.com/dmonllao/moodle/commit/a03e919fb909f8018f46dfee280e50e8e651fb25#L2R14. You might want to add Panel in https://github.com/dmonllao/moodle/commit/a03e919fb909f8018f46dfee280e50e8e651fb25#L1R87
          6. Seventh commit Comment should start with capital letter and end with dot. https://github.com/dmonllao/moodle/commit/f096e6f6b4ca159ea3555e49d8c0f9858c721b32#L1R42
          Show
          Rajesh Taneja added a comment - Patch looks good, but there are few things you might want to consider: First commit there is no space between string concatenation (after and before +). You might ignore it as it's the same case in present code. Also, just wondering if -header-text can be -header as id is for h1. Second commit you have used camel case (closeButtonTitle), it seems fine for now as it goes with current coding style. But it will be nice to open another bug consider refracting this code. Also, can we use close string from editor.php lang file, rather then creating a new string? If not then you might be better off using AMOS to copy it and also create a new issue to probably have one close string in moodle.php. Third commit id_yuiconfirmyes and id_yuiconfirmno should be unique, probably a good idea to add COUNT to it. Fourth commit not sure if https://github.com/dmonllao/moodle/commit/5282e29ff2adb2c565a87b0da675b8479a141209#L1R101 id is unique Fifth commit Inconsistent space, although goes with code around it. So not sure, but personally I will leave a space. Same in https://github.com/dmonllao/moodle/commit/a03e919fb909f8018f46dfee280e50e8e651fb25#L1R12 , https://github.com/dmonllao/moodle/commit/a03e919fb909f8018f46dfee280e50e8e651fb25#L2R14 . You might want to add Panel in https://github.com/dmonllao/moodle/commit/a03e919fb909f8018f46dfee280e50e8e651fb25#L1R87 Seventh commit Comment should start with capital letter and end with dot. https://github.com/dmonllao/moodle/commit/f096e6f6b4ca159ea3555e49d8c0f9858c721b32#L1R42
          Hide
          David Monllaó added a comment -

          Hi Rajesh, many thanks for the review, I applied changes in most of the commented points, there is an issue already linked for further work if necessary

          1. I added the -text sufix to distinct it from the header class (moodle-dialogue-hd)
          2. Removed new string and using editor string
          3. I've added unique IDs to id_yuiconfirmyes, id_yuiconfirmno and also to id_alertconfirm; most of the time the notifications implementations loads the panels as hidden elements so there could be IDs conflicts as you pointed out
          4. This id is not modified by this issue and the current behaviour is maintained
          5. I left the current style because it was a simple word replacement not a rewrite of the module, I've changed it now. About the panel dependency I didn't added the panel module because this dependency is managed by 'moodle-core-notification', block_community modules don't know about the modules used by it's dependencies.
          6. I've added the final dot, I haven't added the first capital because it's a var
          Show
          David Monllaó added a comment - Hi Rajesh, many thanks for the review, I applied changes in most of the commented points, there is an issue already linked for further work if necessary I added the -text sufix to distinct it from the header class (moodle-dialogue-hd) Removed new string and using editor string I've added unique IDs to id_yuiconfirmyes, id_yuiconfirmno and also to id_alertconfirm; most of the time the notifications implementations loads the panels as hidden elements so there could be IDs conflicts as you pointed out This id is not modified by this issue and the current behaviour is maintained I left the current style because it was a simple word replacement not a rewrite of the module, I've changed it now. About the panel dependency I didn't added the panel module because this dependency is managed by 'moodle-core-notification', block_community modules don't know about the modules used by it's dependencies. I've added the final dot, I haven't added the first capital because it's a var
          Hide
          David Monllaó added a comment -

          Pull branches rebased

          Show
          David Monllaó added a comment - Pull branches rebased
          Hide
          Tim Hunt added a comment -

          David, I just linked a bunch of bugs to this as duplicate. The amount to two issues:

          1. When the pop-up appears, there are no aria attributes to alert a screen-reader to its appearance. (Looks like you have already fixed this.)

          2. When the pop-up appears, the focus is on the Cancel button. Therefore screen-readers just read "cancel", not the whole message. I guess the aria attributes added for 1. may fix this too. Clearly, focus on Cancel is the safe option, so if you just press enter, you do not perform some irreversible action.

          Since our dialogue is based on YUI, I am a bit surprised we have to do anything here. I would have hoped that they would already have made their widgets as accessible as possible. I guess that might come in a future YUI release.

          Show
          Tim Hunt added a comment - David, I just linked a bunch of bugs to this as duplicate. The amount to two issues: 1. When the pop-up appears, there are no aria attributes to alert a screen-reader to its appearance. (Looks like you have already fixed this.) 2. When the pop-up appears, the focus is on the Cancel button. Therefore screen-readers just read "cancel", not the whole message. I guess the aria attributes added for 1. may fix this too. Clearly, focus on Cancel is the safe option, so if you just press enter, you do not perform some irreversible action. Since our dialogue is based on YUI, I am a bit surprised we have to do anything here. I would have hoped that they would already have made their widgets as accessible as possible. I guess that might come in a future YUI release.
          Hide
          David Monllaó added a comment -

          Hi,

          I created another issue (http://tracker.moodle.org/browse/MDL-35560) for more discussion about modal windows/dialogs consistency across Moodle because this issue was growing too much and I tried hard to write code also for stable branches (it was a ARIA issue) without breaking 3rd party themes. I see that mod/quiz and question/ are using Y.YUI2.widget.Dialog, I didn't work on that, probably could be part of that.

          Here I was focused on lib/yui/notification/ and children; there is a hierarchy of classes and the focus goes to the alert 'ok' button or the confirm 'yes' button... depending on the class, but it fallsback in the close button which is labelled-by (using ARIA attributes) the window header, also the user will be trapped in the modal window.

          I've just rebased against latest master, MOODLE_23_STABLE and MOODLE_22_STABLE

          Show
          David Monllaó added a comment - Hi, I created another issue ( http://tracker.moodle.org/browse/MDL-35560 ) for more discussion about modal windows/dialogs consistency across Moodle because this issue was growing too much and I tried hard to write code also for stable branches (it was a ARIA issue) without breaking 3rd party themes. I see that mod/quiz and question/ are using Y.YUI2.widget.Dialog, I didn't work on that, probably could be part of that. Here I was focused on lib/yui/notification/ and children; there is a hierarchy of classes and the focus goes to the alert 'ok' button or the confirm 'yes' button... depending on the class, but it fallsback in the close button which is labelled-by (using ARIA attributes) the window header, also the user will be trapped in the modal window. I've just rebased against latest master, MOODLE_23_STABLE and MOODLE_22_STABLE
          Hide
          Rajesh Taneja added a comment -

          Thanks David,
          Patch looks good.

          [y] Syntax
          [y] Output
          [y] Whitespace
          [-] Language
          [-] Databases
          [y] Testing
          [-] Security
          [-] Documentation
          [y] Git
          [y] Sanity check

          Show
          Rajesh Taneja added a comment - Thanks David, Patch looks good. [y] Syntax [y] Output [y] Whitespace [-] Language [-] Databases [y] Testing [-] Security [-] Documentation [y] Git [y] Sanity check
          Hide
          Dan Poltawski added a comment -

          Hi David,

          I'm afraid in enrol/yui/notification/notification.js on 2.2 there are conflict markers in your patch.

          Show
          Dan Poltawski added a comment - Hi David, I'm afraid in enrol/yui/notification/notification.js on 2.2 there are conflict markers in your patch.
          Hide
          David Monllaó added a comment -

          Sorry Dan, is fixed now

          Show
          David Monllaó added a comment - Sorry Dan, is fixed now
          Hide
          Dan Poltawski added a comment -

          Back to david to check after rebase.

          Show
          Dan Poltawski added a comment - Back to david to check after rebase.
          Hide
          David Monllaó added a comment -

          22, 23 and master branches rebased, I've also unsuccessfully browsed a bit the sites looking for something unexpected

          Show
          David Monllaó added a comment - 22, 23 and master branches rebased, I've also unsuccessfully browsed a bit the sites looking for something unexpected
          Hide
          Dan Poltawski added a comment -

          There appears to be CSS issue on the bottom of the modchooser after pulling this.

          Show
          Dan Poltawski added a comment - There appears to be CSS issue on the bottom of the modchooser after pulling this.
          Hide
          David Monllaó added a comment -

          Was because of MDL-35959, is solved in master and 23 (no activity chooser in 22)

          Show
          David Monllaó added a comment - Was because of MDL-35959 , is solved in master and 23 (no activity chooser in 22)
          Hide
          Dan Poltawski added a comment -

          Thanks David, i've integrated this now

          Show
          Dan Poltawski added a comment - Thanks David, i've integrated this now
          Hide
          David Monllaó added a comment -

          Refining the testing instructions with branch-dependant steps according to what has been finally integrated

          Show
          David Monllaó added a comment - Refining the testing instructions with branch-dependant steps according to what has been finally integrated
          Hide
          Ankit Agarwal added a comment - - edited

          Hi David,
          I noticed following things:-

          1. On step 1.2 background scroll is possible, not sure if it should be
          2. Enrol cohort modal window's close cross has no title
          3. There was no title in community courses list preview image modal window (close cross)(2.17)
          4. Main moodle interface can be accessed by tabbing on step 2.17
          5. Main moodle interface can be accessed by tabbing on step 2.23

          Please suggest if this needs to be passed or failed.
          Thanks

          Show
          Ankit Agarwal added a comment - - edited Hi David, I noticed following things:- On step 1.2 background scroll is possible, not sure if it should be Enrol cohort modal window's close cross has no title There was no title in community courses list preview image modal window (close cross)(2.17) Main moodle interface can be accessed by tabbing on step 2.17 Main moodle interface can be accessed by tabbing on step 2.23 Please suggest if this needs to be passed or failed. Thanks
          Hide
          David Monllaó added a comment -

          Thanks Ankit:

          1.- Is not a problem, the thing is that users with accessibility problems which uses the keyboard have to be limited to the modal window, is not important if the scroll bar works or not.
          2.- Not all the moodle overlays has been switched to Y.Panel, this is not part of this issue, there is another one (MDL-35560) for further work if necessary, the testing instructions specifies what is part of this issue.
          3.- I'm not sure what you mean, the 2.17 point is about the focus and the close button and the image is not supposed to have a title, the close button is; if you mean the header it should be wrapped in a H1. I'm not sure if I have understood what you mean, please if something is not working as specified in the testing instructions tell me.
          4.- The header of the 2nd test group is "non modal windows"
          5.- The header of the 2nd test group is "non modal windows"

          Show
          David Monllaó added a comment - Thanks Ankit: 1.- Is not a problem, the thing is that users with accessibility problems which uses the keyboard have to be limited to the modal window, is not important if the scroll bar works or not. 2.- Not all the moodle overlays has been switched to Y.Panel, this is not part of this issue, there is another one ( MDL-35560 ) for further work if necessary, the testing instructions specifies what is part of this issue. 3.- I'm not sure what you mean, the 2.17 point is about the focus and the close button and the image is not supposed to have a title, the close button is; if you mean the header it should be wrapped in a H1. I'm not sure if I have understood what you mean, please if something is not working as specified in the testing instructions tell me. 4.- The header of the 2nd test group is "non modal windows" 5.- The header of the 2nd test group is "non modal windows"
          Hide
          David Monllaó added a comment -

          Now I see your edited comment about 3.-, I can see the title in the close cross, can you specify which branch and which browser are you using?

          Show
          David Monllaó added a comment - Now I see your edited comment about 3.-, I can see the title in the close cross, can you specify which branch and which browser are you using?
          Hide
          Ankit Agarwal added a comment -

          Thanks David.
          Aha I think it was cached, I didnt see the title on the close button on step 2.17. Now it is there.

          Passing
          Thanks

          Show
          Ankit Agarwal added a comment - Thanks David. Aha I think it was cached, I didnt see the title on the close button on step 2.17. Now it is there. Passing Thanks
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Changes are now upstream, thanks for your collaboration!

          If you are going to have any celebration next days, enjoy with your gang, if not, too!

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Changes are now upstream, thanks for your collaboration! If you are going to have any celebration next days, enjoy with your gang, if not, too! Ciao

            People

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

              Dates

              • Created:
                Updated:
                Resolved: