451693 - Make live chat accessible using WAI-ARIA live region markup

Status: RESOLVED FIXED

(support.mozilla.org Graveyard :: Chat, defect)

Description

[Aaron Leventhal]

Mozilla's live chat can be made accessible using the same techniques we're using now in Chatzilla. Gijs Kruitbosch (CC'd) did the work on that, and can provide more details.

In this case it should be easier. I suggest putting role="log" aria-live="polite" on the chat log itself would be enough, since this is just a 2 way chat. Gijs, is that right?

Normally the extra aria-live="polite" shouldn't be necessary but screen readers don't necessarily infer politeness from role="log" as they should.

Comment 1

[:Gijs (he/him)]

(In reply to comment #0)
> Mozilla's live chat can be made accessible using the same techniques we're
> using now in Chatzilla. Gijs Kruitbosch (CC'd) did the work on that, and can
> provide more details.
> 
> In this case it should be easier. I suggest putting role="log"
> aria-live="polite" on the chat log itself would be enough, since this is just a
> 2 way chat. Gijs, is that right?

Yes, though you could make it smart and eg. emphasize messages which come in after a long time of inactivity or something of the sort. That'd be a second step though.

Right now I don't have time to look at the chat myself (I'm going to bugmail collected over 2 months of holidays, so yeah...) but I think Aaron basically said most of it anyway...

Comment 2

[:Gijs (he/him)]

So, the Live Chat uses an iframe that loads https://chat-support.mozilla.com:9091/webchat/yakframe.html

There it sticks <div class="chat-line"/>s in the ytext div that represent the message.

Each <div> has two <span>s in it, one that has the name of the person speaking (class operator-name or client-name, if it's the helper or helpee, so to speak), and one with the message (class "text").

It's an interesting system. The scripts are at:

https://chat-support.mozilla.com:9091/webchat/dwr/interface/room.js
https://chat-support.mozilla.com:9091/webchat/dwr/engine.js
https://chat-support.mozilla.com:9091/webchat/common.js

And then some. AFAICT we need to hack:
- the HTML file, to make ytext have role="log", aria-live="off", as we don't want it asserting for every message (specifically not the user's own messages)
- the common.js script, and specifically the addChatText function, to make the non-client messages have aria-live="assertive".

We may or may not want to add a flash widget to make things go "plop" or "beep" for a message in general.

I can try to do a patch for this, but:
1) do the t&c for the use of the Jive stuff allow us to hack it? They have scary copyright notices at the top of their code.
2) is there a non-production environment where I can test this?
3) Aaron/Marco, does the above sound remotely plausible?

Comment 3

[Matthew Middleton (:zzxc)]

The copyright notice on the javascript pages is outdated, all the Fastpath (and Fastpath webchat) code has been released under the GPL.  We have both a staging and a development server set up for developing Fastpath/Openfire, so you can test in this environment.

The javascript files you linked above are minimized; you should look at the readable versions in SVN.  See http://viewvc.svn.mozilla.org/vc/projects/livechat/trunk/webchat/src/webapp/

Since you know what needs to be done, I can help with testing/applying the changes in a patch.  Or, if you would prefer, I could make the patch.  Audible alerts on new messages need to be implemented in the web client; I'll file a separate bug for this.

Comment 4

[Marco Zehe (:MarcoZ)]

(In reply to comment #2)
> 3) Aaron/Marco, does the above sound remotely plausible?

Hi, you master of understatement! ;-) I believe you hit things right on the mark here. i especially like the idea to only assert those messages by the operator/helper.

Comment 5

[:Gijs (he/him)]

(In reply to comment #4)
> (In reply to comment #2)
> > 3) Aaron/Marco, does the above sound remotely plausible?
> 
> Hi, you master of understatement! ;-) I believe you hit things right on the
> mark here. i especially like the idea to only assert those messages by the
> operator/helper.

Right. I was mostly wondering about whether we would still deal with aria-live="assertive" rows being inserted if the entire table had aria-live="off"... (also wrt the official spec, dunno what that says about this)

Of course, we could do aria-live="assertive" and then aria-live="off" on the messages that we do *not* want announced, but that seems like peculiar logic to me... :-)

Matthew: cool, thanks for all the info. I'll try to whip up a patch soon (although my laptop is dying, so I'm having trouble arranging a developer environment to do large-scale stuff in because of my uni profile quota - hoping the SVN repo for this stuff is pretty small)

Comment 6

[:Gijs (he/him)]

Attachment: Patch with log as assertive

Patch using aria-live="assertive" on the log.

Comment 7

[:Gijs (he/him)]

Attachment: Patch with log as off

Patch that sets aria-live="off" on the log.

Comment 8

[:Gijs (he/him)]

Assuming I didn't screw up, this should do the trick. Marco, which do you think is best?

Comment 9

[Marco Zehe (:MarcoZ)]

Comment on attachment 362806 [details] [diff] [review]
Patch with log as off

This is the better approach, imo.

Comment 10

[Marco Zehe (:MarcoZ)]

Comment on attachment 362804 [details] [diff] [review]
Patch with log as assertive

My gutt feeling is to use aria-live="assertive" when appropriate, not as a default.

Comment 11

[:Gijs (he/him)]

Comment on attachment 362806 [details] [diff] [review]
Patch with log as off

In fact, this misses out announcements, which should also be announced (ha, ha). I'll do a new patch later today, not on a machine with svn/diff etc. installed atm... :X

Comment 12

[:Gijs (he/him)]

Attachment: Better patch

Patch that also covers announcements, and uses the role attribute rather than the aria-role attribute (oops...)

Comment 13

[:Gijs (he/him)]

Comment on attachment 362877 [details] [diff] [review]
Better patch

Presuming I'll need review from Matthew to check this in (can I even do that assuming I have a CVS SSH key, or do I need a separate one / more permission bits to check into SVN?)

Comment 14

[Matthew Middleton (:zzxc)]

Comment on attachment 362877 [details] [diff] [review]
Better patch

Looks good to me, thanks!  Everything worked when testing it on sm-chat01.

Comment 15

[Matthew Middleton (:zzxc)]

Checked in, r22782

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

Hi Marco - if you've tested this, would you mind verifying that it works?  Thanks!