Saya Menggunakan Web Selama Sehari Hanya Dengan Keyboard

Artikel ini adalah bagian dari seri di mana saya mencoba menggunakan web di bawah berbagai batasan, mewakili demografi pengguna tertentu. Saya berharap dapat mengangkat profil kesulitan yang dihadapi oleh orang-orang nyata, yang dapat dihindari jika kita merancang dan mengembangkan dengan cara yang sesuai dengan kebutuhan mereka. Terakhir kali, saya menggunakan web selama sehari tanpa JavaScript. Hari ini, saya memaksakan diri untuk menavigasi web hanya dengan menggunakan keyboard saya.

Siapa yang Menggunakan Keyboard Untuk Menavigasi?

Secara garis besar, ada tiga jenis pengguna keyboard:

• Pengguna dengan gangguan mobilitas yang kesulitan menggunakan mouse,
• Pengguna dengan gangguan penglihatan yang tidak dapat melihat elemen yang dapat diklik di halaman,
• Pengguna bertenaga yang dapat menggunakan mouse tetapi merasa lebih cepat menggunakan keyboard.

Berapa Banyak Pengguna yang Kami Bicarakan?

Saya telah menjelajahi web untuk statistik penggunaan keyboard, dan saya tidak dapat menemukan apa pun. Dengan serius. Tidak satu studi.

Sebagian besar situs panduan aksesibilitas keyboard hanya menerima begitu saja bahwa "banyak pengguna" mengandalkan keyboard untuk berkeliling. Siapa pun yang mencoba untuk mendapatkan perkiraan jumlah biasanya dibubarkan dengan “statistik tidak masalah — situs Anda harus dapat diakses, titik.”

Ya, memang benar bahwa skala penggunaan non-mouse adalah poin yang diperdebatkan. Jika Anda dapat membuat perubahan yang memberdayakan bahkan satu pengguna, itu adalah perubahan yang layak dilakukan. Tetapi ada banyak statistik yang tersedia di sekitar hal-hal seperti buta warna, penggunaan browser, kecepatan koneksi, dan sebagainya — mengapa kerumitan seputar statistik keyboard? Jika jumlahnya sama lazimnya dengan yang disarankan oleh situs, tentunya memilikinya akan memungkinkan kasus bisnis yang lebih kuat dan membuat mempertahankan aksesibilitas keyboard ke pemangku kepentingan Anda lebih mudah.

Hal yang paling dekat dengan angka yang dapat saya temukan adalah artikel di PowerMapper, yang menunjukkan bahwa 7% orang dewasa usia kerja di AS, Inggris, dan Kanada memiliki "kesulitan ketangkasan yang parah." Ini akan membuat mereka “tidak mungkin menggunakan mouse, dan lebih mengandalkan keyboard.”

Pengguna dengan gangguan penglihatan yang parah menggunakan perangkat lunak yang disebut pembaca layar, yaitu perangkat lunak yang membacakan konten di layar sebagai ucapan yang disintesis. Seperti pengguna yang dapat melihat, pengguna yang tidak dapat melihat ingin dapat memindai halaman untuk informasi menarik, sehingga pembaca layar memiliki pintasan keyboard untuk menavigasi melalui judul dan tautan, dan bergantung pada elemen yang dapat difokuskan pada keyboard untuk interaksi.

“Orang tunanetra membutuhkan akses keyboard penuh. Periode."

— David Macdonald, co-editor Menggunakan WAI ARIA di HTML5

Pengguna yang sama ini juga memiliki pembaca layar di perangkat seluler mereka, di mana mereka menggunakan gerakan menggesek alih-alih menekan keyboard untuk 'menabrak' konten. Jadi, meskipun mereka tidak benar-benar menggunakan keyboard, mereka memang mengharuskan situs untuk dapat diakses dengan keyboard karena teknologi pembaca layar terhubung ke urutan tab dan pendengar acara yang sama seolah-olah mereka menggunakan keyboard. Perlu dicatat bahwa hanya sekitar dua pertiga hingga tiga perempat pengguna pembaca layar yang buta, artinya sisanya mungkin menggunakan kombinasi pembaca layar dan teknik pembesaran.

2,3% orang Amerika (dari segala usia) memiliki cacat visual, tidak semuanya harus menjamin penggunaan pembaca layar. Pada tahun 2016, Addy Osmani memperkirakan penggunaan pembaca layar aktual sekitar 1 hingga 2%. Jika kami memperhitungkan pengguna ini dengan pengguna dengan gangguan mobilitas dan pengguna bertenaga kami, penggunaan keyboard menambah persentase yang cukup besar dari audiens global. Oleh karena itu, memperhatikan aksesibilitas keyboard tidak hanya melakukan hal yang benar secara moral (dan secara hukum — banyak negara mengharuskan situs web dapat diakses secara hukum), tetapi juga masuk akal secara bisnis.

Dengan semua itu, bagaimana keadaan web saat ini? Saatnya mencari tahu!

Percobaan

Apa yang dilakukan setiap orang ketika mereka memiliki pekerjaan yang mengintimidasi selama sehari? Menunda! Saya menuju ke youtube.com. Saya memiliki video tertentu dalam pikiran dan bersyukur menemukan bahwa saya tidak perlu masuk ke dalam kotak pencarian utama, karena difokuskan pada pemuatan halaman secara default.

Atribut autofocus

Saya berasumsi ini akan difokuskan dengan JavaScript pada pemuatan jendela, tetapi sebenarnya ditangani oleh browser dengan atribut autofocus pada elemen input.

Sebagai pengguna keyboard yang terlihat, saya menemukan ini sangat berguna. Sebagai pengguna pembaca layar buta, saya tidak yakin apakah saya akan menyukainya atau tidak. Konsensusnya tampaknya bahwa penggunaan autofocus yang bijaksana tidak masalah, dalam kasus di mana satu-satunya tujuan halaman adalah untuk berinteraksi dengan formulir (misalnya halaman arahan Google, atau formulir kontak situs).

Gaya Fokus Default

Saya mencari beberapa Garis Siapa Itu? ya ampun, dan mau tidak mau menyadari bahwa YouTube tidak mendefinisikan gaya :focus khusus apa pun, alih-alih mengandalkan gaya asli browser untuk secara visual menunjukkan elemen mana yang saya tab.

Saya selalu mendapat kesan bahwa tidak semua browser mendefinisikan :focus state mereka sendiri, jadi Anda harus menentukan gaya kustom Anda sendiri. Saya memutuskan untuk menguji ini dan melihat browser mana yang mengabaikan untuk menerapkan gaya default, tetapi yang mengejutkan saya, saya tidak dapat menemukannya. Setiap browser yang saya uji memiliki implementasi asli :focus , meskipun masing-masing memiliki gaya yang berbeda.

Saya bahkan pergi cukup jauh ke masa lalu:

Jika Anda ingin melihat lebih banyak, ada kumpulan tangkapan layar yang komprehensif dari berbagai elemen di keadaan asli peramban.

Ini memberitahu saya bahwa Anda dapat mengasumsikan bahwa setiap browser dilengkapi dengan beberapa gaya dasar :focus . Tidak apa-apa untuk membiarkan browser melakukan pekerjaan. Apa yang Anda pertaruhkan adalah inkonsistensi: semua elemen gaya browser agak berbeda, dan beberapa sangat halus sehingga tidak dapat diakses secara visual.

Dimungkinkan untuk menonaktifkan gaya fokus browser default — dengan menetapkan outline: none pada elemen Anda — tetapi Anda harus melakukan ini hanya jika Anda menerapkan alternatif gaya Anda sendiri . Heydon Pickering merekomendasikan pendekatan ini, dengan alasan default yang tidak jelas atau jelek yang digunakan oleh beberapa browser. Jika Anda memutuskan untuk meluncurkan gaya Anda sendiri, pastikan untuk menggunakan lebih dari sekadar warna sebagai pengubah: Tambahkan garis luar atau garis bawah atau beberapa indikator visual lainnya untuk mendukung pengguna yang buta warna.

Banyak situs menekan gaya fokus default tetapi gagal menyediakan gaya khusus, yang mengarah ke pengalaman yang tidak dapat diakses. Jika situs Anda menggunakan pengaturan ulang CSS Eric Meyer, itu mungkin tidak dapat diakses; file yang biasa digunakan ini mengatur ulang gaya default :focus tetapi menginstruksikan pengembang untuk menulisnya sendiri, dan banyak yang gagal menemukan instruksinya.

Beberapa orang berpendapat bahwa ini dapat membingungkan pengguna jika Anda menonaktifkan default browser, karena mereka kehilangan kemampuan visual dari status fokus yang biasa mereka gunakan dan sebagai gantinya harus mempelajari seperti apa status fokus situs Anda. Di sisi lain, beberapa berpendapat bahwa default browser jelek, atau bahkan membingungkan pengguna non-keyboard.

Mengapa membingungkan? Nah, lihat format carousel animasi ini di BBC. Ada dua tombol navigasi — berikutnya, dan sebelumnya — dan berguna bagi pengguna keyboard bahwa fokus tetap pada tombol tersebut sepanjang narasi. Namun bagi pengguna mouse, bisa jadi cukup membingungkan karena tombol yang diklik masih 'fokus' setelah kursor dipindahkan.

:focus-visible

Jika Anda menginginkan yang terbaik dari kedua dunia, Anda mungkin ingin menjelajahi kelas semu CSS4 :focus-visible , yang memungkinkan Anda memberikan gaya fokus yang berbeda tergantung pada konteksnya. :focus-visible styling hanya menargetkan elemen yang telah difokuskan dengan keyboard, bukan dengan klik mouse. Ini sangat keren, meskipun saat ini hanya didukung secara native di Firefox. Ini dapat diaktifkan di Chrome dengan menyalakan tanda 'Fitur Platform Web Eksperimental'.

Video YouTube Dan Aksesibilitas Keyboard

YouTube melakukan pekerjaan yang baik dengan pemutar videonya — setiap bagian pemutar dapat dinavigasi dengan keyboard. Saya suka bagaimana kontrol volume meluncur keluar saat Anda tab fokus menjauh dari ikon bisu, berbeda dengan meluncur keluar saat melayang di atas ikon bisu.

Yang tidak saya sukai adalah label yang membantu, seperti teks 'Bungkam' yang muncul saat mengarahkan kursor ke ikon bisu, tidak ditampilkan pada fokus.

Area lain yang mengecewakan YouTube adalah ia menekan beberapa gaya fokus. Di sini saya mencoba untuk menekan tombol 'Tampilkan lebih banyak'.

Saya tidak sengaja tab melewati tombol 'Tampilkan lebih banyak' karena saya tidak bisa melihat gaya :focus diterapkan, baik kustom atau asli. Saya menemukan bahwa gaya asli sedang diganti dengan outline-width :

Aksesibilitas Keyboard GitHub

Oke, waktu kerja. Di mana tempat yang lebih baik untuk bekerja selain di rumah kode, github.com?

Saya memperhatikan tiga hal tentang GitHub: Satu hebat, satu masuk akal, dan satu buruk.

Pertama, yang baik.

Tautan 'Lewati Ke Konten'

GitHub menawarkan tautan Skip to content , yang melompati menu utama.

Jika Anda menekan ENTER saat fokus pada tautan 'Lewati ke konten', Anda melewati semua item menu di bagian atas halaman dan dapat mulai membuka tab di dalam area utama konten, menghemat waktu saat bernavigasi. Ini adalah pola aksesibilitas umum yang sangat berguna bagi pengguna keyboard dan pembaca layar. Sekitar 30% pengguna pembaca layar akan menggunakan tautan lewati jika Anda menyediakannya.

Atau, beberapa situs memilih untuk menempatkan konten utama terlebih dahulu dalam urutan membaca, di atas navigasi. Pendekatan ini telah ketinggalan zaman karena melanggar pedoman untuk membuat konten DOM Anda sesuai dengan urutan visual (kecuali navigasi Anda muncul secara visual di bagian bawah). Dan sementara pendekatan ini berarti kami tidak memerlukan tautan 'Lewati navigasi' sama sekali, kami mungkin menginginkan tautan 'Lewati ke navigasi' sebagai gantinya.

Tab Untuk Melihat Konten

Salah satu fitur yang saya perhatikan bekerja secara berbeda dengan versi 'non-keyboard' adalah indikator kerusakan kode.

Dengan menggunakan mouse, Anda dapat mengklik bilah berwarna di bawah repositori mana pun untuk melihat perincian proporsional dari berbagai bahasa pemrograman yang digunakan dalam repo. Menggunakan keyboard, Anda tidak dapat benar-benar menavigasi ke bilah berwarna, tetapi bahasa muncul secara otomatis saat Anda melewati bagian akhir informasi meta.

Ini sepertinya tidak perlu — saya akan dengan senang hati tab ke bilah berwarna dan menekan ENTER pada itu — tetapi perilaku yang berbeda ini juga tidak membahayakan.

Tautan Tak Terlihat

Satu hal bermasalah yang saya temukan adalah bahwa ada tautan "tidak terlihat" setelah melewati gambar profil saya di kanan atas. Urutan tab saya akan tab ke gambar, lalu ke tautan tak terlihat ini, dan kemudian ke tombol 'Tonton' pada repo (lihat gif di bawah). Saya tidak tahu apa yang dilakukan tautan tak terlihat itu, jadi ketika saya menyadari bahwa saya ada di dalamnya, saya menekan ENTER dan segera keluar!

Pada pemeriksaan lebih dekat, sepertinya saya telah menavigasi ke formulir "hanya pembaca layar" ( sr-only adalah nama kelas pembaca layar yang umum) yang memiliki fitur 'Keluar'.

Tautan keluar ini merupakan tambahan dari tautan keluar pada menu tarik-turun profil Anda:

Saya tidak yakin bahwa dua tautan keluar HTML terpisah diperlukan, karena pengguna pembaca layar harus dapat memicu tarik-turun dan menavigasi ke tautan keluar utama. Dan jika kami ingin menyimpan tautan terpisah, saya akan merekomendasikan untuk menerapkan gaya :focus ke konten pembaca layar sehingga pengguna yang dapat melihat tidak secara tidak sengaja memicu keluar sendiri!

Cara Membuat Pintasan 'Lewati ke Konten'

Jadi bagaimana kita membuat ulang pintasan 'Lewati ke konten' itu? Ini cukup sederhana untuk diterapkan, tetapi bisa sangat sulit untuk menjadi sempurna — jadi inilah yang saya anggap sebagai Cawan Suci dari solusi lewati tautan.

'Lewati tautan' atau disebut 'Lewati navigasi', 'Lewati navigasi utama', 'Lewati tautan navigasi', atau 'Lewati ke konten utama'. 'Lewati ke konten utama' mungkin yang paling jelas karena memberi tahu Anda ke mana Anda menavigasi, daripada apa yang Anda lewati.

Tautan pintasan idealnya muncul tepat setelah tag <body> pembuka. Itu bisa muncul nanti di DOM, bahkan setelah footer, asalkan Anda memiliki atribut tabindex="1" untuk memaksanya menjadi elemen interaktif pertama dalam urutan tab. Namun, menggunakan tabindex dengan angka lebih besar dari nol umumnya merupakan praktik yang buruk dan sering kali akan menghasilkan peringatan saat menggunakan alat validasi seperti Lighthouse.

Tidak mudah untuk mengandalkan tabindex , karena Anda mungkin memiliki lebih dari satu tautan dengan tabindex="1" . Dalam kasus ini, tautan pertama yang akan mendapatkan fokus tab terlebih dahulu, bukan tautan selanjutnya. Baca selengkapnya tentang menggunakan atribut tabindex di sini, tetapi ingat bahwa Anda selalu lebih baik memindahkan tautan secara fisik ke awal DOM agar aman.

 <a class="screen-reader-shortcut" href="#main-content"> Skip to main content </a>

Tautan 'Lewati ke konten utama' memiliki penggunaan terbatas untuk pengguna yang dapat melihat, yang sudah dapat melewati navigasi dengan menggunakan mata mereka. Jadi, sementara beberapa situs membuat tautan lewati terlihat setiap saat, konvensi saat ini adalah untuk menjaga tautan tetap tersembunyi sampai Anda tab ke dalamnya, di mana titik itu dalam fokus dan mendapatkan gaya yang diterapkan oleh :focus pseudo selector.

 .screen-reader-shortcut { position: absolute; top: -1000em; } .screen-reader-shortcut:focus { position: fixed; top: 0; left: 0; z-index: 999; /* ...and now any nice styling you want to apply... */ padding: 1em; background-color: rgb(114, 105, 105); color: white; text-decoration: none; }

Jadi, apa yang sebenarnya kita lewati? Apa itu #main-content ? Itu benar-benar bisa apa saja:

1. konten sebaris
   yaitu id dari tag h1 Anda: <h1 id="main-content"> .
2. Wadah
   misalnya id wadah di sekitar konten utama Anda seperti <main id="main-content"> .
3. Saudara jangkar
   Anda dapat menautkan ke tag bernama tepat di atas konten utama Anda, misalnya <a name="main-content"></a> . Pendekatan ini biasanya dijelaskan dalam tutorial lama — saya tidak akan merekomendasikannya akhir-akhir ini.

Untuk kompatibilitas maksimum di semua pembaca layar, saya sarankan untuk menautkan ke tag h1 . Ini untuk memastikan bahwa konten dibacakan segera setelah Anda menggunakan tautan lewati. Menautkan ke wadah dapat menyebabkan perilaku lucu, misalnya pembaca layar mulai membacakan semua konten di dalam wadah.

#main-content Anda juga harus memiliki indeks tabindex -1 , untuk memastikan bahwa itu dapat difokuskan secara terprogram. Beberapa pembaca layar mungkin tidak mematuhi tautan lewati jika tidak.

 <h1 tabindex="-1">This is the title of the page</h1>

Satu pertimbangan terakhir: dukungan browser lawas. Jika Anda memiliki cukup banyak pengguna di IE9 atau di bawahnya, Anda mungkin perlu menerapkan sedikit perbaikan JavaScript ke tautan lewati Anda untuk memastikan bahwa fokus benar-benar bergeser seperti yang diharapkan dan pengguna Anda berhasil melewati navigasi Anda.

Mengapa Kita Menemukan Kembali Roda?

Tampaknya gila bahwa sebagai pengembang web kami harus menerapkan peretasan 'lewati navigasi' ini di semua situs kami sebagai aturan. Anda akan berpikir kita bisa membiarkan standar bekerja.

Sejak HTML5, kami memiliki elemen semantik seperti <main> , <nav> dan <header> . Sebelumnya, kami memiliki landmark ARIA seperti role="main" , role="navigation" dan role="banner" masing-masing. Dalam lanskap web saat ini, praktik terbaik menyatakan bahwa Anda memerlukan keduanya, yaitu <main role="main"> , yang merupakan pelanggaran mengerikan terhadap prinsip KERING, tetapi begitulah.

Dengan semua kekayaan semantik ini, Anda berharap browser akan mulai mendukung navigasi secara native melalui area tengara ini, misalnya dengan menampilkan pintasan keyboard bagi pengguna untuk langsung masuk ke bagian <main> halaman web. Tidak beruntung — tidak ada dukungan asli saat ini. Taruhan terbaik Anda adalah menggunakan Navigasi Landmark melalui ekstensi Keyboard untuk Chrome, Opera atau Firefox.

Namun, pengguna pembaca layar dapat mulai menavigasi langsung ke kawasan tengara ini. Misalnya, di VoiceOver di Mac, Anda dapat menekan CTRL + ALT + U untuk membuka Menu Landmark dan membuka tengara 'utama', yang merupakan pintasan cepat dan konsisten untuk membuka konten utama. Tentu saja, ini bergantung pada situs yang menandai dokumen mereka dengan benar.

Berikut adalah titik awal yang baik untuk situs Anda jika Anda ingin situs dapat dinavigasi melalui kawasan tengara:

 <body> <header role="banner"> <!-- Logo and things can go here --> <nav role="navigation"> <!-- Site navigation links go here --> </nav> </header> <main role="main"> <!-- Main content lives here - including our h1 --> </main> <footer role="contentinfo"> <!-- Copyright statement, etc --> </footer> </body>

Semua markup ini adalah pekerjaan yang haus. Waktu untuk minum kopi.

Kopi Pakta

Saya ingat pernah melihat brosur untuk pactcoffee.com… ayo kita lihat!

Spanduk Kue

Spanduk 'Kebijakan cookie' adalah salah satu hal pertama yang Anda perhatikan di sini, dan mengabaikannya hampir merupakan refleks naluriah bagi pengguna mouse yang dapat melihat. Beberapa pengguna pembaca layar mungkin tidak mempedulikannya (jika Anda buta, Anda tidak akan tahu itu ada di sana sampai Anda mencapainya), tetapi sebagai pengguna yang dapat melihat, Anda melihatnya, Anda ingin membunuhnya, dan dalam kasus situs ini, Anda harus melewati SEMUA LINK LAINNYA sebelum Anda dapat menutupnya.

Saya menggunakan ekstensi aksesibilitas ChromeLens untuk melacak urutan tab halaman:

Ini dapat diperbaiki dengan memindahkan pemberitahuan ke bagian atas dokumen (itu masih dapat ditambatkan ke bagian bawah secara visual dengan CSS), atau dengan menambahkan tabindex="1" ke tombol OK. Saya menyarankan untuk menerapkan perbaikan ini pada konten apa pun yang diharapkan pengguna ingin mengabaikannya.

Lebih Banyak Tautan Tak Terlihat

Seperti di GitHub, saya menemukan diri saya tabbing ke elemen di luar layar yang tujuannya tidak jelas. Ternyata itu adalah tombol 'Lihat lebih sedikit…' yang berada di belakang kartu 'Lihat lebih banyak…'.

Ini karena area 'tersembunyi' tidak benar-benar tersembunyi, hanya diputar 180 derajat, menggunakan:

 transform: rotateY(180deg);

…yang berarti tombol 'Lihat lebih sedikit…' masih merupakan bagian dari urutan tab. Ini dapat diperbaiki dengan menerapkan display: none hingga aplikasi siap untuk memicu rotasi:

Kopi dipesan. Sekarang saatnya untuk melanjutkan penelitian saya.

dunia IT

Saya sedang melakukan riset untuk artikel ini dan menemukan eksperimen serupa dengan eksperimen saya sendiri; Kevin Purdy menjelajahi web selama tujuh hari hanya dengan menggunakan keyboardnya. Saya merasa ironis bahwa saya tidak dapat membaca artikelnya di bawah batasan yang sama!

Masalahnya adalah spanduk cookie satu halaman penuh, yang mengharuskan saya untuk "Memperbarui Pengaturan Privasi" atau menerima pengaturan cookie default. Tidak peduli berapa kali saya tab, saya tidak bisa fokus pada spanduk cookie dan mengabaikannya.

Saya menggali kode sumber untuk mencari tahu apa yang sedang terjadi. Untuk sesaat, saya pikir itu mungkin musuh bebuyutan kita, properti CSS outline .

Memeriksa tautan "Perbarui Pengaturan Privasi", saya dapat melihat outline: 0 seperti yang saya duga. Jadi mungkin saya fokus pada tombol, tetapi tidak ada umpan balik visual saat itu terjadi?

Saya mencoba mengatur status ke :hover untuk melihat apakah saya kehilangan gaya apa pun sebagai pengguna keyboard:

Benar saja, tautannya berubah menjadi warna oranye yang bagus dan jelas saat melayang — sesuatu yang tidak pernah saya lihat saat fokus:

Hore! Retak itu! Saya tidak pernah melihat status :focus karena gaya kustom hanya diterapkan pada :hover . Saya pasti telah melewati tombol tanpa menyadarinya, bukan?

Salah. Bahkan ketika saya meretas CSS secara lokal, saya tidak dapat melihat gaya fokus apa pun, yang berarti saya bahkan tidak sampai sejauh tab ke modal cookie. Kemudian saya menyadari… tautan tersebut tidak memiliki atribut href :

Itu adalah pelaku yang sebenarnya. Garis outline: 0 bukan masalahnya — browser tidak akan pernah membuka tab ke tautan karena itu bukan tautan yang valid!

Dari spesifikasi HTML 5.2:

Tujuan tautan diberikan oleh atribut href, yang harus ada dan harus berisi URL valid yang tidak kosong yang berpotensi dikelilingi oleh spasi. Jika atribut href tidak ada, maka elemen tersebut tidak mendefinisikan tautan.

Memberi tautan sebuah atribut href — meskipun itu hanya # — akan menjadikannya tautan yang valid dan akan menambahkannya ke urutan tab halaman.

Lucunya, kemudian pada hari itu, saya dikirimi sebuah artikel di PC World untuk dibaca dan saya mengalami masalah yang persis sama.

Tampaknya kedua situs menggunakan Platform Pengelolaan Izin (CMP) yang sama. Saya melakukan sedikit penggalian dan menyimpulkan bahwa itu memengaruhi sejumlah situs yang dimiliki oleh perusahaan yang sama, dan sejak itu menghubungi mereka secara langsung dengan perbaikan yang disarankan.

kinetika

Keran dapur saya bocor dan saya bermaksud untuk menggantinya. Saya melihat sebuah iklan di koran lokal untuk kinetico.co.uk, jadi saya pikir saya akan melihatnya.

Saya tidak dapat menavigasi ke bagian 'Kitchen Taps', karena tautannya tersimpan di belakang tautan induk 'Salt & Cartridges' yang hanya menampilkan tautan turunannya saat mengarahkan kursor. Sangat menarik bahwa situs ini cukup berpikiran maju untuk menyediakan tautan 'Lewati ke Konten' (terlihat secara singkat di gif di atas) tetapi tidak dapat membuat menu yang dapat diakses!

Di sinilah menu yang salah — itu hanya menampilkan sub menu ketika item menu induk sedang diarahkan:

Memperbaikinya lebih mudah diucapkan daripada dilakukan. Dalam kebanyakan kasus, Anda cukup "menggandakan" pemilih Anda untuk diterapkan ke fokus juga:

 li:hover .nav_sub_menu, li:focus .nav_sub_menu { }

Tetapi ini tidak berfungsi dalam kasus ini karena meskipun elemen <li> dapat dilayangkan, itu tidak dapat difokuskan. Ini adalah tautan di dalam <li> yang dapat difokuskan. Tetapi submenu tidak ada di dalam tautan, itu di sebelahnya , jadi kita perlu menerapkan pemilih saudara untuk menampilkan submenu saat tautan dalam fokus.

 li:hover .nav_sub_menu, a:focus + .nav_sub_menu { }

Tweak ini berarti kita dapat melihat submenu kita ketika kita tab ke item menu induk pada keyboard. Tetapi apa yang terjadi ketika Anda mencoba masuk ke submenu?

Saat kami tab dari item menu induk, fokus bergeser ke tautan pertama di menu anak seperti yang diharapkan. Tapi ini mengalihkan fokus dari tautan menu induk, artinya submenu disembunyikan dan item menu anak dihapus dari urutan tab lagi!

Ini adalah masalah yang dapat diselesaikan dengan :focus-within , yang memungkinkan Anda menerapkan gaya ke elemen induk jika elemen anaknya atau elemen turunannya memiliki fokus. Jadi, dalam hal ini, kita harus melipatgandakan:

 li:hover .nav_sub_menu, /* hover over parent menu item, show child menu */ a:focus + .nav_sub_menu, /* focus onto parent menu item, show child menu */ .nav_sub_menu:focus-within { /* focus onto child menu item, keep showing child menu */ }

Menu kami sekarang sepenuhnya dapat diakses oleh keyboard melalui CSS murni. Saya suka solusi CSS yang kreatif, tetapi ada peringatan di sini: cukup banyak solusi "CSS-only" di alam liar jatuh ketika datang ke navigasi keyboard. Menghindari JavaScript tidak serta merta membuat situs lebih mudah diakses.

Faktanya, menu berbasis JS mungkin lebih baik dalam kasus ini, karena dukungan browser untuk solusi ini masih sangat buruk. :focus-within saat ini hanya dapat digunakan di Chrome, Firefox, dan Safari. Bahkan di Chrome, saya menemukan itu tidak kompatibel dengan display: none logika yang digunakan untuk menampilkan/menyembunyikan menu anak; Saya harus menyembunyikan item menu saya dengan mengatur opacity: 0 sebagai gantinya.

Oke, aku sudah selesai untuk hari ini. Sekarang saatnya untuk bersantai dengan sedikit media sosial.

Facebook

Facebook melakukan pekerjaan luar biasa di sini, menyediakan kelas master dalam aksesibilitas keyboard.

Pada penekanan TAB pertama, menu tersembunyi terbuka, menyediakan pintasan ke bagian paling populer dari halaman saat ini dan tautan ke halaman populer lainnya.

Saat Anda menelusuri bagian halaman menggunakan tombol panah, bagian tersebut disorot secara visual sehingga Anda dapat melihat ke mana Anda akan melakukan tab.

Fitur yang paling berguna adalah Facebook menyediakan pintasan OPT + / (atau ALT + / ) untuk kembali ke menu kapan saja, dengan memanfaatkan atribut aria-keyshortcuts.

 <div class="a11y-help"> Press opt + / to open this menu </div> <div aria-label="Navigation Assistant" aria-keyshortcuts="Alt+/" role="menubar"> <a class="screen-reader-shortcut" tabindex="1" href="#main-content"> Skip to main content </a> </div>

Tidak seperti tautan 'lewati ke konten utama', yang dibangun di atas teknologi penahan asli dan "hanya berfungsi", atribut aria-keyshortcuts mengharuskan penulis untuk menerapkan semua perilaku keyboard, jadi Anda harus menulis beberapa JavaScript khusus jika Anda ingin menggunakan ini.

Berikut adalah beberapa JS yang menyembunyikan dan menampilkan area menubar , yang merupakan titik awal yang berguna:

 const a11yArea = document.querySelector('*[role="menubar"]'); document.addEventListener('keydown', (e) => { if (e.altKey && e.code === 'Slash') { a11yArea.style.display = a11yArea.style.display === 'block' ? 'none' : 'block'; } });

Ringkasan

Eksperimen ini telah menjadi kumpulan pengalaman keyboard yang hebat dan yang buruk. Saya memiliki tiga takeaways utama.

Tetap Bergaya

Sejauh ini masalah aksesibilitas keyboard paling umum yang saya hadapi saat ini adalah kurangnya gaya fokus untuk elemen tabbable. Menekan gaya fokus asli tanpa menentukan gaya fokus khusus membuat sangat sulit, bahkan tidak mungkin, untuk mengetahui di mana Anda berada di halaman. Menghapus garis besar adalah kesalahan umum yang bahkan ada situs yang didedikasikan untuk itu.

Memastikan bahwa gaya fokus asli atau kustom terlihat adalah satu-satunya hal paling berdampak yang dapat Anda lakukan di area aksesibilitas keyboard, dan ini sering kali merupakan salah satu yang termudah; kasus sederhana menggandakan penyeleksi pada gaya :hover Anda yang ada. Jika Anda hanya melakukan satu hal setelah membaca artikel ini, seharusnya mencari outline: 0 dan outline: none di CSS Anda.

Semantik Adalah Kunci

Berapa kali Anda mencoba membuka tautan di tab baru, hanya agar jendela Anda saat ini dialihkan? Itu terjadi pada saya sesekali, dan menjengkelkan seperti itu, saya beruntung bahwa itu adalah satu-satunya masalah kegunaan yang cenderung saya hadapi ketika saya menggunakan web. Masalah seperti itu muncul dari penyalahgunaan platform.

Mari kita lihat kode ini di sini:

 <span>Click here</span>

Pengguna yang mampu dan dapat melihat akan dapat mengeklik <span> dan dialihkan ke Google. Namun, karena ini adalah <span> dan bukan tautan atau tombol, ini tidak memiliki kemampuan fokus secara otomatis, sehingga keyboard atau pembaca layar tidak dapat berinteraksi dengannya.

Pengguna keyboard adalah pengguna yang bergantung pada standar, sedangkan demografis yang mampu dan terlihat cukup memiliki hak istimewa untuk dapat berinteraksi dengan elemen meskipun tidak sesuai.

Gunakan fitur asli platform. Tulis HTML yang baik dan bersih, dan gunakan validator seperti https://validator.w3.org untuk menangkap hal-hal seperti atribut href yang hilang pada jangkar Anda.

Konten Adalah Kunci

Anda mungkin diminta untuk menampilkan pemberitahuan cookie, formulir berlangganan, iklan atau pemberitahuan adblock.

Lakukan apa yang Anda bisa untuk membuat pengalaman ini tidak mengganggu. Jika Anda tidak bisa membuatnya tidak mencolok, setidaknya buat mereka bisa diabaikan.

Pengguna ada di sana untuk melihat konten Anda, bukan spanduk Anda, jadi tempatkan elemen yang dapat ditutup ini terlebih dahulu di DOM Anda sehingga mereka dapat dengan cepat ditutup, atau kembali menggunakan tabindex="1" jika Anda tidak dapat memindahkannya.

Terakhir, dukung pengguna Anda untuk mengakses konten Anda secepat mungkin, dengan menerapkan Holy Grail dari tautan 'lompat ke konten utama'.

Nantikan artikel berikutnya dalam seri ini, di mana saya akan membangun beberapa teknik ini ketika saya menggunakan pembaca layar selama sehari.