Web'i Ekran Okuyucu Kullanarak Bir Gün Kullandım

Bu makale, belirli bir kullanıcı demografisini temsil eden çeşitli kısıtlamalar altında web'i kullanmaya çalıştığım bir dizinin parçasıdır. Gerçek insanların karşılaştığı, onların ihtiyaçlarına duyarlı bir şekilde tasarlar ve geliştirirsek önlenebilecek zorlukların profilini yükseltmeyi umuyorum. Geçen sefer sadece klavyemle bir günlüğüne internette gezindim. Bu sefer ekrandan kaçınıyorum ve web'i bir ekran okuyucu ile kullanıyorum.

Ekran Okuyucu Nedir?

Ekran okuyucu, ekrandaki şeyleri (metin, resimler, bağlantılar vb.) yorumlayan ve bunları görme engelli kişilerin tüketebileceği ve etkileşimde bulunabileceği bir biçime dönüştüren bir yazılım uygulamasıdır. Ekran okuyucu kullanıcılarının üçte ikisi, ekran okuyucu çıktıları olarak konuşmayı seçiyor ve ekran okuyucu kullanıcılarının üçte biri braille'i seçiyor.

Ekran okuyucular, kelime işlemciler, e-posta istemcileri ve web tarayıcıları gibi programlarla kullanılabilir. Uygulamanın içeriğini ve arayüzünü, daha sonra ekran okuyucu tarafından okunabilecek bir erişilebilirlik ağacına eşleyerek çalışırlar. Bazı ekran okuyucuların belirli programları ağaca manuel olarak eşlemesi gerekirken, diğerleri daha geneldir ve çoğu programla çalışmalıdır.

Windows'ta en popüler ekran okuyucu, genel ekran okuyucu pazarının neredeyse yarısıyla JAWS'dır. Ev sürümü için yaklaşık bin dolara mal olan ticari bir yazılımdır. Windows için açık kaynaklı bir alternatif, masaüstündeki tüm ekran okuyucu kullanıcılarının üçte birinden azı tarafından kullanılan NVDA'dır.

Microsoft Narrator , System Access , Window-Eyes ve ZoomText (tam ekran okuyucu değil, okuma yetenekleri olan bir ekran büyüteci); bunların birleşik toplamı, ekran okuyucu kullanımının yaklaşık %6'sına eşittir. Linux'ta Orca, varsayılan olarak bir dizi dağıtımda paketlenmiştir.

macOS, iOS ve tvOS ile birlikte gelen ekran okuyucu VoiceOver'dır . VoiceOver, masaüstü ekran okuyucu kullanıcılarının %11,7'sini oluşturur ve mobilde ekran okuyucu kullanıcılarının %69'una yükselir. Mobil alandaki diğer önemli ekran okuyucular, Android'de Talkback (%29,5) ve kendisi Talkback'e dayanan, ancak ek hareketlerle birlikte Samsung'da Voice Assistant'tır (%5,2).

Bir MacBook'um ve bir iPhone'um var, bu yüzden bu makale için VoiceOver ve Safari kullanacağım. Safari, VoiceOver ile kullanılması önerilen tarayıcıdır, çünkü her ikisi de Apple tarafından sağlanır ve birlikte iyi çalışır. VoiceOver'ı farklı bir tarayıcıyla kullanmak beklenmeyen davranışlara yol açabilir.

Ekran Okuyucunuzu Etkinleştirme ve Kullanma

Talimatlarım VoiceOver içindir, ancak seçtiğiniz ekran okuyucunuz için eşdeğer komutlar olmalıdır.

Masaüstünde VoiceOver

Daha önce hiç ekran okuyucu kullanmadıysanız, göz korkutucu bir deneyim olabilir. Yalnızca işitsel bir deneyime gitmek büyük bir kültür şoku ve gürültü saldırısını nasıl kontrol edeceğini bilmemek sinir bozucu. Bu nedenle, öğrenmek isteyeceğiniz ilk şey, onu nasıl kapatacağınızdır.

VoiceOver'ı kapatma kısayolu, onu açma kısayoluyla aynıdır: ⌘ + F5 ( ⌘ , Cmd tuşu olarak da bilinir). Dokunmatik çubuğu olan daha yeni Mac'lerde kısayol, komut tuşunu basılı tutmak ve Touch ID düğmesine üç kez basmaktır. VoiceOver çok hızlı mı konuşuyor? VoiceOver İzlencesi'ni açın, 'Konuşma' sekmesine basın ve hızı buna göre ayarlayın.

Açma ve kapatma konusunda uzmanlaştıktan sonra, “VoiceOver tuşunu” (aslında aynı anda iki tuşa basılan) kullanmayı öğrenmeniz gerekecek: Ctrl ve ⌥ (ikinci tuş “Option olarak da bilinir) ” veya Alt tuşu). VO tuşunu diğer tuşlarla birlikte kullanarak web'de gezinebilirsiniz.

Örneğin, web sayfasını mevcut konumdan okumak için VO + A'yı kullanabilirsiniz; pratikte bu, Ctrl + ⌥ + A tuşlarını basılı tutmak anlamına gelir. VO'nun neye karşılık geldiğini hatırlamak ilk başta kafa karıştırıcı olabilir, ancak VO notasyonu kısalık ve tutarlılık içindir. VO anahtarını başka bir şey olacak şekilde yapılandırmak mümkündür, bu nedenle herkesin takip edebileceği standart bir gösterime sahip olmak mantıklıdır.

DOM'deki her bir öğeyi sırayla geçmek için VO ve ok tuşlarını ( VO + → ve VO + ← ) kullanabilirsiniz. Bir bağlantıyla karşılaştığınızda, tıklamak için VO + Boşluk tuşlarını kullanabilirsiniz - bu tuşları form öğeleriyle etkileşim kurmak için de kullanacaksınız.

Huzzah! Artık Web'de gezinmek için VoiceOver hakkında yeterince bilginiz var.

Mobilde VoiceOver

VoiceOver'ı açmak için mobil/tablet kısayolu cihaza göre değişir, ancak genellikle ana sayfa düğmesine 'üç kez tıklanması' gerekir (ayarlarda kısayolu etkinleştirdikten sonra).

Two-Finger Swipe Down komutuyla geçerli konumdan her şeyi okuyabilir ve Swipe Right or Left ile DOM'deki her öğeyi sırayla seçebilirsiniz.

Artık iOS VoiceOver hakkında masaüstünüz kadar bilgi sahibisiniz!

İçerik Türüne Göre Gezinme

Gören bir kullanıcı olarak web'i nasıl kullandığınızı düşünün. Her kelimeyi dikkatlice, sırayla, yukarıdan aşağıya okuyor musunuz? Hayır. İnsanlar tasarım gereği tembeldir ve ilginç bilgiler için sayfaları olabildiğince hızlı 'taramayı' öğrenmişlerdir.

Ekran okuyucu kullanıcıları da aynı verimlilik ihtiyacına sahiptir, bu nedenle çoğu, başlıklar, bağlantılar veya form kontrolleri gibi içerik türüne göre sayfada gezinir. Bunu yapmanın bir yolu, VO + U ile kısayollar menüsünü açmak, ← ve → ok tuşlarıyla istediğiniz içerik türüne gitmek ve ardından ↑↓ tuşlarıyla bu öğeler arasında gezinmektir.

Bunu yapmanın başka bir yolu da 'Hızlı Dolaşma'yı etkinleştirmektir ( ← ile → aynı anda basılı tutarak). Hızlı Dolaşma etkinken, ↑ okunu ← veya → yanında tutarak içerik türünü seçebilirsiniz. iOS'ta bunu Two-Finger Rotate hareketiyle yaparsınız.

İçerik türünüzü seçtikten sonra, ↑↓ tuşlarıyla (veya iOS'ta Swipe Up or Down Kaydırarak) her bir rotor öğesini atlayabilirsiniz. Hatırlanması gereken çok şey var gibi geliyorsa, başvuru için bu süper kullanışlı VoiceOver hile sayfasına yer işareti koymaya değer.

İçerik türleri arasında gezinmenin üçüncü bir yolu izleme dörtgeni hareketlerini kullanmaktır. Bu, deneyimi iPad/iPhone'da iOS'ta VoiceOver'ı nasıl kullanabileceğinize yaklaştırıyor, bu da yalnızca bir dizi ekran okuyucu komutunu hatırlamanız gerektiği anlamına geliyor!

OSX'teki yerleşik eğitim programında jest tabanlı gezinmeyi ve diğer birçok VoiceOver tekniğini uygulayabilirsiniz. Buna Sistem Tercihleri ​​→ Erişilebilirlik → VoiceOver → VoiceOver Eğitimini Aç üzerinden erişebilirsiniz.

Öğreticiyi tamamladıktan sonra, gitmeye can atıyordum!

Örnek Olay 1: YouTube

YouTube'da Arama

Safari araç çubuğundaki YouTube ana sayfasına gittim; bunun üzerine VoiceOver, Ctrl + ⌥ + Shift + ↓ ile web içeriğine "dahil olmamı" söyledi. Aynı mekanizma gömülü içerik ve bazı form kontrolleri için de geçerli olduğundan, yakında web içeriğine adım atmaya alışacaktım.

Hızlı Gezinmeyi kullanarak, sayfanın üst kısmındaki arama bölümüne kolayca atlamak için form kontrolleri aracılığıyla gezinebildim.

Kaliteli içerik aradım:

Ve arama düğmesine gittim:

Ancak VO + Space ile butonu etkinleştirdiğimde hiçbir şey duyurulmadı.

Gözlerimi açtım ve arama gerçekleşti ve sayfa sonuçlarla doldu, ancak tek başına ses yoluyla bilmenin hiçbir yolu yoktu.

Şaşırdım, devtools açıkken eylemlerimi yeniden ürettim ve ağ sekmesine göz kulak oldum.

Şüphelenildiği üzere YouTube, "istemci tarafı oluşturma" adı verilen bir performans tekniği kullanıyor; bu, JavaScript'in tüm sayfayı yeniden boyamak zorunda kalmamak için form gönderimini durdurduğu ve arama sonuçlarını yerinde oluşturduğu anlamına geliyor. Arama sonuçları normal bir bağlantı gibi yeni bir sayfaya yüklenseydi, VoiceOver gezinmem için yeni sayfayı duyururdu.

İstemci tarafından oluşturulan uygulamalar için erişilebilirliğe ayrılmış tüm makaleler vardır; Bu durumda, YouTube'a, arama gönderiminin başarılı olduğunu bildiren bir aria-live bölge uygulamasını tavsiye ederim.

1. İpucu: DOM'da istemci tarafı değişikliklerini duyurmak için aria-live bölgeleri kullanın.

 <div role="region" aria-live="polite" class="off-screen"></div> <form> <label> <span class="off-screen">Search for a video</span> <input type="text" /> </label> <input type="submit" value="Search" /> </form> <script> document.getElementById('search-form').addEventListener('submit', function (e) { e.preventDefault(); ajaxSearchResults(); // not defined here, for brevity document.getElementById('search-status').textContent = 'Search submitted. Navigate to results below.'; // announce to screen reader }); </script>

Artık hile yaptığımdan ve bakılacak arama sonuçları olduğunu bildiğimden, gözlerimi kapattım ve Quick Nav'in “başlıklar” moduna geçerek ve oradan sonuçlara geçerek sonuçların ilk videosuna gittim.

YouTube'da Video Oynatma

Bir YouTube video sayfası yüklediğiniz anda video otomatik olarak oynatılır. Bu, günlük kullanımda değer verdiğim bir şey, ancak bu, VoiceOver'ın konuşmasıyla karıştırıldığında acı verici bir deneyimdi. Sonraki videolar için otomatik oynatmayı devre dışı bırakmanın bir yolunu bulamadım. Gerçekten yapabileceğim tek şey bir sonraki videomu yüklemek ve ekran okuyucu duyurularını durdurmak için hızlıca CTRL .

2. İpucu: Her zaman otomatik oynatmayı engellemenin bir yolunu sağlayın ve kullanıcının seçimini unutmayın.

Videonun kendisi, etkileşim kurmak için adım atmanız gereken bir "grup" olarak değerlendirilir. Hoş bir şekilde şaşırdığım video oynatıcıdaki seçeneklerin her birinde gezinebildim - Flash günlerinde durumun böyle olduğundan şüpheliyim!

Ancak, oynatıcıdaki bazı kontrollerin etiketi olmadığını gördüm, bu nedenle 'Sinema modu' basitçe “düğme” olarak okundu.

3. İpucu: Form denetimlerinizi her zaman etiketleyin.

Ekran okuyucu kullanıcıları çoğunlukla kör olsa da, yaklaşık %20'si "az gören" olarak sınıflandırılır, bu nedenle sayfanın bir kısmını görebilir. Bu nedenle, bir ekran okuyucu kullanıcısı yine de "Sinema modunu" etkinleştirmeyi takdir edebilir.

Bu ipuçları önem sırasına göre listelenmemiştir, ancak öyle olsaydı, bu benim bir numaram olurdu:

4. İpucu: Ekran okuyucu kullanıcıları, gören kullanıcılarla işlevsel bir denkliğe sahip olmalıdır.

“Sinema modu” seçeneğini etiketlemeyi ihmal ederek, ekran okuyucu kullanıcılarını normalde kullanabilecekleri bir özelliğin dışında tutuyoruz.

Bununla birlikte, bir özelliğin bir ekran okuyucuya uygulanmayacağı durumlar vardır - örneğin, bağlamsız sayıların saçmalıklarını okuyacak ayrıntılı bir SVG çizgi grafiği. Bu gibi durumlarda, öğeye özel aria-hidden="true" özniteliğini uygulayabilir, böylece öğenin ekran okuyucular tarafından tamamen yok sayılmasını sağlayabiliriz. Geri dönüş olarak yine de bazı ekran dışı alternatif metin veya veri tabloları sağlamamız gerekeceğini unutmayın.

İpucu #5: Ekran okuyucu kullanıcıları için geçerli olmayan içeriği gizlemek için aria-hidden kullanın.

Bazı içerikleri geri sarabilmem için oynatma konumunu nasıl ayarlayacağımı bulmam uzun zaman aldı. Kaydırıcıya ( VO + Shift + ↓ ) "girdikten" sonra, ayarlamak için ⌥ + ↑↓ tuşlarını basılı tutarsınız. Bana sezgisel görünmüyor ama yine de Apple'ın bazı tartışmalı klavye kısayol kararları verdiği ilk sefer değil.

YouTube Videosunun Sonunda Otomatik Oynatma

Videonun sonunda otomatik olarak yeni bir videoya yönlendirildim, bu kafa karıştırıcıydı - herhangi bir duyuru yapılmadı.

Kısa süre sonra Otomatik Kullan kontrollerine gitmeyi ve bunları devre dışı bırakmayı öğrendim:

Bu, bir video sayfası yüklediğimde videonun otomatik olarak oynatılmasını engellemez, ancak o video sayfasının bir sonraki videoya otomatik olarak yeniden yönlendirilmesini engeller.

Vaka Çalışması 2: BBC

Haber, belirli bir şey aramak yerine pasif olarak tüketilen bir şey olduğundan, BBC News'de başlıklara göre gezinmeye karar verdim. Bunun için Hızlı Dolaşma'yı kullanmanız gerekmediğini belirtmekte fayda var: VoiceOver, uzman kullanıcı için zaman kazandırabilecek öğe arama komutları sağlar. Bu durumda VO + ⌘ + H tuşları ile başlıklarda gezinebiliyorum.

İlk başlık tanımlama bilgisi bildirimiydi ve ikinci başlık 'Erişilebilirlik bağlantıları' başlıklı bir <h2> idi. Bu ikinci başlığın altındaki ilk bağlantı, diğer tüm gezinmeyi atlamamı sağlayan bir "İçeriğe geç" bağlantısıydı.

'İçeriğe geç' bağlantıları çok kullanışlıdır ve yalnızca ekran okuyucu kullanıcıları için değildir; önceki makaleme bakın “Bir günlüğüne web'i sadece bir klavyeyle kullandım”.

İpucu #6: Klavye ve ekran okuyucu kullanıcılarınız için 'içeriğe geç' bağlantıları sağlayın.

Başlıklara göre gezinmek iyi bir yaklaşımdı: her haber öğesinin kendi başlığı vardır, bu yüzden belirli bir hikaye hakkında daha fazla okumaya karar vermeden önce başlığı duyabiliyordum. Ve başlığın kendisi bir bağlantı etiketinin içine sarıldığından, tıklamak istediğimde gezinme modlarını değiştirmem bile gerekmedi; Mevcut makale seçimimi yüklemek için sadece VO + Space yapabilirim.

Ana sayfa içeriğe atlama kısayolu, bir #skip-to-content-link-target bağlantısına (daha sonra en iyi haber başlığını okur) güzel bir şekilde bağlantılıyken, makale sayfası atlama bağlantısı bozuktu. Beni başlığı okumak yerine makale içeriğini çevreleyen group götüren farklı bir kimliğe ( #page ) bağlantı verdi.

Bu noktada, VoiceOver'ın tüm makaleyi bana okumasını sağlamak için VO + A'ya bastım.

Oldukça ayrıntılı olmaya başladığı Twitter yerleşimine ulaşana kadar oldukça iyi başa çıktı. Bir noktada, yararsız bir şekilde “Bağlantı: 1068987739478130688” okudu.

Bu, tweet'in video yerleştirme bölümünde biraz tehlikeli bir işaretlemeye bağlı gibi görünüyor:

Görünüşe göre VoiceOver iç içe görüntünün alt niteliğini okumuyor ve bağlantının içinde başka bir metin yok, bu nedenle VoiceOver bildiği en yararlı şeyi yapıyor: URL'nin kendisinin bir bölümünü okumak.

Diğer ekran okuyucular bu biçimlendirmeyle sorunsuz çalışabilir - kilometreniz değişebilir. Ancak daha güvenli bir uygulama, alternatif metni taşımak için bir aria-label veya ekran dışında görsel olarak gizlenmiş bazı metne sahip bağlantı etiketi olabilir. Buradayken, muhtemelen “Gömülü video”yu biraz daha yararlı bir şeyle değiştirirdim, örneğin “Gömülü video: oynatmak için tıklayın”).

Bağlantı sorunları orada değildi:

Ana tweet içeriğinin altında, 'beğeni' sayacı olarak ikiye katlanan bir 'beğen' düğmesi vardır. Görsel olarak mantıklı, ancak ekran okuyucu açısından burada bağlam yok. Bu ekran okuyucu deneyimi iki nedenden dolayı kötü:

1. “1,887”nin ne anlama geldiğini bilmiyorum.
2. Bilmiyorum, linke tıklayarak tweeti beğeneceğim.

Ekran okuyucu kullanıcılarına daha fazla bağlam verilmelidir, örneğin “1.887 kullanıcı bu tweeti beğendi. Beğenmek için tıklayın." Bu, bazı düşünceli ekran dışı metinlerle başarılabilir:

 <style> .off-screen { clip: rect(0 0 0 0); clip-path: inset(100%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; } </style> <a href="/tweets/123/like"> <span class="off-screen">1,887 users like this tweet. Click to like</span> <span aria-hidden="true">1,887</span> </a>

7. İpucu: Ayrı ayrı okunduğunda her bağlantının anlamlı olduğundan emin olun.

BBC'de 'uzun biçimli' bir parça da dahil olmak üzere birkaç makale daha okudum.

Daha Uzun Makaleleri Okumak

Başka bir uzun biçimli BBC makalesinden alınan aşağıdaki ekran görüntüsüne bakın - kaç farklı resim görebilirsiniz ve bunların alt özellikleri ne olmalıdır?

İlk olarak, resmin ortasındaki Havasu Gölü'nün ön plan görüntüsüne bakalım. Altında bir başlık var: "Havasu Gölü, Colorado Nehri'ni tutan Parker Barajı'nın 1938'de tamamlanmasından sonra kuruldu".

Bir resim yazısı sağlanmış olsa bile bir alt niteliği sağlamak en iyi uygulamadır. alt metin resmi açıklamalı, resim yazısı ise bağlam sağlamalıdır. Bu durumda, alt niteliği "Güneşli bir günde Havasu Gölü'nün havadan görünümü" gibi bir şey olabilir.

Alternatif alt önüne “Resim: ” veya “Resmi” veya benzeri bir şey eklemememiz gerektiğini unutmayın. Ekran okuyucular, alt önce "görüntü" kelimesini duyurarak bu bağlamı zaten sağlıyor. Ayrıca, alt metni kısa tutun (16 kelimenin altında). Daha uzun bir alt metne ihtiyaç duyulursa, örneğin bir resimde kopyalanması gereken çok fazla metin varsa, longdesc niteliğine bakın.

İpucu #8: Açıklayıcı ancak etkili alt metinler yazın.

Anlamsal olarak, ekran görüntüsü örneği <figure> ve <figcaption> öğeleriyle işaretlenmelidir:

 <figure> <img src="/havasu.jpg" alt="Aerial view of Lake Havasu on a sunny day" /> <figcaption>Lake Havasu was created after the completion of the Parker Dam in 1938, which held back the Colorado River</figcaption> </figure>

Şimdi bu ekran görüntüsündeki arka plan görüntüsüne bakalım (çeşitli bardak ve ekipmanları taşıyan). Genel bir kural olarak, bunun gibi arka plan veya sunum resimlerinin boş bir alt niteliği ( alt="" ) olması gerekir, böylece VoiceOver'a alternatif bir metin olmadığı ve onu okumaya çalışmadığı açıkça söylenmelidir.

Boş bir alt="" , büyük bir hayır-hayır olan alt özniteliğe sahip olmakla aynı DEĞİLDİR. Bir alt özniteliği eksikse , ekran okuyucular bunun yerine genellikle çok kullanışlı olmayan görüntü dosya adlarını okuyacaktır!

9. İpucu: Sunum içeriği için boş alt nitelikleri kullanmaktan korkmayın.

Örnek Olay 3: Facebook

Şimdi Facebook'a gidiyorum ve daha önce yoksunluk belirtileri yaşıyordum, bu yüzden biraz daha Pratik Şakacı aramaya başladım.

Facebook, şu ana kadar denediğim diğer sitelerden bir veya iki adım daha ileri gidiyor ve bir 'İçeriğe geç' bağlantısı yerine, sırasıyla sayfalara veya sayfa bölümlerine bağlanan en az iki açılır listemiz var.

Facebook ayrıca bir dizi tuşu, sayfanın herhangi bir yerinden kullanılabilecek kısayol tuşları olarak tanımlar:

Bunlarla oynadım ve orada olduklarını öğrendikten sonra VoiceOver ile oldukça iyi çalışıyorlar. Gördüğüm tek sorun tescilli olmaları (aynı kısayolların Facebook dışında da çalışmasını bekleyemem), ancak Facebook'un burada gerçekten çok çalışması güzel.

Facebook erişilebilirliğiyle ilgili ilk izlenimim iyi olsa da kısa süre sonra sitede gezinmeyi zorlaştıran küçük tuhaflıklar fark ettim.

Örneğin, bu sayfada başlıklar aracılığıyla gezinmeye çalışırken kafam çok karıştı:

Sayfadaki ilk başlık, kenar çubuğuna gizlenmiş bir başlık seviyesi 3'tür. Bunu hemen, ana içerik sütununda, Sayfa tarafından paylaşılan bir duruma karşılık gelen SIX başlık seviyesi takip eder.

Bu, Chrome/Firefox için Web Geliştirici eklentisi ile görselleştirilebilir.

Genel bir kural olarak, 1'den büyük olmayan bir farkla sıralı başlıklara sahip olmak iyi bir fikirdir. Bunu yapmazsanız, anlaşmayı bozmaz, ancak buna bir ekran okuyucu perspektifinden yaklaşmak ve sizi endişelendirmek kesinlikle kafa karıştırıcıdır. h1'den h1 atladığınız için yanlışlıkla bazı önemli bilgileri h6 .

İpucu #10: Başlık yapınızı doğrulayın.

Şimdi, web sitesinin etine geçelim: gönderiler. Facebook tamamen insanlarla iletişimde kalmak ve ne yaptıklarını görmekle ilgilidir. Ancak alt metnin çoğu kullanıcı için bilinmeyen bir kavram olduğu bir dünyada yaşıyoruz, peki Facebook bu kendini beğenmiş özçekimleri ve köpek resimlerini bir ekran okuyucu kitlesine nasıl tercüme ediyor?

Facebook, bir fotoğrafta ne (veya kim) olduğunu analiz etmek ve onun metinsel bir açıklamasını oluşturmak için nesne tanıma teknolojisini kullanan bir Otomatik Alternatif Metin oluşturucuya sahiptir. Peki, ne kadar iyi çalışıyor?

Bu görselin alt metni “Görüntü şunları içerebilir: gökyüzü, çimen ve açık hava” idi. “Alacakaranlıkta Cambridge Katedrali”ni tanımaktan çok uzak ama kesinlikle doğru yönde atılmış bir adım.

Bazı açıklamaların doğruluğundan inanılmaz derecede etkilendim. Denediğim başka bir resim "Görüntü şunları içerebilir: John Smith, Jane Doe ve Chris Ashton dahil 3 kişi, gülümseyen insanlar, yakın plan ve iç mekan" - çok açıklayıcı ve kesinlikle doğru!

Ancak sosyal medyada viral olan memlerin ve şakaların doğası gereği erişilemez olması beni rahatsız ediyor; Facebook, aşağıdakileri "Görüntü şunları içerebilir: kuş ve metin" olarak değerlendirir, bu doğru olsa da gerçek tasvirden çok uzaktır!

Neyse ki, kullanıcılar isterlerse kendi alt metinlerini yazabilirler.

Örnek Olay 4: Amazon

Facebook'ta fark ettiğim bir şey Amazon'da da oluyor. Arama düğmesi, DOM'deki arama giriş alanından önce görünür. Bu, düğmenin görsel olarak giriş alanından sonra görünmesine rağmen.

Web sitenizin görsel olarak mantıklı bir sırada olması muhtemeldir. Ya birisi web sayfanızın bazı bölümlerini rastgele hareket ettirirse - mantıklı olmaya devam eder mi?

Muhtemelen değil. DOM yapınızı görsel tasarımınızla uyumlu tutma konusunda disiplinli değilseniz, ekran okuyucu deneyiminize bu şekilde gelebilir. Bazen içeriği CSS ile taşımak daha kolaydır, ancak genellikle DOM'da taşımak daha iyidir.

İpucu #11: DOM sırasının görsel sıra ile eşleşmesini sağlayın.

Bu iki yüksek profilli sitenin arama navigasyonlarıyla birlikte bu en iyi uygulama kılavuzunu benimsememesinin nedeni beni şaşırtıyor. Ancak, düğme ve giriş metni o kadar uzak değildir ki, sıralamaları büyük bir erişilebilirlik sorununa neden olur.

Amazon'daki Başlıklar

Yine Facebook gibi Amazon'da da garip bir başlık düzeni var. Başlıklar aracılığıyla arama yaptım ve sayfadaki ilk başlığın "Amazon'daki Diğer Satıcılar" bölümünde 5. seviye bir başlık olduğu konusunda kafam karıştı:

Bunun ekran okuyucuyla ilgili bir hata olduğunu düşündüm, bu yüzden kontrol etmek için Amazon'un kaynak kodunu araştırdım:

Sayfanın h1'i kaynak kodunda yaklaşık 10.000 satır aşağıda görünüyor.

Bu sadece semantik olarak ve erişilebilirlik açısından zayıf olmakla kalmaz, aynı zamanda SEO için de zayıftır. Kötü SEO, daha az dönüşüm (satış) anlamına gelir - Amazon'un çok üstünde olmasını beklediğim bir şey!

İpucu #12: Erişilebilirlik ve SEO aynı madalyonun iki yüzüdür.

Ekran okuyucu deneyimini geliştirmek için yaptığımız birçok şey SEO'yu da iyileştirecektir. Semantik olarak geçerli başlıklar ve ayrıntılı alt metin, arama motoru tarayıcıları için harikadır; bu, sitenizin aramada daha üst sıralarda yer aldığı ve daha geniş bir kitleye ulaşacağınız anlamına gelir.

İşletme yöneticinizi erişilebilir siteler oluşturmanın önemli olduğuna ikna etmekte zorlanıyorsanız, farklı bir açı deneyin ve bunun yerine SEO avantajlarına dikkat edin.

Çeşitli

Bir günlük tarama ve deneyimleri tek bir makaleye sığdırmak zor. İşte kesimi yapan bazı önemli noktalar ve vurgular.

Yavaş Siteleri Fark Edeceksiniz

Ekran okuyucular, DOM yüklenene kadar sayfayı ayrıştıramaz ve erişilebilirlik ağacını oluşturamaz. Gören kullanıcılar bir sayfayı yüklenirken tarayabilir, zaman ayırmaya değer olup olmadığını hızlı bir şekilde belirleyebilir ve değilse geri düğmesine basabilir. Ekran okuyucu kullanıcılarının sayfanın %100'ünün yüklenmesini beklemekten başka seçeneği yoktur.

Performanslı bir web sitesi yapmak herkese fayda sağlarken, özellikle ekran okuyucu kullanıcıları için faydalı olduğunu belirtmek ilginçtir.

Neyi Kabul Ediyorum?

NatWest'ten alınan bunun gibi form kontrolleri, ilişkileri belirtmek için büyük ölçüde uzaysal yakınlığa bağlı olabilir. Ekran okuyucu alanında, uzaysal bir yakınlık yoktur - yalnızca kardeşler ve ebeveynler - ve neye 'evet' dediğinizi bilmek için tahminde bulunmanız gerekir.

Feragatname etiketin bir parçası olsaydı neyi kabul ettiğimi bilirdim:

 <label> Important: We can only hold details of one trip at a time. <input type="checkbox" /> Tick to confirm you have read this. * </label>

Aşağıdaki Kod Bir Kabus

Ekran okuyucumu kullanarak CSS Püf Noktaları hakkında teknik bir makale okumaya çalıştım, ancak dürüst olmak gerekirse, bu deneyimi takip etmeyi tamamen imkansız buldum. Bu, CSS Tricks web sitesinin hatası değil - teknik fikirleri ve kod örneklerini tamamen işitsel bir şekilde açıklamanın inanılmaz derecede karmaşık olduğunu düşünüyorum. Bir ortakla hata ayıklamayı kaç kez denediniz ve ihtiyacınız olan söz dizimini tam olarak açıklamak yerine, onlara kopyalayıp yapıştırmaları için bir şeyler verdiniz mi yoksa kendiniz mi doldurdunuz?

Bu kod örneğini makaleden ne kadar kolay okuyabileceğinize bakın:

Ama işte ekran okuyucu versiyonu:

eğik çizgi önce görüntü alanı yüksekliğini alırız ve bir vh birimi için bir değer elde etmek için yüzde bir [duraklat] ile çarparız vh eşittir pencere iç yükseklik yıldız [duraklat] sıfır sıfır bir eğik çizgi sonra değeri [duraklat] ] vh belgenin köküne özel özellik belge belge öğesi stil kümesi özelliği [duraklat] vh dolar sol ayraç vh sağ ayraç px

Ses ortamında tamamen okunamıyor. Yorumlarda noktalama işaretleri kullanma eğilimimiz yoktur ve bu durumda, ekran okuyucu alanında bir satır diğerine sorunsuz bir şekilde akar. camelCase metni, bir cümle içinde yazılmış gibi ayrı kelimeler olarak okunur. window.innerHeight gibi noktalar yoksayılır ve "pencere iç yüksekliği" olarak değerlendirilir. Okunan tek 'kod', sonundaki süslü parantezlerdir.

Kod, standart <pre> ve <code> HTML öğeleri kullanılarak işaretlenmiştir, bu nedenle bunun ekran okuyucu kullanıcıları için nasıl daha iyi hale getirilebileceğini bilmiyorum. Kodlama konusunda sebat eden herkes benim tam bir hayranlığım var.

Aksi takdirde, bulabildiğim tek hata, sitenin logosunun ana sayfaya bir bağlantısının olması, ancak alt metnin olmamasıydı, bu yüzden tek duyduğum “bağlantı: eğik çizgi” oldu. Yalnızca bir web geliştiricisi olarak benim kapasitem dahilinde, href="/" özniteliğine sahip bir bağlantınız olup olmadığını biliyorum, o zaman sizi web sitesinin ana sayfasına götürür, bu yüzden bağlantının ne için olduğunu anladım - ancak “bağlantı: CSS Hileleri ana sayfa” daha iyi olurdu!

iOS'ta VoiceOver, OSX'ten Daha Zor

Telefonumda VoiceOver'ı kullanmak bir deneyimdi!

Kendime, ekran kapalıyken ve mobil klavyeyi kullanarak Twitter uygulamasında gezinme ve Tweet yazma görevini verdim. Beklediğimden daha zordu ve birkaç yazım hatası yaptım.

Normal bir ekran okuyucu kullanıcısı olsaydım, harici klavye kullanan ve Bluetooth klavyeye yatırım yapan mobil ekran okuyucu kullanıcılarının %41'ine katılmam gerektiğini düşünüyorum. Clara Van Gerven, 2015'te kırk gün boyunca bir ekran okuyucu kullandığında aynı sonuca vardı.

Üç parmakla üç kez dokunarak Ekran Perdesi modunu etkinleştirmek oldukça güzeldi. Bu, ekranı kapattı ancak telefonun kilidini açık tuttu, böylece kimse izlemeden telefonuma göz atmaya devam edebildim. Bu özellik, aksi takdirde omzunun üzerinden izleyen kişiye farkında olmadan şifrelerini verebilecek olan görme engelli kullanıcılar için çok önemlidir, ancak aynı zamanda pil tasarrufu için harika bir yan faydası da vardır.

Özet

Bu ilginç ve zorlu bir deneyimdi ve serinin şu ana kadar yazılması en zor makalesiydi.

Durup onları düşündüğünüzde bariz görünen küçük şeyler beni şaşırttı. Örneğin, bir ekran okuyucu kullanırken, internette gezinirken aynı anda müzik dinlemek neredeyse imkansızdır! Sayfanın içeriğini korumak da zor olabilir, özellikle bir telefon görüşmesi veya başka bir şeyle kesintiye uğrarsanız; ekran okuyucuya geri döndüğünüzde yerinizi kaybetmişsiniz demektir.

En büyük çıkarım, yalnızca sesli bir deneyime gitmenin büyük bir kültürel şok olduğudur. Web'de gezinmenin tamamen farklı bir yolu ve böyle bir karşıtlık olduğu için, neyin 'iyi' veya 'kötü' bir ekran okuyucu deneyimi oluşturduğunu bilmek bile zor. Oldukça ezici olabilir ve pek çok geliştiricinin bunları test etmekten kaçınmasına şaşmamalı.

Ama sırf zor diye yapmaktan kaçınmamalıyız. Charlie Owen'ın konuşmasında dediği gibi, Sevgili Geliştirici, Web Sizinle İlgili Değil : Bu. Dır-dir. Senin. iş . Whilst it's fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can't just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.

Let us do our jobs responsibly, and let's make life a little easier for ourselves, with my last tip of the article:

Tip #13: Test on a screen reader, little and often.

I've tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I'd have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.

Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.

Did you enjoy this article? This was the third one in a series; read how I Used The Web For A Day With JavaScript Turned Off and how I Used The Web For A Day With Just A Keyboard.