Neden Bölüm Üzerinden HTML5 makalesini Seçmelisiniz?

Birkaç gün önce, biri bana HTML'de <article> ve <section> arasındaki farkı soran bazı arkadaşlarla sohbet ediyordum. Bu, web geliştirmenin ebedi gizemlerinden biridir, orada "neden beyaz boşluk: şimdi rap, beyaz boşluk değil: sarma yok?" ve “CSS 'gri' neden 'koyu gri'den daha koyu bir renk?”.

Her zamanki cevabımı verdim: <article> 'yi yalnızca bir gazete makalesi veya bir blog yazısı olarak değil, bir giyim eşyası olarak düşünün - başka bir bağlamda yeniden kullanılabilecek ayrı bir varlık. Yani pantolonunuz bir eşyadır ve farklı bir kıyafetle giyebilirsiniz; gömleğiniz bir makaledir ve farklı pantolonlarla giyilebilir; diz boyu rugan stiletto botlarınız bir eşyadır (sadece bir tanesini giymezsiniz, değil mi?).

Spesifikasyon diyor ki:

“Makale öğesi, bir belgede, sayfada, uygulamada veya sitede tam veya bağımsız bir kompozisyonu temsil eder ve bu, prensipte bağımsız olarak dağıtılabilir veya yeniden kullanılabilir, örneğin sendikasyonda. Bu bir forum gönderisi, bir dergi veya gazete makalesi, bir blog girişi, kullanıcı tarafından gönderilen bir yorum, etkileşimli bir widget veya gadget veya herhangi bir bağımsız içerik öğesi olabilir.”

Bu nedenle, blog gönderilerinin listesini içeren bir ana sayfa, her blog gönderisi için bir tane olmak üzere bir dizi <article> öğesini saran bir <main> öğesi olacaktır. Her videonun bir <article> içine sarıldığı bir video listesi (YouTube'u düşünün), bir ürün listesi (Amazon'u düşünün) vb. için aynı yapıyı kullanırsınız. Bu <article> öğelerinin herhangi biri kavramsal olarak birleştirilebilir — her biri kendi özel sayfasında, başka bir sayfadaki bir reklamda, bir RSS beslemesinde giriş olarak vb. tek başına durabilir.

Apple'ın WatchOS'u, sayfanızın birincil içeriğini öğrenmek için <article> öğesini kullanan Reader'ı içerir. Elma diyor ki:

“Reader'ı, metin ağırlıklı web sayfalarına giden bağlantıları takip ederken otomatik olarak etkinleştirildiği watchOS 5'e getirdik. Reader'ın, belgedeki öğelerin anlamını ve amacını pekiştirmek için anlamsal işaretleme kullanarak web sayfanızın önemli kısımlarını çizmesini sağlamak önemlidir. Bir örnek üzerinden gidelim. İlk olarak, bir makale etiketine sararak sayfanın hangi bölümlerinin en önemli olduğunu belirtiyoruz.”

<article> ile HTML5 mikro verilerinin birleştirilmesi, Reader'ın küçük izleme ekranları için en uygun ekranı oluşturmasına yardımcı olur:

“Özellikle, bu başlık öğelerini makalenin içine dahil etmek, hepsinin Reader'da görünmesini sağlar. Reader ayrıca itemprop özniteliğinin değerine bağlı olarak her bir başlık öğesini farklı biçimlerde şekillendirir. itemprop kullanarak yazar, yayın tarihi, başlık ve alt başlığın belirgin bir şekilde öne çıkmasını sağlayabiliyoruz.”

Peki ya <bölüm>?

Her zamanki tavsiyem devam ediyor: <section> ile uğraşmayın veya <article> 'dan nasıl farklı olduğu konusunda endişelenmeyin. Tarayıcının HTML5 belge taslağını belirleyebilmesi için başlıklar için genel bir sarmalayıcı olarak icat edildi.

Ne? Belge anahat algoritması, yalnızca bir başlık etiketi - <h2> <h1> <h3> kullanmanın ve nasıl olduğuna bağlı olarak sihirli bir şekilde doğru başlık düzeyine "olmasını" sağlamanın bir yoludur (örn. derinden HTML5 bölümleme öğelerinde yuvalanmıştır: <article> , <section> vb.

Örneğin, CMS'nize şunları yazdınız:

 <h1>My Fabulous article</h1> <p>Lorem Ipsum Trondant Fnord</p>

Bu, bağımsız bir makale olarak gösterildiğinde mükemmel bir şekilde çalışır. Peki ya en son makalelerinizin bir listesi olan ana sayfanızda?

 <h1>My latest posts</h1> <article> <h1>My fabulous article</h1> <p>Lorem Ipsum Trondant Fnord</p> </article> <article> <h1>Another magnum opus</h1> <p>Magnum solero paddle pop</p> </article>

Bu örnekte, spesifikasyona göre, <article> öğelerinin içindeki <h1> s, mantıksal <h2> s "olur", çünkü <article> , <section> gibi bir bölümleme öğesidir .

Not : Bu yeni bir fikir değildir. 1991'de Sir Timbo Amca şunları yazdı:

“Aslında, [AAP DTD'den gelenler] başlıkları için <h1> , <h2> vb. yerine, yuvalanabilir bir <SECTION> ... </SECTION> öğesinin ve genel bir <H> öğesinin olmasını tercih ederim. <H> ... </H> bölümlerin içindeki herhangi bir seviyede gerekli Başlık seviyesini üretecektir.”

Ancak ne yazık ki, hiçbir tarayıcı HTML5 anahatlarını uygulamaz, bu nedenle <section> kullanmanın bir anlamı yoktur. Bir noktada, JAWS ekran okuyucusu belge anahat algoritmasını uygulamaya çalıştı (IE'de, ancak Firefox'ta değil) ancak hata yaparak uyguladı. Görünüşe göre tarayıcı geliştiricileri ilgilenmiyor (gerçek anoraklar için Daha Fazla Okuma bölümünde daha kötü ayrıntılar).

"Ama," diye araya girdi başka bir arkadaş sohbete, "artık tarayıcılar <h1> öğesinin <section> s içinde ne kadar derine yerleştirildiğine bağlı olarak farklı yazı tipi boyutları gösteriyor" ve bunu kanıtlamaya devam etti. Zihin karmaşası!

İşte benzer bir demo. Sol sütun, bölümlere yerleştirilmiş dört <h1> s gösterir; sağdaki sütun a, <h1> , <h2> , <h3> , <h4> iç içe yerleştirme olmadan gösterir. Firefox ekran görüntüsü, yuvalanmış <h1> s öğesinin varsayılan olarak geleneksel <h1> … <h4> etiketleriyle aynı yazı tipine sahip olduğunu gösterir:

Sonuçlar Chrome'da, Mac için Edge beta gibi Chromium türevlerinde ve Mac'te Safari'de aynıdır.

Öyleyse bu, hepimizin mutlu bir şekilde <h1> öğesini <section> s içine yerleştirip tek başlık öğemiz olarak kullanmaya başlamamız gerektiği anlamına mı geliyor?

Hayır. Çünkü bu sadece h1'lerin görsel stilinde bir değişiklik. Firefox Erişilebilirlik denetçisini devtools'ta açarsak, "seviye 2" metninin H2 gibi görünecek şekilde tasarlandığını, ancak yine de "seviye 1" olarak ayarlandığını görebiliriz - Erişilebilirlik Ağacı, seviye olarak değiştirilmemiştir. 2.

Bunu sağ sütundaki Gerçek H2 ile karşılaştırın:

Bu, erişilebilirlik ağacına bunun 2. düzey bir başlık olduğu konusunda doğru bir şekilde bilgi verildiğini gösterir. Aslında Mozilla, hesaplanan düzeyi erişilebilirlik ağacına iletmeyi denedi:

"Bununla biraz denedik... ama geri almak zorunda kaldık çünkü 11 yıllık takımımızdaki insanlar çok fazla gerilemeden (yanlışlıkla <h1> seviyelerini düşürmek ve benzeri) şikayet ettiler."

Yardımcı teknoloji kullanıcıları için uygun bir başlık hiyerarşisi hayati önem taşır. Sekizinci WebAIM ekran okuyucu kullanıcı anketinin gösterdiği gibi,

"Uygun başlık yapılarının kullanışlılığı çok yüksek, katılımcıların %86,1'i başlık seviyelerini çok veya biraz yararlı buluyor."

Bu nedenle, <h1> 'e kadar <h6> kullanmaya devam etmeli ve section yoksaymalısınız.

Asla asla Deme

“Ama..” şimdi öfkeyle, “tam bu sayfada bir <section> öğesi var!” diye kekeliyor olabilirsiniz. Ve haklısın sevgili okuyucu. "Hızlı özet", erişilebilirlik nedenleriyle bir <section> içine sarılmıştır. Ekran okuyucu kullanıcısı Leonie Watson, “Bir Ekran Okuyucu Kullanıcısı Web'e Nasıl Erişir” adlı web seminerini verdiğinde, deneyimini daha iyi hale getirmek için Smashing Magazine'in işaretlemesinin değiştirilebileceği bir alana dikkat çekti.

Ekran görüntüsünden de görebileceğiniz gibi, Smashing makalelerinden önce hızlı bir özet gelir, ardından özeti uygun makaleden ayıran yatay bir çizgi gelir.

Ancak ayırıcı tamamen dekoratif olduğundan Leonie özetin nerede bitip makalenin nerede başladığını anlayamadı. Bir düzeltme önerdi: özeti bir <section> öğesiyle sardık:

 <section aria-label="quick summary"> Summary text </section>

Çoğu ekran okuyucuda, erişilebilir bir ada sahip olmadığı sürece bir <section> öğesi duyurulmaz. Bu durumda, arya etiketinin metni. Şimdi, ekran okuyucusu "Hızlı özet bölgesi"ni ve özetin ardından "Hızlı özet bölgesi bitişi"ni duyurdu. Bu basit işaretleme aynı zamanda bir ekran okuyucu kullanıcısının isterlerse özeti atlamasını da mümkün kılar.

Basit bir <div> kullanabilirdik ama sonra, Marco Zehe'nin yazdığı gibi,

"Genel bir kural olarak, bir şeyi aria-label veya aria-labeledby aracılığıyla etiketlerseniz, uygun bir widget'a veya önemli bir role sahip olduğundan emin olun."

Bu nedenle, <div role=”region” aria-label=”quick summary”> kullanmak yerine, yerleşik bir bölge rolüne sahip olduğundan ve Bruce'un yanılmaz ARIA yasası geçerli olduğundan <section> seçtik: yerleşik vuruşlar cıvata- üzerinde. Büyük ölçüde.

Çözüm

Umarım, bu eve dönüşlerle uzaklaşmışsınızdır:

• Bir sürü <h1> s kullanmayın. <h1> sayfanızın ana başlığı yapın, ardından <h2> , <h3> , <h4> , vb. öğelerini seviyeleri atlamadan uygun bir hiyerarşide kullanın.
• <section> , bir makalenin belirli bir alt bölümünün başladığı ve bittiği bir ekran okuyucu kullanıcısına sinyal vermek için aria etiketiyle birlikte kullanılabilir. Aksi takdirde, unutun veya <aside aria-label=”quick summary”> veya <div role=”region” aria-label=”quick summary”> gibi başka bir öğe kullanın.
• <main> , <header> , <footer> ve <nav> ekran okuyucu kullanıcıları için çok kullanışlıdır ve yardımcı teknoloji kullanmayanlar için tamamen şeffaftır. Bu yüzden onları kullanın.
• <article> yalnızca blog gönderileri için değil, bağımsız herhangi bir şey içindir. Ayrıca WatchOS'un içeriğinizi düzgün bir şekilde görüntülemesine yardımcı olur.

Leonie Watson'ın bu makaleyi yazmadaki yardımını minnetle kabul ediyorum. Herhangi bir hata tamamen onun hatasıdır.

Daha fazla okuma

• “Başlıklar ve Bölümler”, HTML 5.2 W3C Tavsiyesi (14 Aralık '17) Uyarısına dikkat edin: “Şu anda anahat algoritmasının bilinen hiçbir yerel uygulaması yok… Bu nedenle, belge yapısını kullanıcılara iletmek için anahat algoritmasına güvenilemez. Yazarlar, belge yapısını iletmek için başlık sıralamasını (h1-h6) kullanmalıdır.
• “Belge Anahattı Algoritması Yok,” Adrian Roseli Kesitleme algoritmasının belirtiminin nasıl değiştiğine dair tüm kanlı ayrıntılar.
• “HTML'de ARIA,” W3C Editörünün Taslağı (19 Aralık '19) Kendinizi HTML'ye ARIA rolleri ve nitelikleri eklerken bulursanız, uymanız gereken kurallar.
• The Practical Value Of Semantic HTML,” Bruce Lawson WatchOS'un HTML5 ve mikro verileri nasıl kullandığına ilişkin ayrıntılara bağlantı veren kendi makalem.