Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.9.5
    • Fix Version/s: 2.0
    • Labels:
      None
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE
    • Rank:
      35825

      Description

      This is what screen reader users hear when reading past the help icon when posting a new discussion topic: "Read carefully, Write carefully, Ask good questions, How to write text and Use emoticons."

      This was often interpreted as paternalistic advice, and never understood as a help icon. Other help icons on that page are much better; e.g., "Help with About formatting text (new window)."

      Why it matters

      Verbosity is one of the prime enemies of screen reader users; anything that sounds like it might not be directly related to the task at hand is usually skipped. Labels starting with "Help" were more likely to attract attention and less likely to be frustrating.
      Possible solution

      Every help icon's ALT attribute should being with, "Help with" and follow with the shortest possible description of help content. "(New window)" isn't necessary for most screen reader users, but is very helpful for vision-impaired users, where the popup may appear in an area of the screen they cannot see.

        Issue Links

          Activity

          Hide
          Sam Marshall added a comment -

          Just to comment, accessibility testers here also think this is a serious problem (this was actually found during ForumNG testing, but is a general issue). Their issue is that the text is long:

          > it was still not very easy to
          > post. The main issue here was the length of the title/alt on
          > the Help icon "Read carefully, Write carefully, Ask good
          > questions and About the HTML editor". The impact is that
          > [our tester] lost track of where he was when he heard this alt
          > between "message" and the edit field, which meant that he
          > wasn't sure when he was able to type.

          Show
          Sam Marshall added a comment - Just to comment, accessibility testers here also think this is a serious problem (this was actually found during ForumNG testing, but is a general issue). Their issue is that the text is long: > it was still not very easy to > post. The main issue here was the length of the title/alt on > the Help icon "Read carefully, Write carefully, Ask good > questions and About the HTML editor". The impact is that > [our tester] lost track of where he was when he heard this alt > between "message" and the edit field, which meant that he > wasn't sure when he was able to type.
          Hide
          Sam Marshall added a comment -

          This appears to be in weblib, function editorhelpbutton(). It selects from a whole bunch of help files which correspond to the topic heading that it's about to go to.

          My suggestion would be that we change this so that it only displays a single help text corresponding to either the 'richtext' (About the HTML editor) or 'text' (How to write text) depending on which is included, i.e. we do not display titles for the 'reading', 'writing', 'questions', 'emoticons' options. It looks to me like one or other of those options should probably be included in all situations, and users who click on the help button will see the full list of topics - which are all vaguely connected to the HTML or text editor, so the summary should be okay.

          As an added bonus this would remove one instance of broken internationalisation (the code enforces commas as separators, and finished the list by concatenating a language-string equivalent of 'and' there, which does not represent the way all languages write lists) because there would no longer be a list of things that needed joining together...

          I'm happy to code and commit this change if people agree with it, so let me know. There may be some problem with this which I didn't consider.

          Show
          Sam Marshall added a comment - This appears to be in weblib, function editorhelpbutton(). It selects from a whole bunch of help files which correspond to the topic heading that it's about to go to. My suggestion would be that we change this so that it only displays a single help text corresponding to either the 'richtext' (About the HTML editor) or 'text' (How to write text) depending on which is included, i.e. we do not display titles for the 'reading', 'writing', 'questions', 'emoticons' options. It looks to me like one or other of those options should probably be included in all situations, and users who click on the help button will see the full list of topics - which are all vaguely connected to the HTML or text editor, so the summary should be okay. As an added bonus this would remove one instance of broken internationalisation (the code enforces commas as separators, and finished the list by concatenating a language-string equivalent of 'and' there, which does not represent the way all languages write lists) because there would no longer be a list of things that needed joining together... I'm happy to code and commit this change if people agree with it, so let me know. There may be some problem with this which I didn't consider.
          Hide
          Helen Foster added a comment -

          Hi Sam,

          Thanks for your comments and your kind offer to fix this issue. +1 from me for your solution of having either the 'richtext' (About the HTML editor) or 'text' (How to write text) depending on whether the user has the html editor enabled.

          It would be great if you could fix this issue in 1.9.7 and HEAD.

          Regarding Moodle 2.0, the plan is to minimize the text in help pop-ups to just 2-3 sentences and make use of the context-sensitive Moodle Docs pages for further information. Also, help pop-ups will no longer contain any links. Thus, there shouldn't be any lists of things that need joining together.

          PS Any chance you could also reposition the help pop-up so that it is next to the HTML editor or text field, rather than after the word 'Message'?

          Show
          Helen Foster added a comment - Hi Sam, Thanks for your comments and your kind offer to fix this issue. +1 from me for your solution of having either the 'richtext' (About the HTML editor) or 'text' (How to write text) depending on whether the user has the html editor enabled. It would be great if you could fix this issue in 1.9.7 and HEAD. Regarding Moodle 2.0, the plan is to minimize the text in help pop-ups to just 2-3 sentences and make use of the context-sensitive Moodle Docs pages for further information. Also, help pop-ups will no longer contain any links. Thus, there shouldn't be any lists of things that need joining together. PS Any chance you could also reposition the help pop-up so that it is next to the HTML editor or text field, rather than after the word 'Message'?
          Hide
          Martin Dougiamas added a comment -

          Two brief notes:

          1) "paternalistic advice" --> yes, but to improve educational efficiency
          2) it made more sense when they were separate context-sensitive buttons but it all got combined by someone along the line

          Show
          Martin Dougiamas added a comment - Two brief notes: 1) "paternalistic advice" --> yes, but to improve educational efficiency 2) it made more sense when they were separate context-sensitive buttons but it all got combined by someone along the line
          Hide
          Rossiani Wijaya added a comment -

          created patch to embedded 'help with' and '(new window)' strings to the alt icon.
          regular expression is used to check the existence of these strings.

          please take a look.

          Rosie

          Show
          Rossiani Wijaya added a comment - created patch to embedded 'help with' and '(new window)' strings to the alt icon. regular expression is used to check the existence of these strings. please take a look. Rosie
          Hide
          Helen Foster added a comment -

          Hopefully this issue will be resolved by MDL-22067. However I think we still need to figure out what to do when help is combined in other help popups, for example the add an activity help popup.

          Show
          Helen Foster added a comment - Hopefully this issue will be resolved by MDL-22067 . However I think we still need to figure out what to do when help is combined in other help popups, for example the add an activity help popup.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: