Kategori
Web Accessibility

Emoticons in Accessibility Perspective

Diperbarui 14 Juli 2010 oleh Dani Iswara

How should we use emoticons on the Web? Web Content Accessibility Guidelines (WCAG) version 2.0 has this answer. Emoticons include ASCII characters arranged to form facial expressions or other pictures to communicate an emotion. Sometimes it is confusing for blind users. Text-based content is still needed by screen readers. It is recommended to use proper alternative text (alt). The simple words 'smile' for :) and 'laugh' for :D are enough. Emoticons are already turned off on this unessential weblog.

I have no real screen reader to test. But Fangs–screen reader emulator, a Firefox extension–may read :) text as colon right paren (parenthesis), not smile. And :D will be heard as colon D.

This post is also a respond to Adi Kharisma–rismaka.net–post titled (in bahasa Indonesia) Alasan tidak Memasang Emoticon.

Here is a complete recommendation by WCAG 2.0 related to this topic.
Checkpoint H86: Providing text alternatives for ASCII art, emoticons, and leetspeak, noted that in general:

User Agent and Assistive Technology Support Notes

  • Assistive technologies provide different levels of support for speaking title attributes. Some do not include features that allow users to access information provided via the title attribute.
  • Implementing this technique with the title attribute is only sufficient if the title attribute is accessibility supported. The content of the title attribute needs to be available to all keyboard users (not only those with text-to-speech software) for this attribute to be accessibility supported.
  • JAWS 6.2 and higher and WindowEyes 5.0 and higher support the abbr and acronym elements. They can all be set to speak the title attribute when these elements are encountered, but this is not the default setting and is often not turned on by users.
  • Many graphical user agents render text enclosed within an abbr or acronym element with a dotted line below or surrounding it. In addition, when the mouse hovers over the element, the expansion is displayed as a tool tip.
  • In Internet Explorer 7 and below, items marked using the abbr element are not displayed with any additional formatting. For IE 6 and below, the expanded version does not display as a tooltip when the mouse hovers over the item.
  • Within a given user agent or assistive technology, abbr and acronym elements are presented to users in the same way.

If you were looking for the Flash related, read this FLASH28: Providing text alternatives for ASCII art, emoticons, and leetspeak in Flash (WCAG 2.0).

Related to my post titled (in bahasa Indonesia) Logisnya Konten via Emulator Screen Reader, please use the correct punctuation in the content.
Example: “I love your smile :smile:”. Redundancy.

Then, keep on context logically. Example: “I will [gun icon here] you!” What is the right alt?

  • “I will [...alt="icon of pistol"...] you!”
  • “I will [...alt="pistol"...] you!”
  • I will [...alt="shoot"...] you!

My conclusion is, until user agents and assistive technologies supported, better to use a logical text (semantic manner) in context for this case properly.

12 tanggapan untuk “Emoticons in Accessibility Perspective”

Atau screen reader-nya yang belum dikembangkan maksimal?

Daripada nanti malah muncul ikon-ikon karakter yang tidak dipahami karena penggunaan berbagai karakter emotikon yang dinonaktifkan, sepert :evil: :rose: :shoot: dan lain sebagainya, bukannya lebih baik fitur ini diaktifkan?

Memang ada orang yang tidak bisa melihat lebah yang hinggap mencari madu di antara bunga-bunga kebun, tapi bukan berarti bunga-bunga itu mesti dipangkas dan menggantinya dengan pengeras suara yang nyaring bersuara “kumbang hingga di atas bunga” kan?

Kemanusiaan bukan hanya meliputi empati pada apa mereka yang tidak bisa merasakan apa yang tidak dapat kita rasakan, namun juga pada mereka yang bisa sama-sama merasakan, dan pada apa yang tidak bisa kita rasakan namun bisa dirasakan oleh orang lain.

Coba yang mengerti aksesibilitas menyumbang ide dan kode sumber sesuai untuk desain emotikon dan termasuk juga alih bahasanya, sehingga bisa disentuh lebih luas lagi.

Dunia ini luas, dan kadang tidak semua bisa sampai pada kita dengan baik. Bahkan ketika kita bisa melihat dengan baik pun, tidak semuanya dapat kita tangkap dengan seutuhnya.

