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”
perhaps like this?
:)
ardianzzz,
yes, but title attribute is not fully accessible colon smile colon or smile here.
It should be there, before the dot/punctuation.
Ah ribet!
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.
Dalam konteks di atas, bukan dipangkas! Tapi cukup ada orang lain yang bertindak selaku 'screen reader' mendeskripsikan situasi tersebut.
Bukan sandi dong namanya!
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 atributalt
-nya.Seandainya peranti ‘screen reader’ tersebut ‘open source’, mungkin lain masalahnya?
[OOT] Sorry. Server problem, I think. No response from IdWebSpace.com!
kirain lagi nge-raya-in CSS naked day :p
[OOT] logfiles: