AbI-Meldestelle:
Melden Sie Barrieren im Web der Meldestelle für Webbarrieren.
Es gibt unterschiedliche Anforderungen, die an die Barrierefreiheit von Chatanwendungen gestellt werden. Wir haben hier ein paar dieser Anforderungen in einer Übersicht zusammengestellt.
Die Richtlinien des IMS-Global-Konsortiums beziehen sich auf fünf verschiedene Werkzeuge zur synchronen Kommunikation und Kollaboration:
Synchrone Textchats dienen - im Gegensatz beispielsweise zu einer sog. Shoutbox, die der asynchronen Kommunikation via Text dient - dazu, dass zwei oder mehr Menschen in Echtzeit miteinander über den Austausch von Textnachrichten kommunizieren. Damit ein solcher Textchat barrierefrei ist müssen sowohl die Textnachrichten als auch die Bedienelemente des Chats barrierefrei und zugänglich sein.
Probleme bzgl. der Zugänglichkeit und Barrierefreiheit können auftreten, wenn
Die Zugänglichkeit von Chatanwendungen kann durch folgende Maßnahmen verbessert werden:
Quelle:
http://www.webaim.org/articles/archives/chats/
In diesem Artikel des Projekts "Web Accessibility in Mind" (WebAIM) wird zwischen Chats auf Grundlagen des Protokolls "Internet Relay Chat" (IRC), webbasierten Chats und Instant Messengern (IM) wie ICQ unterschieden.
Folgende Anforderungen werden in dem Artikel an eine barrierefreie Chatanwendung gestellt:
Quelle
http://groups.google.com/group/mozilla.dev.accessibility/browse_thread/thread/d3b676373ec544a0/915293b5b818a102?lnk=gst&q=chat+accessibility&rnum=2#915293b5b818a102
In einer Diskussion in der Usenet-Gruppe mozilla.dev.accessibility wurde Anfang des Jahres 2007 die Frage diskutiert, wie sich Screenreader im Umgang mit Chat- und Instant-Messaging-Anwendungen verhalten sollten bzw. wie diese Anwendungen aufbereitet werden müssen, damit Screenreader-Nutzerinnen und -Nutzer damit arbeiten können. Folgende Aussagen stammen aus dieser Diskussion.
Yes, as long as that means the beginning of the most recent message, not the end of it. If I'm reading the chat log and start typing, does the focus switch to the window in which I am entering text? This would be a good default (assistive technologies generally allow the review position, e.g., the location of the braille window, to be disconnected from the system cursor if desired, and this can be useful at times in chat applications).
Also, if a new message is appended to the chat log while I'm reading an earlier message, will the focus shift to the new message? My preference would for "no shift" in this situation, by default, but maybe some users would like the new message to receive focus as soon as it appears.
[...] but if I am only focused on the input window, I'd like a quick way to read the newest information. It would also be helpful to be able to identify any message I want to read in the log. I'd be able to list them by namme or time stamp or whatever and move among them. I might want to read more than the newest content. I might also want to just hear the new stuff as it comes in.
You want to hear a message as it comes in irrespective of your context,
you want the ability to turn the above off in the case of excessively chatty buddies.
More generally, the combination of "automatically speak messages" and "selectively turn off buddies" needs to be customizable together; as an example, an alternative work habit might be to turn off auto speaking of *all* messages, and selectively turn on special buddies.
In all cases, you need an auditory alert as a message comes in (separate from speaking the message).
You need a global kbd shortcut to jump to the last buddy who talked to you and that you haven't responded yet. In general the above commands works off of the ring of pending buddies, pushing the buddy you just jumped to the end of the queue. Finally, you need a means of quickly finding out all the buddies who have messaged you while you were AFK when you return; in Emacspeak this information is placed at the end of the mode-line output.