Moodle

Moodle pages have bad performance with older versions of the screenreader JAWS

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 1.8
  • Fix Version/s: 2.0.8
  • Component/s: Accessibility
  • Labels:
    None
  • Environment:
    JAWS versions 7.0, 6.20, 6.10, 6.0, 5.10, 5.0 and 4.51, running in Windows XP on a 1.4GHz Pentium M
  • Affected Branches:
    MOODLE_18_STABLE
  • Fixed Branches:
    MOODLE_20_STABLE

Description

Older versions of the screenreader JAWS hang and become unresponsive for several seconds when the user does anything of the following on a Moodle page:

  • Loads, reloads or jumps back to the page through the history
  • Follows a link to an anchor within the same page
  • Activates a script that modifies the page contents
  • Brings up the JAWS list of links-dialog

This makes Moodle-usage very cumbersome.

The problem is caused by large stylesheets.

Any web page that has enough stylesheet code exhibits the same problems. More stylesheet code causes longer delays. The delay is significant even on relatively fast computers.

Attachments

  1. File
    screenreader-css-minimizer.php
    10/Aug/07 11:26 PM
    3 kB
    Nicklas Lindgren
  2. Text File
    screenreader-styles.patch
    10/Aug/07 10:59 PM
    2 kB
    Nicklas Lindgren
  3. Text File
    screenreader-styles-r2.patch
    21/Aug/07 2:10 AM
    2 kB
    Nicklas Lindgren
  4. File
    styles_screenreader.css
    10/Aug/07 10:59 PM
    0.3 kB
    Nicklas Lindgren

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Nicklas Lindgren added a comment - - edited

Attached a proposed patch to solve the problem.

Forum thread in http://moodle.org/mod/forum/discuss.php?d=77723

Show
Nicklas Lindgren added a comment - - edited Attached a proposed patch to solve the problem. Forum thread in http://moodle.org/mod/forum/discuss.php?d=77723
Hide
Permalink
Nicklas Lindgren added a comment -

Attached the tool used to make the stylesheet.

Show
Nicklas Lindgren added a comment - Attached the tool used to make the stylesheet.
Hide
Permalink
Nick Freear added a comment -

Hi Nicklas.
Thanks for reporting this. I have some questions:

  • Is this a problem in JAWS 7 (as implied by "Environment" section above)? I've tried skipping the Course News block (that is, an anchor within the same page) without problems on JAWS 7 on Internet Explorer 6/ XP Professional.
  • When JAWS "hangs and becomes unresponsive" what is your browser doing? (I accept it may be hard to tell what your browser is doing, if you're relying on JAWS!) Are you using Internet Explorer 6?
  • As you say the stylesheets are large - BUT they should be cached for 10 minutes in IE6 and other browsers, see this old bug MDL-5099 (We may need to look at this again). How do you know that stylesheets are the problem?

A slight modification for weblib.php, theme_setup function:
if (empty($USER->screenreader))
TO
if (empty($USER->screenreader) || $USER->screenreader==0)

Your patch basically works in terms of mechanics (though we'd want to look at the many 'display:none' again!)
but a) the 'screenreader' setting on the user profile is undocumented, and I'm wary of using it, and b) I think that some screenreader users do care about visual styles - if you have low vision instead of complete blindness, or if you're a non-native speaker using a screenreader to help with pronunciation, etc.

Thanks, Nick

Show
Nick Freear added a comment - Hi Nicklas. Thanks for reporting this. I have some questions:
  • Is this a problem in JAWS 7 (as implied by "Environment" section above)? I've tried skipping the Course News block (that is, an anchor within the same page) without problems on JAWS 7 on Internet Explorer 6/ XP Professional.
  • When JAWS "hangs and becomes unresponsive" what is your browser doing? (I accept it may be hard to tell what your browser is doing, if you're relying on JAWS!) Are you using Internet Explorer 6?
  • As you say the stylesheets are large - BUT they should be cached for 10 minutes in IE6 and other browsers, see this old bug MDL-5099 (We may need to look at this again). How do you know that stylesheets are the problem?
A slight modification for weblib.php, theme_setup function: if (empty($USER->screenreader)) TO if (empty($USER->screenreader) || $USER->screenreader==0) Your patch basically works in terms of mechanics (though we'd want to look at the many 'display:none' again!) but a) the 'screenreader' setting on the user profile is undocumented, and I'm wary of using it, and b) I think that some screenreader users do care about visual styles - if you have low vision instead of complete blindness, or if you're a non-native speaker using a screenreader to help with pronunciation, etc. Thanks, Nick
Hide
Permalink
Nicklas Lindgren added a comment -

> - Is this a problem in JAWS 7 (as implied by "Environment" section
> above)? I've tried skipping the Course News block (that is, an
> anchor within the same page) without problems on JAWS 7 on
> Internet Explorer 6/ XP Professional.

It is a problem in 7.0 but it is fixed in 7.10 (and 8.0 for that matter).

> - When JAWS "hangs and becomes unresponsive" what is your browser
> doing? (I accept it may be hard to tell what your browser is
> doing, if you're relying on JAWS!) Are you using Internet Explorer
> 6?

As far as i can tell, nothing.

The page is already rendered correctly before the delays. Neither JAWS nor IE consumes any significant amount of CPU-time when this happens.

> - As you say the stylesheets are large - BUT they should be cached
> for 10 minutes in IE6 and other browsers, see this old bug
> MDL-5099 (We may need to look at this again). How do you know that
> stylesheets are the problem?

The stylesheets are not downloaded any more often than usual, the delays are not caused by waiting for network traffic.

By removing the links to the stylesheets completely from moodle pages, the problem also disappears. Also you can cause the same problem on any webpage by linking in a stylesheet filled with 7000 css rulesets.

Therefore a large stylesheet is a necessary and sufficient condition for causing this problem.

A large stylesheet in this case is one with many css rulesets. The css-rulesets may be empty and they don't have to apply to any elements in the webpage. But a troublesome stylesheet with all code commented
out do not cause these problems.

> A slight modification for weblib.php, theme_setup function:
> if (empty($USER->screenreader))
> TO
> if (empty($USER->screenreader) || $USER->screenreader==0)

Thanks! I updated the patch.

> but a) the 'screenreader' setting on the user profile is
> undocumented, and I'm wary of using it, and

Another solution is to implement it as a theme. We have done both.

> b) I think that some screenreader users do care about visual styles
> - if you have low vision instead of complete blindness, or if you're
> a non-native speaker using a screenreader to help with
> pronunciation, etc.

That concerns me too. I have no exhaustive knowledge of how screenreaders are used.

Show
Nicklas Lindgren added a comment - > - Is this a problem in JAWS 7 (as implied by "Environment" section > above)? I've tried skipping the Course News block (that is, an > anchor within the same page) without problems on JAWS 7 on > Internet Explorer 6/ XP Professional. It is a problem in 7.0 but it is fixed in 7.10 (and 8.0 for that matter). > - When JAWS "hangs and becomes unresponsive" what is your browser > doing? (I accept it may be hard to tell what your browser is > doing, if you're relying on JAWS!) Are you using Internet Explorer > 6? As far as i can tell, nothing. The page is already rendered correctly before the delays. Neither JAWS nor IE consumes any significant amount of CPU-time when this happens. > - As you say the stylesheets are large - BUT they should be cached > for 10 minutes in IE6 and other browsers, see this old bug > MDL-5099 (We may need to look at this again). How do you know that > stylesheets are the problem? The stylesheets are not downloaded any more often than usual, the delays are not caused by waiting for network traffic. By removing the links to the stylesheets completely from moodle pages, the problem also disappears. Also you can cause the same problem on any webpage by linking in a stylesheet filled with 7000 css rulesets. Therefore a large stylesheet is a necessary and sufficient condition for causing this problem. A large stylesheet in this case is one with many css rulesets. The css-rulesets may be empty and they don't have to apply to any elements in the webpage. But a troublesome stylesheet with all code commented out do not cause these problems. > A slight modification for weblib.php, theme_setup function: > if (empty($USER->screenreader)) > TO > if (empty($USER->screenreader) || $USER->screenreader==0) Thanks! I updated the patch. > but a) the 'screenreader' setting on the user profile is > undocumented, and I'm wary of using it, and Another solution is to implement it as a theme. We have done both. > b) I think that some screenreader users do care about visual styles > - if you have low vision instead of complete blindness, or if you're > a non-native speaker using a screenreader to help with > pronunciation, etc. That concerns me too. I have no exhaustive knowledge of how screenreaders are used.
Hide
Permalink
Nicklas Lindgren added a comment -

Current usage of the Screen reader setting seems to be usability improvements for users that are completely blind (removes the tabular layout for the calendar, etc).

Ideally the setting should have a better name, and should probably be connected to other profile settings that are appropriate to make when using this, such as making sure the HTML-editor is turned off.

Also, it might be appropriate to ask the users about these settings as part of the signup process.

There are other settings you also might consider in addition to this, such as picking a theme with high contrast and large fonts.

Show
Nicklas Lindgren added a comment - Current usage of the Screen reader setting seems to be usability improvements for users that are completely blind (removes the tabular layout for the calendar, etc). Ideally the setting should have a better name, and should probably be connected to other profile settings that are appropriate to make when using this, such as making sure the HTML-editor is turned off. Also, it might be appropriate to ask the users about these settings as part of the signup process. There are other settings you also might consider in addition to this, such as picking a theme with high contrast and large fonts.
Hide
Permalink
Wen Hao Chuang added a comment -

by the way have anyone tested this issue with moodle 1.9? Just wondering. Thanks!

Show
Wen Hao Chuang added a comment - by the way have anyone tested this issue with moodle 1.9? Just wondering. Thanks!

People

Vote (2)
Watch (3)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Moodle. Try JIRA - bug tracking software for your team.