Emotikons mewakili pelbagai ekspresi sebuah bahasa tulisan, sesuatu yang tidak bisa ditangkap hanya sekadar melalui tulisan saja. Bahkan surat cinta pun banyak emotikons-nya bukan? Seperti &heart; dan lain sebagainya.

Lalu kenapa dalam morse dan sejenisnya tidak ada emotikons? Mengapa dalam berkas formal tidak ada emotikons? Mengapa dalam blog ini tidak emotikons?

He he…, nanti malah kepanjangan :smile: (ga ada emotikons-nya).

Cahya,
tanggapan yang sangat menarik. Terima kasih.

Kalau terkait dengan fitur 'screen reader'-nya, jawaban sepertinya mengarah ke standardisasi.

Memang ada orang yang tidak bisa melihat lebah yang hinggap mencari madu di antara bunga-bunga kebun, tapi bukan berarti bunga-bunga itu mesti dipangkas dan menggantinya dengan pengeras suara yang nyaring bersuara “kumbang hinggap di atas bunga” kan?

Dalam konteks di atas, bukan dipangkas! Tapi cukup ada orang lain yang bertindak selaku 'screen reader' mendeskripsikan situasi tersebut.

Dalam morse dan sejenisnya tidak ada emotikons? Bukan sandi dong namanya!

Mengapa dalam berkas formal tidak ada emotikons? Mungkin bisa saja jika ada fiturnya (dan diijinkan).

Jika emotikon diaktifkan, alt sebaiknya memakai teks seperti yang dipakai sistem 'smileys' WordPress. Pertimbangan lain mengaktifkannya atau tidak, ya seperti yang ditulis Mas Adi tersebut. Bagi saya: 'bandwidth' dan 'http request'!

Jadi, menurut saya, kembali ke standardisasi dan konteks, ♥ (and number nine thousand eight hundred twenty-nine).

Kadang juga terganggu saat berkomentar dengan kaskus emoticon terutama desain tema yang belum optimal.

Sementara cukup menggunakan emoticon bawaan WP.com saja (tidak bisa pasang plugin), menulis saja kadang malas, jadi belum niat beli hosting biar bisa pasang beberapa macam plugin hehe.. :D

:kabuuuuuuurrrrr: ah

agung,
terganggu bagaimana dulu? Waktu muat lambat atau integrasi tampilan ikonnya? Jika terganggu dengan emotikon, saya ‘disable’ skrip domain utama, ‘disable’ gambar. Tapi risikonya, fitur ‘reply’ jadi ‘reloading’.

Terganggu, seperti paragraf yang acak adut (mungkin yang punya lagi trial tema baru), kalau saat ‘disable’ gambar mendingan tidak usah tambah kaskus emoticon.

IMO,
Apa tidak cukup dengan emotikon standar yang ada pada mesin wordpress ?

Terkait dengan screen reader ( pembaca layar ? ), seperti kalimat awal Mas Cahya cukup menggoda untuk diulas, jangan-jangan pembaca layarnya yang belum optimal.

Pembaca layar sekelas JAWS ( yang terbaik untuk versi windows dan mahal :( ), masih belum mampu membaca emotikon dengan baik. Padahal kelahiran emotikon mungkin lebih dulu dibandingkan JAWS.

Jika pada posisi ini yang digunakan, harusnya pembaca layar yang menyesuaikan diri, bukan emotikon yang harus menyesuaikan ( tentu saja emotikon standar, bukan seperti emotikon kaskus ). CMIIW

Pak Aldy,
ah sialan…makin kritis komentarnya.

Menurut Using Smileys-nya WordPress.org, jika mengetikkan emotikon memakai format teks penuh (misal :smile:) dan tampilan ikon emotikon diaktifkan di sisi pengelola, ada peluang masih aksesibel. Karena teks yang kita ketik itu akan muncul sebagai atribut alt-nya.

Seandainya peranti ‘screen reader’ tersebut ‘open source’, mungkin lain masalahnya?

[OOT] logfiles:

[15-Jul-2010 11:35:47] PHP Warning:  [eAccelerator] Can not create shared memory area in Unknown on line 0
[15-Jul-2010 11:35:47] PHP Fatal error:  Unable to start eAccelerator module in Unknown on line 0

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *

Situs ini menggunakan Akismet untuk mengurangi spam. Pelajari bagaimana data komentar Anda diproses.