Moodle
  1. Moodle
  2. MDL-24613

Accesshide class can cause problems in Safari/VoiceOver (apparently)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.9.9
    • Fix Version/s: 1.9.11, 2.0.2
    • Component/s: Accessibility
    • Labels:
      None
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE, MOODLE_20_STABLE
    • Rank:
      15427

      Description

      "...However, when I tried it in VoiceOver, I discovered he was
      correct. As soon as you reach a "week" indicator, like "Week 1", a window
      would appear at the top left of the screen and Safari/VoiceOver would be stuck.
      I had to kill the VoiceOver process to get it back.
      [...]
      I then realized
      that the problematic area was embedded in a span with a CSS class of
      "accesshide". Removing the span with its class from the page solved the
      problem. It was the CSS class that was somehow at fault. "

      To summarise, the tutor who reported this found that by making the number 10,000 instead of 100,000 this stopped Safari breaking. Yay 16-bit integer?

      I found a related problem when making accesshide links appear, which is that sometimes the browser scrolls to top. It is better to use left or right for this approach. Moodle code was changed to use top because of RTL languages, however, this is unnecessary as we can use .dir-rtl. (Change tested in RTL language.)

        Activity

        Sam Marshall created issue -
        Hide
        Sam Marshall added a comment -

        Note I am unable to reproduce the actual problem but I guess the fix will work... (sigh). Also note that it was me who broke it in the first place! MDL-12876. (But only because somebody else switched it to 'top'...)

        Fix is:

        --- theme/standard/styles_layout.css	1 Oct 2010 19:51:32 -0000	1.92
        +++ theme/standard/styles_layout.css	11 Oct 2010 10:10:42 -0000
        @@ -522,10 +522,13 @@
         /*Accessibility: text 'seen' by screen readers but not visual users. Fixed for RTL languages, example Farsi. */
         .accesshide {
           position:absolute;
        -  top:-100000px;
        -  left:10px;
        +  left:-10000px;
           font-weight:normal;
           font-size:1em;
        +}
        +.dir-rtl .accesshide {
        +  right:-10000px;
        +  left:auto;
         }
        

        Tested on English, Hebrew to check it didn't add scrollbars.

        Will apply to 1.9, 2.0 unless somebody objects?

        Show
        Sam Marshall added a comment - Note I am unable to reproduce the actual problem but I guess the fix will work... (sigh). Also note that it was me who broke it in the first place! MDL-12876 . (But only because somebody else switched it to 'top'...) Fix is: --- theme/standard/styles_layout.css 1 Oct 2010 19:51:32 -0000 1.92 +++ theme/standard/styles_layout.css 11 Oct 2010 10:10:42 -0000 @@ -522,10 +522,13 @@ /*Accessibility: text 'seen' by screen readers but not visual users. Fixed for RTL languages, example Farsi. */ .accesshide { position:absolute; - top:-100000px; - left:10px; + left:-10000px; font-weight:normal; font-size:1em; +} +.dir-rtl .accesshide { + right:-10000px; + left:auto; } Tested on English, Hebrew to check it didn't add scrollbars. Will apply to 1.9, 2.0 unless somebody objects?
        Hide
        Sam Marshall added a comment -

        affected files:

        1.9
        theme/standard/styles_layout.css
        2.0
        theme/base/style/core.css

        Show
        Sam Marshall added a comment - affected files: 1.9 theme/standard/styles_layout.css 2.0 theme/base/style/core.css
        Hide
        Sam Marshall added a comment -

        Awesome, I got some better details, now I can reproduce this - it only happens on a specific page (in ou moodle) - however it does seem to be that the accesshide is the cause of it, so I think still worth changing if possible (we don't know which other specific pages it might affect in standard moodle under certain conditions - this wasn't a code thing, I mean, it's only like, a specific course's version of the specific page).

        crashes browser and comes dame close to crashing the machine (took ages for me to get the force close window to come up).

        Show
        Sam Marshall added a comment - Awesome, I got some better details, now I can reproduce this - it only happens on a specific page (in ou moodle) - however it does seem to be that the accesshide is the cause of it, so I think still worth changing if possible (we don't know which other specific pages it might affect in standard moodle under certain conditions - this wasn't a code thing, I mean, it's only like, a specific course's version of the specific page). crashes browser and comes dame close to crashing the machine (took ages for me to get the force close window to come up).
        Hide
        Tim Hunt added a comment -

        If we suspect 16-bit ints are the cause, what about using 20000 or 30000? Not that it really matters. Seems OK to commit to me. Might be worth making a post in the themes forum to alert more people to this issue.

        Show
        Tim Hunt added a comment - If we suspect 16-bit ints are the cause, what about using 20000 or 30000? Not that it really matters. Seems OK to commit to me. Might be worth making a post in the themes forum to alert more people to this issue.
        Hide
        Sam Marshall added a comment -

        fix verified: after the changes above, it does not crash browser (and is read out OK).

        Show
        Sam Marshall added a comment - fix verified: after the changes above, it does not crash browser (and is read out OK).
        Hide
        Sam Marshall added a comment -

        Fix applied to MOODLE_19 and HEAD

        Show
        Sam Marshall added a comment - Fix applied to MOODLE_19 and HEAD
        Sam Marshall made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 1.9.10 [ 10407 ]
        Resolution Fixed [ 1 ]
        Hide
        Sam Marshall added a comment -

        As per Tim's suggestion, forum thread added here:

        http://moodle.org/mod/forum/discuss.php?d=159891

        Show
        Sam Marshall added a comment - As per Tim's suggestion, forum thread added here: http://moodle.org/mod/forum/discuss.php?d=159891
        Martin Dougiamas made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        QA Assignee nobody
        Martin Dougiamas made changes -
        Workflow jira [ 39441 ] MDL Workflow [ 65812 ]
        Hide
        Shamim Rezaie added a comment -

        It adds a very long unnecessary horizontal scrollbar on RTL pages on Google Chrome.
        was there any special reason for setting a negative value for left(right) instead of top?

        Show
        Shamim Rezaie added a comment - It adds a very long unnecessary horizontal scrollbar on RTL pages on Google Chrome. was there any special reason for setting a negative value for left(right) instead of top?
        Shamim Rezaie made changes -
        Resolution Fixed [ 1 ]
        Status Closed [ 6 ] Reopened [ 4 ]
        Hide
        Sam Marshall added a comment -

        Yes - the reason for using left/right instead of top is that if there is a link which has accesshide and becomes visible when you tab to it, then when you do tab to it, sometimes the browser scrolls up to the top of the page which is obviously really unhelpful. This doesn't happen with left/right.

        Also if we are trying not to use 'top' value less than about -30,000 to avoid this crash, then a very very long page might get messed up.

        I have just checked it and can confirm the bug in Chrome RTL. It works correctly in Firefox. However there is also a similar bug in IE7 and IE8 RTL (although in this case it's just frankly wrong as the scroll is to wrong side, and it doesn't reveal the hidden text like it does in Chrome...)

        Maybe in this case it would be preferable to take the slight accessibility hit, in RTL languages only, and use the top: -30000 or whatever (hopefully avoiding crash).

        Show
        Sam Marshall added a comment - Yes - the reason for using left/right instead of top is that if there is a link which has accesshide and becomes visible when you tab to it, then when you do tab to it, sometimes the browser scrolls up to the top of the page which is obviously really unhelpful. This doesn't happen with left/right. Also if we are trying not to use 'top' value less than about -30,000 to avoid this crash, then a very very long page might get messed up. I have just checked it and can confirm the bug in Chrome RTL. It works correctly in Firefox. However there is also a similar bug in IE7 and IE8 RTL (although in this case it's just frankly wrong as the scroll is to wrong side, and it doesn't reveal the hidden text like it does in Chrome...) Maybe in this case it would be preferable to take the slight accessibility hit, in RTL languages only, and use the top: -30000 or whatever (hopefully avoiding crash).
        Hide
        Sam Marshall added a comment -

        I have tested a change which sets top:-30000 in RTL languages only (normal mode still uses left -10000).

        using an RTL language to test, this appears to work (= not cause scrollbars or other visible problems) on IE7, IE8, Firefox 3.6, and Chrome (latest release).

        -30000 instead of -100000 (previous) is because this is still in 16-bit range so there's some chance it hopefully won't crash safari w. voiceover in whatever situation made it crash last time.

        As noted change does not affect 'normal' (LTR) languages, where nobody has reported any problem.

        I filed pull requests for this change to be applied in 1.9 and 2.0 branches, these are PULL-35 and PULL-36.

        Show
        Sam Marshall added a comment - I have tested a change which sets top:-30000 in RTL languages only (normal mode still uses left -10000). using an RTL language to test, this appears to work (= not cause scrollbars or other visible problems) on IE7, IE8, Firefox 3.6, and Chrome (latest release). -30000 instead of -100000 (previous) is because this is still in 16-bit range so there's some chance it hopefully won't crash safari w. voiceover in whatever situation made it crash last time. As noted change does not affect 'normal' (LTR) languages, where nobody has reported any problem. I filed pull requests for this change to be applied in 1.9 and 2.0 branches, these are PULL-35 and PULL-36.
        Eloy Lafuente (stronk7) made changes -
        Link This issue will be resolved by PULL-35 [ PULL-35 ]
        Eloy Lafuente (stronk7) made changes -
        Link This issue will be resolved by PULL-36 [ PULL-36 ]
        Hide
        Eloy Lafuente (stronk7) added a comment -

        Passed test. Voiceover didn't break and visually everything seemed ok.

        Side note: I got some strange jumps to top (both in rtl and ltr) with voiceover enabled under safari when clicking on the section titles. Not sure if that is normal or no. Not reproducible with voiceover disabled.

        Closing as fixed, thanks!

        Show
        Eloy Lafuente (stronk7) added a comment - Passed test. Voiceover didn't break and visually everything seemed ok. Side note: I got some strange jumps to top (both in rtl and ltr) with voiceover enabled under safari when clicking on the section titles. Not sure if that is normal or no. Not reproducible with voiceover disabled. Closing as fixed, thanks!
        Eloy Lafuente (stronk7) made changes -
        Status Reopened [ 4 ] Closed [ 6 ]
        Fix Version/s 1.9.11 [ 10410 ]
        Fix Version/s 2.0.2 [ 10421 ]
        Fix Version/s 1.9.10 [ 10407 ]
        Resolution Fixed [ 1 ]
        QA Assignee nobody
        Martin Dougiamas made changes -
        Workflow MDL Workflow [ 65812 ] MDL Full Workflow [ 95159 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: