Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1.1
    • Fix Version/s: 2.4
    • Component/s: Accessibility, Chat
    • Labels:
    • Testing Instructions:
      Hide
      1. Log in as Admin/teacher
      2. Go to a course and add a chat activity
      3. Click on "Click here to enter the chat now" to start chat
      4. In chat window check three sections and they should have proper header and aria attributes (Header will not be visible on screen, so check with firebug)
        1. Message-list (Top-left) should have header "Messages", aria-live="polite" and role="log"
        2. chat-userlist (Right)should have header "Participants", aria-live="polite" and aria-relevant="all"
        3. chat-input-area (bottom) should have header "Compose a message"
      5. Use a screen reader to use the chat and see if it makes sense
      Show
      Log in as Admin/teacher Go to a course and add a chat activity Click on "Click here to enter the chat now" to start chat In chat window check three sections and they should have proper header and aria attributes (Header will not be visible on screen, so check with firebug) Message-list (Top-left) should have header "Messages", aria-live="polite" and role="log" chat-userlist (Right)should have header "Participants", aria-live="polite" and aria-relevant="all" chat-input-area (bottom) should have header "Compose a message" Use a screen reader to use the chat and see if it makes sense
    • Affected Branches:
      MOODLE_21_STABLE
    • Fixed Branches:
      MOODLE_24_STABLE
    • Pull Master Branch:
      wip-mdl-30918
    • Rank:
      33926

      Description

      Make normal chat more accessible, so people can navigate easily between different sections.

      Original description
      Most chat rooms have the place to post the message at the bottom of the screen and the chat history runs in reverse order. This implementation works just fine, but it might be confusing to users who are used to the more traditional method. We could consider changing the orientation of the messages and the location of the message box.

        Activity

        Hide
        Rajesh Taneja added a comment - - edited

        Thanks for reporting this Greg,

        Are you suggestion one more chat layout? Can you please explain more about traditional chat method ?
        Also, regarding MDL-30917 and MDL-30895, one is asking for removing multiple tools and other one is asking for improving the layout.

        If we plan to change layout, then it will not be possible to fix MDL-30917, as we will require two tools. Most users still use chat rooms with text box on bottom.

        I think it will be nice to handle all these issues here, so we can come up with a nice solution. It will be helpful, if you can help summarise the requirements.

        Show
        Rajesh Taneja added a comment - - edited Thanks for reporting this Greg, Are you suggestion one more chat layout? Can you please explain more about traditional chat method ? Also, regarding MDL-30917 and MDL-30895 , one is asking for removing multiple tools and other one is asking for improving the layout. If we plan to change layout, then it will not be possible to fix MDL-30917 , as we will require two tools. Most users still use chat rooms with text box on bottom. I think it will be nice to handle all these issues here, so we can come up with a nice solution. It will be helpful, if you can help summarise the requirements.
        Hide
        Rajesh Taneja added a comment - - edited

        revisiting this and it seems your suggestion make sense.
        Although, the problem is user have to go though the whole list of messages (scroll to bottom), before user can view enter message.

        I think rather then combining two chat tools, we can re-design chat to be accessible and leave accessible chat as it is. As this might cater to certain group of people.

        Can you please help us to finalize the specifications, so that we can take it forward.

        Show
        Rajesh Taneja added a comment - - edited revisiting this and it seems your suggestion make sense. Although, the problem is user have to go though the whole list of messages (scroll to bottom), before user can view enter message. I think rather then combining two chat tools, we can re-design chat to be accessible and leave accessible chat as it is. As this might cater to certain group of people. Can you please help us to finalize the specifications, so that we can take it forward.
        Hide
        Rajesh Taneja added a comment -

        Hello Greg,

        Can you please provide some inputs on this issue, so I can take it forward.

        Show
        Rajesh Taneja added a comment - Hello Greg, Can you please provide some inputs on this issue, so I can take it forward.
        Hide
        Greg Kraus added a comment -

        Hi Rajesh,

        I guess it depends on whether the end goal is to make one chat tool that works for all people, or continue to have two chat tools, one being more accessible than the other. I think it is possible to make one chat tool that is accessible to everyone and still provide the visual layout you want.

        I'll refer to the two current chat tools as the "standard chat" and the "accessible chat".

        The standard chat can be made significantly more accessible doing two things. First, add some headings to the page. For instance, I would put three headings.

        1. Chat messages
        2. Participants
        3. Compose a message

        The headings can be off screen if they need to be. By using the headings, the screen reader user can easily jump from section to section without having to do a lot of exploring. This is pretty much the way the accessible chat is implemented.

        Second, add some ARIA attributes to the sections of the page that update, namely the chat history and the participants list.

        <div id="chat-userlist" class="box " aria-live="polite" aria-relevant="all">...</div>
        aria-live="polite" will tell the screen reader users when updates occur to the area
        aria-relevant="all" tells the screen reader to announce additions and deletions from the list

        <div id="chat-messages" class="box " role="log" aria-live="polite">...</div>
        role="log" tells the screen reader that there will be new information coming into this area in a sequential manner, and the order is important
        aria-live="polite" in this case is a shim to deal with a bug in IE and JAWS. role="log" carries an implied aria-live="polite" attribute but JAWS in IE does not recognize it so it must be explicitly stated.
        You do not need to set the aria-relevant attribute in this case because the default value for that attribute is they one we want.

        These two steps will go a long way toward making it more accessible and have no visual impact on the page.

        There could be some more work done with screen reader users to actually find what is a more usable interface for them in terms of how the chat messages are actually constructed. For example, in the current implementation of the standard chat, if the above changes are made, the screen reader user will hear something like "19:36. Greg Kraus. Hi everyone in the room, how are you doing?" From a usability perspective it is probably much more important to hear the sender's name or the message first, and the time stamp last. For a sighted user it might also be nice to not have the time stamp play such a prominent role in the UI too.

        One advantage that the accessible chat has over the standard chat is that it does control the rate at which message come in. Basically, the user chooses when to update the screen and then reads them. This is still a nice feature, but could potentially be worked into the main chat window. Some users with learning disabilities might want to control how fast the messages come in. Could there be a check box that says "Live updates", and if it is not checked, then there is a button that says "Get new messages (3)" where the number in parenthesis is the number of new messages waiting?

        Show
        Greg Kraus added a comment - Hi Rajesh, I guess it depends on whether the end goal is to make one chat tool that works for all people, or continue to have two chat tools, one being more accessible than the other. I think it is possible to make one chat tool that is accessible to everyone and still provide the visual layout you want. I'll refer to the two current chat tools as the "standard chat" and the "accessible chat". The standard chat can be made significantly more accessible doing two things. First, add some headings to the page. For instance, I would put three headings. 1. Chat messages 2. Participants 3. Compose a message The headings can be off screen if they need to be. By using the headings, the screen reader user can easily jump from section to section without having to do a lot of exploring. This is pretty much the way the accessible chat is implemented. Second, add some ARIA attributes to the sections of the page that update, namely the chat history and the participants list. <div id="chat-userlist" class="box " aria-live="polite" aria-relevant="all">...</div> aria-live="polite" will tell the screen reader users when updates occur to the area aria-relevant="all" tells the screen reader to announce additions and deletions from the list <div id="chat-messages" class="box " role="log" aria-live="polite">...</div> role="log" tells the screen reader that there will be new information coming into this area in a sequential manner, and the order is important aria-live="polite" in this case is a shim to deal with a bug in IE and JAWS. role="log" carries an implied aria-live="polite" attribute but JAWS in IE does not recognize it so it must be explicitly stated. You do not need to set the aria-relevant attribute in this case because the default value for that attribute is they one we want. These two steps will go a long way toward making it more accessible and have no visual impact on the page. There could be some more work done with screen reader users to actually find what is a more usable interface for them in terms of how the chat messages are actually constructed. For example, in the current implementation of the standard chat, if the above changes are made, the screen reader user will hear something like "19:36. Greg Kraus. Hi everyone in the room, how are you doing?" From a usability perspective it is probably much more important to hear the sender's name or the message first, and the time stamp last. For a sighted user it might also be nice to not have the time stamp play such a prominent role in the UI too. One advantage that the accessible chat has over the standard chat is that it does control the rate at which message come in. Basically, the user chooses when to update the screen and then reads them. This is still a nice feature, but could potentially be worked into the main chat window. Some users with learning disabilities might want to control how fast the messages come in. Could there be a check box that says "Live updates", and if it is not checked, then there is a button that says "Get new messages (3)" where the number in parenthesis is the number of new messages waiting?
        Hide
        Greg Kraus added a comment -

        If in the end you decide to keep two different chat UIs, I would still make the recommended changes to the "standard chat" because there will be screen reader users who want the more dynamic interface.

        Show
        Greg Kraus added a comment - If in the end you decide to keep two different chat UIs, I would still make the recommended changes to the "standard chat" because there will be screen reader users who want the more dynamic interface.
        Hide
        Rajesh Taneja added a comment -

        Thanks for the inputs Greg,

        I will add both your recommendations for standard chat. I will open another issue for accommodating checkbox, which will control live updates.

        As per keeping one chat only, at this point I think it's good to keep accessible chat as it has different layout and it might be usable.

        Show
        Rajesh Taneja added a comment - Thanks for the inputs Greg, I will add both your recommendations for standard chat. I will open another issue for accommodating checkbox, which will control live updates. As per keeping one chat only, at this point I think it's good to keep accessible chat as it has different layout and it might be usable.
        Hide
        Rajesh Taneja added a comment -

        Thanks Greg, for such a descriptive information about fixing this issue.

        I have added headers (moved out of screen) and aria attributes.

        Show
        Rajesh Taneja added a comment - Thanks Greg, for such a descriptive information about fixing this issue. I have added headers (moved out of screen) and aria attributes.
        Hide
        Rossiani Wijaya added a comment -

        This looks good Raj.

        +1 for integration.

        Show
        Rossiani Wijaya added a comment - This looks good Raj. +1 for integration.
        Hide
        Rajesh Taneja added a comment -

        Thanks Rossie,

        I am pushing it only for master, if integrators think this should be backported then please cherry pick to stable (Patch is clean BC)

        Show
        Rajesh Taneja added a comment - Thanks Rossie, I am pushing it only for master, if integrators think this should be backported then please cherry pick to stable (Patch is clean BC)
        Hide
        Dan Poltawski added a comment -

        Thanks, i've integrated this in 2.4 only.

        I tried with osx voiceover and it seemed to make some improvement, though I still don't know how to get to participants list.

        Show
        Dan Poltawski added a comment - Thanks, i've integrated this in 2.4 only. I tried with osx voiceover and it seemed to make some improvement, though I still don't know how to get to participants list.
        Hide
        Michael de Raadt added a comment -

        Test result: Success

        The elements described have been added where expected.

        I tried this with NVDA and it reflected some of the information added, but I'm not an expert user. Going on the word of Greg in that regard.

        Show
        Michael de Raadt added a comment - Test result: Success The elements described have been added where expected. I tried this with NVDA and it reflected some of the information added, but I'm not an expert user. Going on the word of Greg in that regard.
        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:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: