Moodle
  1. Moodle
  2. MDL-31976

editing links have title attribute, and img has duplicate alt/title text

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.9.17, 2.2.2
    • Fix Version/s: 2.2.6, 2.3.3
    • Component/s: Accessibility
    • Labels:
    • Database:
      Any
    • Testing Instructions:
      Hide

      Test pre-requisites

      • Javascript disabled
      • A course with some activities and resources in different sections

      Test steps

      1. As an admin, go to a course and turn editing on
      2. Inspect the icons in the sections and
        • Make sure they don't have a title, if the parent DOM element already has one
        • Make sure the alt is present, but only empty when the image is not important
        • Make sure mousing over those icons the title of the parent DOM (<a>) is displayed as a tooltip
      3. Repeat the test with Javascript enabled
      Show
      Test pre-requisites Javascript disabled A course with some activities and resources in different sections Test steps As an admin, go to a course and turn editing on Inspect the icons in the sections and Make sure they don't have a title, if the parent DOM element already has one Make sure the alt is present, but only empty when the image is not important Make sure mousing over those icons the title of the parent DOM (<a>) is displayed as a tooltip Repeat the test with Javascript enabled
    • Affected Branches:
      MOODLE_19_STABLE, MOODLE_22_STABLE
    • Fixed Branches:
      MOODLE_22_STABLE, MOODLE_23_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-31976-master
    • Rank:
      38644

      Description

      Editing links, such as 'editing_show' have a title e.g. "Show" which is shown on hover, and read by screen readers.

      The images (class="iconsmall") within these links also have alt text and titles e.g. "Show" - which is also shown on hover (some browsers) and read by screen readers.

      The title attribute should only be applied to the link element. The alt text and title on the icon are unnecessary.

      When users of screen readers encounter this they hear "Show show", "Delete delete", "Move move", etc...

      These links should only have the title attrib in the link, and no title or alt on the icon.
      e.g.
      <a href='foo' class='editing_delete' title='Delete'>
      <img src='path/delete.gif' alt='' />
      Delete
      </a>
      An even cleaner solution would be :
      <a href='foo' class='editing_show' title='Publish <resource title> to course'>Show</a>
      then with css :
      .commands a

      { text-indent:-9999em; }

      .editing_show

      { background: transparent url('path/show.gif') etc...}

        Issue Links

          Activity

          Hide
          Michael de Raadt added a comment -

          Thanks for reporting that.

          Is it better to have the title on the link than the alt attribute on the icon image? I suppose so.

          Show
          Michael de Raadt added a comment - Thanks for reporting that. Is it better to have the title on the link than the alt attribute on the icon image? I suppose so.
          Hide
          Stuart Lamour added a comment -

          or we could clean it up a whole lot more :

          <a href='foo' class='editing_show' title='Publish <resource title> to course'>Show</a>

          .commands a

          { text-indent:-9999em; }

          .editing_show

          { background: transparent url('path/show.gif') etc...}
          Show
          Stuart Lamour added a comment - or we could clean it up a whole lot more : <a href='foo' class='editing_show' title='Publish <resource title> to course'>Show</a> .commands a { text-indent:-9999em; } .editing_show { background: transparent url('path/show.gif') etc...}
          Hide
          Greg Kraus added a comment -

          Using the title to convey important information is problematic for screen reader users because not all screen readers actually read the title attribute. Support for the title attribute varies based on screen reader support and user configurations of their screen reader. Some screen reader software makes the user choose which one to listen to - the title attribute or the actual link text.

          Using the title attribute to display information is also problematic for keyboard-only users because the information in the title attribute is usually only revealed by hovering the mouse over it.

          If the goal here is to provide additional information about the link, there are ARIA techniques that let you accomplish similar goals. Here is an example of role="tooltip"

          http://test.cita.uiuc.edu/aria/tooltip/tooltip1.php

          This is much more accessible to many groups of people.

          Show
          Greg Kraus added a comment - Using the title to convey important information is problematic for screen reader users because not all screen readers actually read the title attribute. Support for the title attribute varies based on screen reader support and user configurations of their screen reader. Some screen reader software makes the user choose which one to listen to - the title attribute or the actual link text. Using the title attribute to display information is also problematic for keyboard-only users because the information in the title attribute is usually only revealed by hovering the mouse over it. If the goal here is to provide additional information about the link, there are ARIA techniques that let you accomplish similar goals. Here is an example of role="tooltip" http://test.cita.uiuc.edu/aria/tooltip/tooltip1.php This is much more accessible to many groups of people.
          Hide
          Stuart Lamour added a comment -

          Greg - using the pattern :

          <a href='foo' class='editing_show' title='Publish <resource title> to course'>Show</a>

          .commands a

          { text-indent:-9999em; }

          .editing_show

          { background: transparent url('path/show.gif') etc...}

          i'm unsure how or where additional accessibility info is needed?

          Show
          Stuart Lamour added a comment - Greg - using the pattern : <a href='foo' class='editing_show' title='Publish <resource title> to course'>Show</a> .commands a { text-indent:-9999em; } .editing_show { background: transparent url('path/show.gif') etc...} i'm unsure how or where additional accessibility info is needed?
          Hide
          Greg Kraus added a comment -

          Here's what each screen reader will say with the suggested implementation.

          JAWS with IE: "show link"
          JAWS with Firefox: "show link publish resource title to course"
          NVDA with Firefox: "link show"
          VoiceOver with Safari: "link show publish resource title to course"
          ChromeVox with Chrome: "show publish resource title to course link"

          It needs to be noted that JAWS with IE can be configured to read different parts of the link, but it basically comes down to having to read either the on-screen text or the title attribute. The user normally does not have both pieces of information read to them.

          Another way screen reader users will browse a page is by reading a list of all of the available links on the page. This is what the screen readers will read for this link in the suggested implementation.

          JAWS with IE: "show"
          JAWS with Firefox: "Show"
          NVDA with Firefox: "Show"
          VoiceOver with Safari: "Publish resource title to course"
          ChromeVox with Chrome: "publish resource title to course"

          It needs to be noted that while in the suggested implementation VoiceOver and ChromeVox don't even read the link text "show" in this situatuation, when the title attribute is absent both screen readers do simply say "Show" instead.

          The end result is that the title attribute is handled inconsistently across screen reader/browser combinations which is why it is recommended to always include all of the pertinent information in the actual link text, even if it's hidden off screen, and not rely on the title attribute.

          I hope this helps.

          Show
          Greg Kraus added a comment - Here's what each screen reader will say with the suggested implementation. JAWS with IE: "show link" JAWS with Firefox: "show link publish resource title to course" NVDA with Firefox: "link show" VoiceOver with Safari: "link show publish resource title to course" ChromeVox with Chrome: "show publish resource title to course link" It needs to be noted that JAWS with IE can be configured to read different parts of the link, but it basically comes down to having to read either the on-screen text or the title attribute. The user normally does not have both pieces of information read to them. Another way screen reader users will browse a page is by reading a list of all of the available links on the page. This is what the screen readers will read for this link in the suggested implementation. JAWS with IE: "show" JAWS with Firefox: "Show" NVDA with Firefox: "Show" VoiceOver with Safari: "Publish resource title to course" ChromeVox with Chrome: "publish resource title to course" It needs to be noted that while in the suggested implementation VoiceOver and ChromeVox don't even read the link text "show" in this situatuation, when the title attribute is absent both screen readers do simply say "Show" instead. The end result is that the title attribute is handled inconsistently across screen reader/browser combinations which is why it is recommended to always include all of the pertinent information in the actual link text, even if it's hidden off screen, and not rely on the title attribute. I hope this helps.
          Hide
          Stuart Lamour added a comment - - edited
          Show
          Stuart Lamour added a comment - - edited seems to be tied into http://tracker.moodle.org/browse/MDL-34080 blog post about resolving this - http://blogs.sussex.ac.uk/elearningteam/2012/08/22/moodle-icons/
          Hide
          Frédéric Massart added a comment -

          I am pushing some patches for peer review.

          The suggested solution in the description is probably the best approach but it needs a huge refactoring of the way we are using icons (see MDL-34080). Also, keeping the <img> but adding some text in the <a> tag did not convince me, please comment on this is you think that it is highly required.

          As the <a> tags don't contain any text, the alt attribute is still required and that's the reason why I kept it in the patch. Regarding the title, I removed it anywhere where the icon was wrapped in an other DOM element which contained a title describing the action.

          I have also added missing alt where I found them, and removed the title generated on the fly using Javascript. You will notice that I removed the alt from the resource/activity names, that is because this image is not required, a <span> with accesshide class already describes the type of activity/resource.

          Here is the logic I used to tell if a title/alt was required:

          Is it a loss if the image is not displayed?
          - No?
              The alt can/should probably be empty
              The title is not recommended
          - Yes?
              The alt has to be present
              The title is optional
          
          Is the image wrapped around a DOM element using title?
          - No?
              The title can be used. But it is recommended to set it on the parent DOM element if it is an <a>.
          - Yes?
              Does the title of the parent DOM element describe the action of the image?
              - Yes?
                  The image does not need a title
              - No?
                  Is there some text content wrapped in the parent that describs the action provided by the image?
                  - Yes?
                      The image title is redundant, and not recommended. The image itself is probably not required either
                      and the alt has probably been set to empty.
                  - No?
                      Then the image is required with a verbose alt, the title is
                      a personal choice, and should preferably been set on the parent DOM element if it is an <a>.
          

          Please comment on this logic if you don't agree with it.

          Show
          Frédéric Massart added a comment - I am pushing some patches for peer review. The suggested solution in the description is probably the best approach but it needs a huge refactoring of the way we are using icons (see MDL-34080 ). Also, keeping the <img> but adding some text in the <a> tag did not convince me, please comment on this is you think that it is highly required. As the <a> tags don't contain any text, the alt attribute is still required and that's the reason why I kept it in the patch. Regarding the title, I removed it anywhere where the icon was wrapped in an other DOM element which contained a title describing the action. I have also added missing alt where I found them, and removed the title generated on the fly using Javascript. You will notice that I removed the alt from the resource/activity names, that is because this image is not required, a <span> with accesshide class already describes the type of activity/resource. Here is the logic I used to tell if a title/alt was required: Is it a loss if the image is not displayed? - No? The alt can/should probably be empty The title is not recommended - Yes? The alt has to be present The title is optional Is the image wrapped around a DOM element using title? - No? The title can be used. But it is recommended to set it on the parent DOM element if it is an <a>. - Yes? Does the title of the parent DOM element describe the action of the image? - Yes? The image does not need a title - No? Is there some text content wrapped in the parent that describs the action provided by the image? - Yes? The image title is redundant, and not recommended. The image itself is probably not required either and the alt has probably been set to empty. - No? Then the image is required with a verbose alt, the title is a personal choice, and should preferably been set on the parent DOM element if it is an <a>. Please comment on this logic if you don't agree with it.
          Hide
          Stuart Lamour added a comment -

          seems very logical Frédéric.

          For most icons in moodle a css icon based on the class of the link is best. This means semantic class names which would be a great bonus for most designers.

          Tim Hunt (who i have added to the watch list) has some good thoughts on the code for activity icons.

          Show
          Stuart Lamour added a comment - seems very logical Frédéric. For most icons in moodle a css icon based on the class of the link is best. This means semantic class names which would be a great bonus for most designers. Tim Hunt (who i have added to the watch list) has some good thoughts on the code for activity icons.
          Hide
          Adrian Greeve added a comment -

          Hi,

          Code looks good.
          All comments are correctly punctuated.
          Test instructions are easy to follow.
          My testing produced the desired result.
          I can't find anything wrong.

          Show
          Adrian Greeve added a comment - Hi, Code looks good. All comments are correctly punctuated. Test instructions are easy to follow. My testing produced the desired result. I can't find anything wrong.
          Hide
          Sam Hemelryk added a comment -

          Hi Fred,

          Two things caught my eye about your changes:

          1. https://github.com/FMCorz/moodle/compare/MDL-31976-master#L1L1616 Removing $modulename from the icon seems like you are losing information there. That provides the module type to those who can not see the icon. There is no other guaranteed way to know what the module is when the icon is not seen by the looks.
          2. https://github.com/FMCorz/moodle/compare/MDL-31976-master#L0R172 I immediately notice that this is going to use editsummary as the title attribute on the link and the alt attribute on the image within it. Having read the discussion about I'm still not clear, is this desired. I would have thought that would have been read out twice?

          I've left this in integration at the moment to allow you to reply.

          Many thanks
          Sam

          Show
          Sam Hemelryk added a comment - Hi Fred, Two things caught my eye about your changes: https://github.com/FMCorz/moodle/compare/MDL-31976-master#L1L1616 Removing $modulename from the icon seems like you are losing information there. That provides the module type to those who can not see the icon. There is no other guaranteed way to know what the module is when the icon is not seen by the looks. https://github.com/FMCorz/moodle/compare/MDL-31976-master#L0R172 I immediately notice that this is going to use editsummary as the title attribute on the link and the alt attribute on the image within it. Having read the discussion about I'm still not clear, is this desired. I would have thought that would have been read out twice? I've left this in integration at the moment to allow you to reply. Many thanks Sam
          Hide
          Frédéric Massart added a comment -

          Hi Sam,

          1. Again, this is really subjective but I sort of agree with you. I removed $modulename because $altname will contain the name of the module if it not present in the activity title. What I didn't think about was that this information is not displayed to anyone, unless using a screenreader. I guess we here have to chose whether we want the information to be spoken twice with a screenreader or assuming that the visual users will identify the module if the icon is not displayed. I think I should put the modulename back in there.

          2. I think this should not be a problem as IMO titles should be used on <a> and an <img> should have an alt. But I might have chosen a better alt text there, probably just 'Edit' as it is an icon and the title describes the action performed while clicking on it.

          We're probably better off reopening this issue.

          Thanks Sam.

          Show
          Frédéric Massart added a comment - Hi Sam, 1. Again, this is really subjective but I sort of agree with you. I removed $modulename because $altname will contain the name of the module if it not present in the activity title. What I didn't think about was that this information is not displayed to anyone, unless using a screenreader. I guess we here have to chose whether we want the information to be spoken twice with a screenreader or assuming that the visual users will identify the module if the icon is not displayed. I think I should put the modulename back in there. 2. I think this should not be a problem as IMO titles should be used on <a> and an <img> should have an alt. But I might have chosen a better alt text there, probably just 'Edit' as it is an icon and the title describes the action performed while clicking on it. We're probably better off reopening this issue. Thanks Sam.
          Hide
          Sam Hemelryk added a comment -

          Hi Fred,

          1. Hehe nothing subjective about that, I was unaware of the mashing going on in alttext, given the module name IS guaranteed to be there I am happy on this point.
          2. Ok as long as that is the plan good as gold.

          I've integrated this now. Given you thought changing the icon alt to edit for point 2 was a good idea and one that I agree with I've made that change during integration.

          Many thanks
          Sam

          Show
          Sam Hemelryk added a comment - Hi Fred, Hehe nothing subjective about that, I was unaware of the mashing going on in alttext, given the module name IS guaranteed to be there I am happy on this point. Ok as long as that is the plan good as gold. I've integrated this now. Given you thought changing the icon alt to edit for point 2 was a good idea and one that I agree with I've made that change during integration. Many thanks Sam
          Hide
          Jason Fowler added a comment -

          Worked fine Fred!

          Show
          Jason Fowler added a comment - Worked fine Fred!
          Hide
          Dan Poltawski added a comment -

          Congratulations, you've done it!

          Nf n erjneq sbe fhpprfshy vagrtengvba vagb guvf jrrxf eryrnfr, V pna abj qvfpybfr gb lbh gur rkvfgnapr bs shapgvba fge_ebg13(), gb tb va lbhe gbbyxvg nybat jvgu uggc://cuc.arg/znahny/ra/shapgvba.tmtrgff.cuc

          Cyrnfr qb abg nyybj guvf vasbezngvba gb cnff shegure.

          Show
          Dan Poltawski added a comment - Congratulations, you've done it! Nf n erjneq sbe fhpprfshy vagrtengvba vagb guvf jrrxf eryrnfr, V pna abj qvfpybfr gb lbh gur rkvfgnapr bs shapgvba fge_ebg13(), gb tb va lbhe gbbyxvg nybat jvgu uggc://cuc.arg/znahny/ra/shapgvba.tmtrgff.cuc Cyrnfr qb abg nyybj guvf vasbezngvba gb cnff shegure.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: