اذهب إلى المحتوى

مع تقدمنا في تعلم لغة HTML من خلال قراءة مصادر متنوعة وتطبيق مختلف الأمثلة وبناء مشاريعنا الخاصة، سنرى باستمرار سمة مشتركة، وهي استخدام المعنى الدلالي Semantic أو الدلالة التي تحملها عناصر HTML، والتي تُدعى أحيانًا POSH وهي اختصار لعبارة الدلالة الصرفة القديمة للغة HTML أو بالإنجليزية Plain Old Semantic HTML. ويعني ذلك استخدام عناصر HTML للغايات التي صممت لأجلها قدر الإمكان.

قد تكون أهمية هذا الموضوع غريبة نظرًا لإدراكنا أننا باستخدام CSS وجافا سكريبت نستطيع تغيير سلوك عناصر HTML بالطريقة التي نشاء. بحيث يمكننا مثلًا استخدام الشيفرة التالية لتشغيل فيديو ضمن موقعنا وتتولى CSS وJavaScript باقي التعديلات:

<div>Play video</div>

لكن سنرى لاحقًا وبتفاصيل أوفى أنه من المنطقي استخدام العنصر المناسب بمكانه المناسب لتنفيذ الأمر، وهو الزر الحقيقي <button>، على النحو الآتي:

<button>Play video</button>

وللتوضيح، لا تقتصر فائدة العناصر <button> على تنسيقها الملائم الذي يُطبق افتراضيًا، لكنها تدعم سهولة الوصول عبر لوحة المفاتيح؛ إذ يمكن للمستخدم التنقل بين الأزرار باستخدام المفتاح Tab وتفعيل الزر المختار من خلال المفتاح Space أو Return أو Enter.

الجيد في الأمر أن كتابة شيفرة HTML دلالية لا يستغرق وقتًا وجهدًا أكبر من كتابة الشيفرة غير الدلالية التي تُعَد ممارسةً سيئةً لسهولة الوصول؛ كما أن الشيفرة الدلالية تقدم ميزات تتعدى سهولة الوصول:

  1. أسهل تطويرًا: فكما ذكرنا، تقدم العناصر الدلالية وظائف مضمنة قد تكون أكثر وضوحًا وفهمًا
  2. أفضل للأجهزة المحمولة: فقد تكون أقل حجمًا وأسرع من العناصر غير الدلالية، كما تسهّل التصميم المتجاوب لصفحات الويب
  3. أفضل لتحسين محركات البحث SEO: تعطي محركات البحث أهمية أكبر للكلمات المفتاحية الموجودة ضمن العناوين الرئيسية والروابط مقارنةً بالكلمات المفتاحية الموجودة في عناصر غير دلالية مثل العناصر <div> مثلًا؛ ولهذا سيكون البحث عن موقعنا أسهل.

سنتابع في بقية الفقرات استكشاف ميزات سهولة الوصول التي تقدمها HTML.

ملاحظة: من الأفضل تثبيت قارئ شاشة على الحاسوب لاختبار الأمثلة التي نعرضها.

دلالات عناصر HTML

تحدثنا سابقًا عن أهمية دلالات العناصر ولماذا علينا استخدام عناصر HTML الصحيحة في مشاريعنا. وعلينا أن لا نتجاهل ذلك أبدًا لأنها النقاط الأساسية التي تُخرق فيها معايير سهول الوصول إن لم تُعالج بالطريقة الصحيحة.

سنجد في عالم الويب الحقيقي أشخاصًا يكتبون شيفرات غريبة باستخدام HTML؛ فبعضهم يسيء استخدام اللغة بتطبيق ممارسات قديمة لم تُنسى بعد، ويفعلها آخرون لجهلهم؛ لكن أيًا يكن السبب، لا بد من استبدال تلك الشيفرات السيئة.

قد لا نستطيع التخلص في بعض الأحيان من تلك الشيفرات بسهولة، فربما كانت ضمن صفحات يولّدها الخادم تلقائيًا وليس لدينا تحكم كامل بها، أو نظرًا لاستخدام محتوى يقدمه طرف خارجي مثل اللوحات الإعلانية.

المحتوى النصي

من أكثر الأشياء التي تعزز الوصول السهل لمستخدمي قارئات الشاشة هو المحتوى المهيكل بطريقة ممتازة ضمن عناوين رئيسية وفقرات وقوائم وهكذا. ويوضح المثال التالي مثالًا ممتازًا لاستخدام العناصر الدلالية:

<h1>My heading</h1>

<p>This is the first section of my document.</p>

<p>I'll add another paragraph here too.</p>

<ol>
 <li>Here is</li>
 <li>a list for</li>
 <li>you to read</li>
</ol>

<h2>My subheading</h2>

<p>
 This is the first subsection of my document. I'd love people to be able to
 find this content!
</p>

<h2>My 2nd subheading</h2>

<p>
 This is the second subsection of my content, which I think is more interesting
 than the last one.
</p>

هناك أيضًا نسخة مطولة من هذا المثال متاحة تجربها مع قارئ للشاشة. وإذا حاولنا التنقل ضمنها، سنلاحظ سهولة الأمر.

  1. ينطق قارئ الشاشة كل عنوان رئيسي عندما نتقدم في المحتوى وينبهنا إلى العناوين والفقرات وغيرها
  2. يقف قارئ الشاشة بعد كل عنصر، مما يسمح لنا بالتنقل بخطوات تناسبنا ضمن المحتوى
  3. بإمكاننا التنقل بين العنوان السابق والتالي في العديد من قارئات الشاشة
  4. بإمكاننا الحصول على قائمة بكل العناوين الأساسية في العديد من قارئات الشاشة لنستخدمها كجدول مساعد لإيجاد محتوى محدد

يكتب المطورون أحيانًا العناوين الرئيسة والفقرات باستخدام عناصر السطر الجديد <br> وإضافة عناصر HTML للتنسيق فقط كالتالي:

<span style="font-size: 3em">My heading</span> <br /><br />
This is the first section of my document.
<br /><br />
I'll add another paragraph here too.
<br /><br />
1. Here is
<br /><br />
2. a list for
<br /><br />
3. you to read
<br /><br />
<span style="font-size: 2.5em">My subheading</span>
<br /><br />
This is the first subsection of my document. I'd love people to be able to find
this content!
<br /><br />
<span style="font-size: 2.5em">My 2nd subheading</span>
<br /><br />
This is the second subsection of my content. I think is more interesting than
the last one.

ولو جرّبنا النسخة المطولة من هذا المثال باستخدام قارئ شاشة فلن نجدها تجربةً جيدة، إذ لن يجد قارئ الشاشة أية إشارات أو دلالات ليستخدمها، كما لن نتمكن من استخلاص جدول بالمحتويات, وسيرى القارئ صفحتنا على شكل كتل كبيرة، بالتالي سيقرؤها دفعةً واحدة.

هنالك أيضًا مشاكل أخرى أبعد من سهولة الوصول، إذ من الصعب تنسيق المحتوى لاحقًا باستخدام CSS أو التعامل معه باستخدام جافاسكريبت لعدم وجود عناصر لاستخدامها كمحددات Selectors.

يمكن أن تؤثر اللغة التي نستخدمها على سهولة الوصول، ولهذا علينا كتابتها بطريقة واضحة بعيدة عن التعقيد، ودون استخدام مصطلحات أو لهجات محلية، لذا لا بد من تفادي استخدام لغة ومحارف لا يمكن لقارئات الشاشة نطقها بسهولة فمثلًا:

  • لا نستخدم الشرطات إن أمكن تحاشيها. فبدلًا من كتابة 5-7 تكتب من 5 إلى 7
  • نكتب الاختصارات بعبارتها الكاملة، فبدلًا من كتابة Jan نكتب January
  • نكتب اختصار عبارة بالكامل مرة أو مرتين على الأقل، ثم نستخدم العنصر <abb> لوصفه

تخطيط الصفحة

استخدم المطورون قديمًا جداول HTML لتخطيط صفحات الويب، واستخدموا خلايا الجدول لتضم الترويسة والتذييل والأشرطة الجانبية وأعمدة المحتوى الرئيسي. وبطبيعة الحال، لا يُعَد ذلك الآن أمرًا مقبولًا لأن قارئ الشاشة سيقرأ المحتوى غالبًا بطريقة مربكة، خاصةً إن كان التخطيط معقدًا ويضم عدة جداول متداخلة.

لنجرّب المثال table-layout.html الذي يبدو مشابهًا للشيفرة التالية:

<table width="1200">
 <!-- main heading row -->
 <tr id="heading">
  <td colspan="6">
   <h1 align="center">Header</h1>
  </td>
 </tr>
 <!-- nav menu row -->
 <tr id="nav" bgcolor="#ffffff">
  <td width="200">
   <a href="#" align="center">Home</a>
  </td>
  <td width="200">
   <a href="#" align="center">Our team</a>
  </td>
  <td width="200">
   <a href="#" align="center">Projects</a>
  </td>
  <td width="200">
   <a href="#" align="center">Contact</a>
  </td>
  <td width="300">
   <form width="300">
    <label
     >Search
     <input
      type="search"
      name="q"
      placeholder="Search query"
      width="300" />
    </label>
   </form>
  </td>
  <td width="100">
   <button width="100">Go!</button>
  </td>
 </tr>
 <!-- spacer row -->
 <tr id="spacer" height="10">
  <td></td>
 </tr>
 <!-- main content and aside row -->
 <tr id="main">
  <td id="content" colspan="4">
   <!-- main content goes here -->
  </td>
  <td id="aside" colspan="2" valign="top">
   <h2>Related</h2>

   <!-- aside content goes here -->
  </td>
 </tr>
 <!-- spacer row -->
 <tr id="spacer" height="10">
  <td></td>
 </tr>
 <!-- footer row -->
 <tr id="footer">
  <td colspan="6">
   <p>©Copyright 1996 by nobody. All rights reversed.</p>
  </td>
 </tr>
</table>

لو حاولنا التنقل بين عناصر المثال عبر قارئ شاشة، فقد يخبرنا بوجود جدول علينا إلقاء نظرة عليه، وعندها من المحتمل وفقًا للقارئ الذي نستخدمه أن ننزل للأسفل لتفقد الجدول والنظر إلى ما يقدمه بشكل منفصل وغير مترابط ومن ثم الخروج من الجدول لمتابعة التنقل ضمن المحتوى.

يعود التخطيط القديم للجدول إلى الأيام التي لم تدعم فيها المتصفحات لغة CSS كفاية؛ أما الآن، فهو مصدر لإرباك التقنيات المساعدة مثل قارئات الشاشة. إضافةً إلى ذلك، تحتاج شيفرته المصدرية إلى الكثير من الأسطر، مما يجعله أقل مرونةً وأصعب صيانةً. ولنقف على صحة ما نقوله، لا بد من مقارنة تجربتنا للمثال السابق مع مثال يستخدم هيكلية حديثة لصفحة الويب، والذي قد يبدو بالشكل التالي:

<header>
 <h1>Header</h1>
</header>

<nav>
 <!-- main navigation in here -->
</nav>

<!-- Here is our page's main content -->
<main>
 <!-- It contains an article -->
 <article>
  <h2>Article heading</h2>

  <!-- article content in here -->
 </article>

 <aside>
  <h2>Related</h2>

  <!-- aside content in here -->
 </aside>
</main>

<!-- And here is our main footer that is used across all the pages of our website -->

<footer>
 <!-- footer content in here -->
</footer>

إن جربنا النسخة ذات الهيكلية الحديثة على صفحة الويب باستخدام قارئ شاشة، فلن نلاحظ حينها تداخلًا أو اختلاطًا عند قراءة المحتوى؛ كما أن شيفرته أقل حجمًا، مما يعني وجود سهولة في صيانة الشيفرة، واستهلاكًا أقل لحزم البيانات، وبالتالي فائدة مضاعفة، خاصةً لمن يعاني من انترنت بطيء.

من الأشياء التي يجب أخذها أيضًا بالحسبان عند إنشاء تخطيط الصفحة، استخدام عناصر HTML دلالية كما عرضنا في مثال سابق؛ إذ بإمكاننا استخدام تخطيط باستخدام عناصر <div> متداخلة، لكن من الأفضل استخدام عناصر تقسيم الصفحة للتغليف مثل <nav> و <footer> وعناصر تكرار المحتوى مثل <article>، مما يعطي قيمةً دلالية أكبر لقارئ الشاشة وغيره من التقنيات، ويقدم إشارات أوضح عن المحتوى الذي ينتقل إليه المستخدم.

ملاحظة: إضافةً إلى القيمة الدلالية الجيدة، والتخطيط الجذاب، لا بد من ترتيب عناصر المحتوى منطقيًا في الشيفرة المصدرية. بإمكاننا طبعًا وضعها في المكان الذي نريد لاحقًا باستخدام CSS، لكن لا بد من البدء بالترتيب المنطقي للعناصر حتى يكون ما تقرؤه قارئات الشاشة أوضح وأكثر منطقيةً لمستخدميها.

عناصر تحكم واجهة المستخدم

نقصد بعناصر تحكم واجهة المستخدم UI بالأجزاء الرئيسية التي يتفاعل معها المستخدم في صفحة الويب وأكثرها شيوعًا الأزرار والروابط واستمارات الويب. سنناقش في هذا القسم بعض النقاط الأساسية التي يجب الانتباه لها عند إنشاء عناصر التحكم لدعم سهولة الوصول؛ كما سنناقش في مقال تالٍ اعتبارات أخرى تتعلق بهذه العناصر.

من ميزات سهولة الوصول الافتراضية الخاصة بعناصر التحكم هي إمكانية التعامل معها عن طريق لوحة المفاتيح في معظم المتصفحات. بإمكاننا تجريب الأمر من خلال المثال native-keyboard-accessibility.html، والذي يمكن إلقاء نظرة على شيفرته المصدرية).

نفتح المثال في نافذة جديدة للمتصفح ونجرّب الضغط على المفتاح Tab، وسنجد بعد عدة ضغطات أن تركيز الدخل سينتقل من عنصر إلى آخر. ولكل عنصر يكتسب تركيز الدخل تظليل مميز يختلف من متصفح لآخر من أجل تمييز أن هذا العنصر قد اكتسب تركيز الدخل.

01 button focused unfocused

ملاحظة: بإمكاننا تفعيل طبقة تعرض ترتيب التنقل بين العناصر باستخدام Tab من خلال أدوات مطوري ويب في متصفحنا.

عندما يكتسب العنصر تركيز الدخل، سنتمكن من النقر على الزر أو على الرابط بالضغط على المفتاح Enter/Return أو الكتابة ضمن العنصر. ولعناصر استمارات الويب المختلفة عناصر تحكم مختلفة، إذ يضم العنصر <select> مثلًا عناصر <option> يمكن التنقل بينها من خلال مفاتيح الأسهم (أعلى وأدنى).

ملاحظة: تختلف خيارات التحكم بالعناصر عبر لوحة المفاتيح من متصفح لآخر.

وهذا السلوك الافتراضي الذي يدعم سهولة الوصول سيكون جاهزًا للاستخدام دون أي عناء، فقط باستخدام العنصر الصحيح، أي باستخدام عناصر مثل الأزرار والروابط والاستمارات بما في ذلك العناصر <label>.

<h1>Links</h1>

<p>This is a link to <a href="https://www.mozilla.org">Mozilla</a>.</p>

<p>
 Another link, to the
 <a href="https://developer.mozilla.org">Mozilla Developer Network</a>.
</p>

<h2>Buttons</h2>

<p>
 <button data-message="This is from the first button">Click me!</button>
 <button data-message="This is from the second button">Click me too!</button>
 <button data-message="This is from the third button">And me!</button>
</p>

<h2>Form</h2>

<form>
 <div>
  <label for="name">Fill in your name:</label>
  <input type="text" id="name" name="name" />
 </div>
 <div>
  <label for="age">Enter your age:</label>
  <input type="text" id="age" name="age" />
 </div>
 <div>
  <label for="mood">Choose your mood:</label>
  <select id="mood" name="mood">
   <option>Happy</option>
   <option>Sad</option>
   <option>Angry</option>
   <option>Worried</option>
  </select>
 </div>
</form>

مع ذلك، يستخدم المطورون أحيانًا HTML بطريقة غريبة، فقد نجد أحيانًا أزرارًا مكتوبةً باستخدام عناصر <div> كما في المثال التالي:

<div data-message="This is from the first button">Click me!</div>
<div data-message="This is from the second button">Click me too!</div>
<div data-message="This is from the third button">And me!</div>

طبعًا، لا يُنصح باستخدام HTML بهذا الشكل، إذ سنخسر الوصول السهل عبر لوحة المفاتيح مباشرةً، والتي يمكن أن نضمنها لو استخدمنا العنصر <button>، كما لن نحصل أيضًا على تنسيق CSS افتراضي.

في الحالات النادرة -ومستحيلة الوجود- التي نُضطر فيها إلى ذلك، علينا استخدام الخاصية role=button مع عناصر أخرى لكي نجعلها على هيئة أزرار، وعلينا إنجاز جميع وظائف الأزرار بنفسنا، بما في ذلك التفاعل مع الفأرة ولوحة المفاتيح.

بناء دعم لسهولة الوصول عبر لوحة المفاتيح

يحتاج مثل هذا الدعم إلى القليل من العمل، ويمكن لأجل ذلك الاطلاع على المثال fake-div-buttons.html، وإلقاء نظرة على شيفرته المصدرية)، فكما يبدو مُنحت الأزار المزيفة <div> إمكانية التقاط تركيز الدخل بما في ذلك حالة استخدام المفتاح Tab، وذلك عن طريق ضبط قيمة الخاصية tabindex لكل زر على القيمة "0"، كما أضيفت الخاصية "role="button لتتعرف قارئات الشاشة عليها عند اكتسابها تركيز الدخل أو عند التفاعل معها:

<div data-message="This is from the first button" tabindex="0" role="button">
 Click me!
</div>
<div data-message="This is from the second button" tabindex="0" role="button">
 Click me too!
</div>
<div data-message="This is from the third button" tabindex="0" role="button">
 And me!
</div>

إن الوظيفة الأساسية للخاصية tabindex هي السماح بتغيير ترتيب الانتقال بين العناصر الأصلية التي تدعم التنقل باستخدام المفتاح Tab على شكل قيم عددية موجبة، بدلًا من طريقة التنقل الافتراضية وفقًا لموقعها في الشيفرة المصدرية. ويُعد هذا الأسلوب خاطئًا في معظم الحالات، لأنه قد يسبب اختلاطًا حقيقيًا؛ لذا من المهم استخدامه حصرًا عند الحاجة له، مثل الحالة التي يعرض فيها تخطيط صفحة الويب العناصر بطريقة بصرية مختلفة تمامًا عن ترتيب ظهورها في الشيفرة المصدرية، وأردنا أن يكون التنقل منطقيًا أكثر. وهناك خياران للخاصية tabindex:

  • "tabindex="0: تتيح للعناصر التي لا تدعم التنقل باستخدام المفتاح Tab أن تدعم، وهي القيمة الأكثر أهمية
  • "tabindex="-1: تتيح للعناصر التي لا تدعم التنقل باستخدام المفتاح Tab إمكانية استقبال تركيز الدخل برمجيًا باستخدام جافاسكريبت مثلًا، أو كهدف لرابط تشعّبي

ومع أن النسخة السابقة من المثال ستدعم التنقل بين الأزرار، إلا أنها لن تسمح لنا بتفعيل هذه الأزرار بالضغط على المفتاح Enter/Return. ولحل هذه المسألة، لا بد من استخدام جافاسكريبت كما يلي:

document.onkeydown = (e) => {
 // The Enter/Return key
 if (e.key === "Enter") {
  document.activeElement.click();
 }
};

وشرح ما فعلناه، فقد أضفنا هنا مترصد أحداث للكائن document لالتقاط الضغط على أي مفتاح من لوحة المفاتيح، ثم نتحقق من المفتاح الذي ضغطه المستخدم الخاصية key لكائن الحدث. فإن كان المفتاح المضغوط Enter/Return، معناها ننفذ الدالة المخزّنة في المعالج onclick من خلال العبارة ()document.activeElement.click؛ إذ يعطينا الكائن activeElement العنصر الحالي الذي تلقى تركيز الدخل في الصفحة.

هناك الكثير من الأشياء التي يجب علينا الاهتمام بها عند بناء مثل هذه الوظائف، إذ ترتبط بها مشاكل عدة، ولهذا من الأفضل استخدام العناصر المناسبة للعمل المناسب في المقام الأول.

نصوص واضحة ومعبرة للعناوين

للعناوين التي ترتبط بعناصر تحكم واجهة المستخدم فوائد كثيرة لجميع المستخدمين، لكن استخدامها بالطريقة الصحيحة له أهمية خاصة بالنسبة لذوي الإعاقة.

علينا في البداية أن نتأكد من أن النص المرافق للزر أو الرابط مفهوم ومميز، بحيث لا نستخدم مثلًا عبارات مثل انقر هنا Click here كعناوين، فقد تكون هناك قائمة من الأزرار يصعب على مستخدمي قارئات الشاشة تتبعها بهذا الشكل. تعرض لقطة الشاشة التالية قائمة بعناصر التحكم في مثالنا وضعها قارئ الشاشة VoiceOver على ماك أو اس:

02 voiceover formcontrols

نتأكد هنا من أن العناوين التي نضعها منطقية حتى لو خارج سياق ورودها، بحيث يمكن أن تُفهم عند قراءتها ضمن سياقها المخصص أو خارجه. تعرض الشيفرة التالية مثلًا عن نص جيد لرابط تشعبي:

<p>
 Whales are really awesome creatures.
 <a href="whales.html">Find out more about whales</a>.
</p>

لكن التالي يْعَد مثالًا سيئًا:

<p>
 Whales are really awesome creatures. To find out more about whales,
 <a href="whales.html">click here</a>.
</p>

ملاحظة: بإمكاننا الإطلاع على ممارسات جيدة وسيئة من خلال المثالين good-links.html و bad-links.html.

تُعد عناوين عناصر التحكم في استمارات الويب مهمة، فهي تقدم تلميحات عما يجب إدخاله ضمن كل عنصر إدخال. وفي ما يلي مثال منطقي عن الأمر:

Fill in your name: <input type="text" id="name" name="name" />

لكن هذا الأمر ليس ذا أهمية لذوي الإعاقة، فلا شيء يربط العنوان بوضوح بعنصر الإدخال النصي ويوضح كيفية ملئه إن لم تكن رؤيته ممكنة. ولو جربنا المثال باستخدام قارئات الشاشة، فقد نحصل فقط على وصف لعناصر الإدخال يقول عدل النص edit text.

أما المثال التالي، فيقدم حلًا أفضل:

<div>
 <label for="name">Fill in your name:</label>
 <input type="text" id="name" name="name" />
</div>

يرتبط العنوان في هذه الشيفرة بعنصر الإدخال بوضوح، وسيكون وصف قارئ الشاشة على الشكل " أدخل اسمك: عدل النص Fill in your name: edit text".

03 voiceover good form label

وكفائدة إضافية، سيمنحنا ربط عنوان بعنصر إدخال، إمكانية النقر على العنوان لتفعيل عنصر الإدخال، مما يمنحنا مساحةً واسعةً لتنقر فيها ويسهل اختيار العنصر.

ملاحظة: يمكن الإطلاع على ممارسات جيدة وسيئة عند بناء الاستمارات من خلال المثالين good-form.html و bad-form.html.

سهولة الوصول إلى جداول البيانات

يمكن كتابة جدول بيانات بسيط من خلال شيفرة HTML بسيطة كالتالي:

<table>
 <tr>
  <td>Name</td>
  <td>Age</td>
  <td>Pronouns</td>
 </tr>
 <tr>
  <td>Gabriel</td>
  <td>13</td>
  <td>he/him</td>
 </tr>
 <tr>
  <td>Elva</td>
  <td>8</td>
  <td>she/her</td>
 </tr>
 <tr>
  <td>Freida</td>
  <td>5</td>
  <td>she/her</td>
 </tr>
</table>

لكن المشكلة في هذه الشيفرة هي عدم قدرة قارئات الشاشة على ربط الصفوف بالأعمدة لتجميع البيانات. ولفعل ذلك، لا بد من تحديد سطور الترويسة Header Rows إن كانت في أعلى الأسطر أو الأعمدة، وهكذا. بطبيعة الحال، لا يمكن تنفيذ ذلك على الجدول السابق إلا مرئيًا. ولأجل ذلك، يمكن إلقاء نظرة على المثال bad-table.html وتجربه، ثم الاطلاع على المثال punk bands table example والذي سنرى فيه بعض النقاط التي تدعم سهول الوصول.

عُرِّفت ترويسات الجدول من خلال عناصر <th> ويمكن تحديد ما إذا كانت ترويسات لأسطر أو أعمدة من خلال الخاصية scope. وهذا ما يعطي مجموعةً مترابطةً من البيانات التي يمكن لقارئات الشاشة تقديمها ككتلة واحدة.

للعنصر <table> والخاصية summary نفس العمل، وهو تقديم نص بديل عن الجدول، مما يمنح مستخدمي قارئ الشاشة وصفًا سريعًا لمحتويات الجدول. ويُفضَّل عادةً العنصر <caption>، لأنه يتيح للمستخدمين الطبيعيين القدرة على الوصول إلى محتواه أيضًا، فقد يجدونه مفيدًا، ولن نحتاج في الواقع إلى كلا العنصرين.

النصوص البديلة

يُعَد الوصول السهل إلى المحتوى النصي محققًا دائمًا، لكن الوضع ليس كذلك بالنسبة للوسائط المتعددة؛ إذ لا يمكن رؤية الصورة والفيديو من قبل ذوي الإعاقات البصرية، ولن يستطيع ذوو الإعاقات السمعية فهم المحتوى الصوتي. لن نغطي هذا الموضوع بهذا المقال، لكننا سنلقي نظرةً على سهولة الوصول إلى عنصر الصور <img> فقط. لأجل ذلك، يمكن الاطلاع على هذا المثال accessible-image.html الذي يقدم أربعة نسخ عن نفس الصورة:

<img src="dinosaur.png" />

<img
 src="dinosaur.png"
 alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth." />

<img
 src="dinosaur.png"
 alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth."
 title="The Mozilla red dinosaur" />

<img src="dinosaur.png" aria-labelledby="dino-label" />

<p id="dino-label">
 The Mozilla red Tyrannosaurus Rex: A two legged dinosaur standing upright like
 a human, with small arms, and a large head with lots of sharp teeth.
</p>

وكما هو واضح، عندما تُعرض الصورة الأولى من خلال قارئ شاشة، فلن تقدم تلك الفائدة الحقيقية لمستخدمه، إذ سيقرأ مثلًا برنامج VoiceOver الصورة على النحو: "dinosaur.png, image"، أي يقرأ فقط عنوان ملف الصورة. وكل ما يمكن للقارئ فهمه هو أن الصورة عن ديناصور ما، لكن وبما أن الملفات قد تُحمَّل بأسماء توّلد آليًا من قبل كاميرا رقمية مثلًا، فلن تقدم هذه الأسماء أية فائدة لتوضيح محتوى الصورة.

ملاحظة: لهذا لا ينبغي أبدًا إضافة محتوى نصي ضمن صورة، إذ لن تصل إليه قارئات الشاشة؛ وللأمر أيضًا مساوئ عدة، فلن نتمكن مثلًا من نسخه ولصقه في مكان آخر.

عندما يصل قارئ الشاشة إلى الصورة الثانية، سيقرأ مايلي:

A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth

تشير هذه الحالة إلى أهمية استخدام نص بديل حتى لو كان اسم ملف الصورة معبرًا، لهذا من المهم التأكد من استخدام الخاصية alt قدر الإمكان، مع الانتباه إلى أن محتوى هذه الخاصية سيقدم وصفًا للصورة وما تعرضه؛ كما يجب أن يكون الوصف مختصرًا ومعبرًا ويوصل كل المعلومات التي تعرضها الصورة، والتي لا تتكرر في المحتوى النصي المحيط بها.

يختلف محتوى الخاصية alt لنفس الصورة وفق السياق؛ فإن كانت صورة هي لجرو صغير Fluffy مثلًا بجانب مراجعة عن طعام كلاب، فسيكون المحتوى "alt="fluffy كافيًا في هذا السياق، لكن إن كانت ضمن صفحة لتبني الكلاب، فسيختلف حينها محتوى الخاصية alt لتلائم السياق، وذلك بتقديم وصف لهذه الصورة مثل alt="Fluffy, a tri-color terrier with very short hair, with a tennis ball in her mouth." بعد التأكد من عدم تكرار نفس الوصف في المحتوى النصي الذي يحيط بالصورة.

وطالما أن المحتوى النصي الذي يحيط بالصورة قد يعرض فصيلة الكلب وحجمه، فلا حاجة لوضعها ضمن محتوى alt، لكن قد لا يعرض المحتوى النصي معلومات عن طول شعر الكلب ولونه وألعابه المفضلة مثلًا، فقد وضعت ضمن محتوى alt.

لا بد من نقل المعلومات التي توصلها الصورة إلى المستخدم المبصر وتتعلق بسياق الموضوع المطروح في الصفحة، وذلك عبر محتوى alt فقط. لذا من المهم إبقاؤه قصيرًا ودقيقًا ومفيدًا.

لا ينبغي إضافة أية معلومات شخصية أو توصيفات زائدة، لأنها لن تفيد أشخاصًا لم يروها أو يختبروها مسبقًا؛ فإن كانت الكرة هي لعبة الجرو المفضلة مثلًا أو لم يتمكن صحيحو البصر من تمييز ذلك من الصورة، فلا حاجة لذكر ذلك.

ومن الأشياء التي يجب أخذها بالحسبان هو أن يكون للصور معنى محدد في السياق الذي نورده أو أنها فقط للزينة؛ فإن كانت لمجرد الزينة، فمن الأفضل عندها وضع نص فارغ، كقيمة للخاصية alt أو أن نضع هذه الصور في الصفحة على شكل خلفية باستخدام CSS.

ملاحظة: يمكن الاطلاع على المقالين: "الصور المتجاوبة" و "الصور في HTML" لمزيد من المعلومات عن إدراج الصور في صفحات الويب وأفضل الممارسات المتبعة في تنفيذ الأمر.

وإن لم نشأ إضافة معلومات نصية كثيرة عن الصورة، فيمكن وضع هذه المعلومات في المحتوى النصي الذي يحيط بها أو ضمن الخاصية title كما في الشيفرة السابقة؛ إذ ستقرأ معظم قارئات الشاشة محتوى الخاصية alt ومحتوى الخاصية title واسم ملف الصورة، كما ستعرض المتصفحات محتوى title عندما تمرر مؤشر الفأرة فوق الصورة.

04 title attribute

لنلق نظرةً سريعةً على الطريقة الرابعة:

<img src="dinosaur.png" aria-labelledby="dino-label" />

<p id="dino-label">The Mozilla red Tyrannosaurus…</p>

لم نستخدم في هذه الحالة الخاصية alt بل قدمنا وصفًا للصورة ضمن فقرة نصية نمطية وأعطيناها معرفًا فريدًا id واستخدمنا بعدها الخاصية aria-labelledby للإشارة إلى المعرّف السابق، مما سيدفع قارئ الشاشة لاستخدام محتوى الفقرة النصية على أنه محتوى alt الخاص بالصورة. ولهذه الطريقة فائدتها إن أردت استخدام النص نفسه كعنوان لعدة صور وهذا غير ممكن أحيانًا باستخدام alt.

ملاحظة: الخاصية aria-labelledby هي جزء من مواصفة WAI-ARIA التي تتيح للمطورين إضافة دلالات لعناصر صفحة الويب لتحسين سهولة الوصول عندما يتطلب الأمر ذلك.

الأشكال وعناوين الأشكال

تتضمن لغة HTML عنصرين لربط شكل من أي نوع، وهما <figure> و <figcaption>:

<figure>
 <img
  src="dinosaur.png"
  alt="The Mozilla Tyrannosaurus"
  aria-describedby="dinodescr" />
 <figcaption id="dinodescr">
  A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a
  human, with small arms, and a large head with lots of sharp teeth.
 </figcaption>
</figure>

على الرغم من وجود عدة طرق لدعم قارئات الشاشة في ربط الأشكال بعناوينها، إلا أن تضمين الخاصيتين aria-labelledby أو aria-describedby سينشئ هذا الرابط إن لم يكن موجودًا. ولهذا الأسلوب فائدته في تطبيق تنسيق CSS، كما يقدم طريقةً نضع فيها وصف الصورة إلى جوارها في الشيفرة المصدرية.

الخاصية alt الفارغة

نكتب الكود الآتي:

<h3>
 <img src="article-icon.png" alt="" />
 Tyrannosaurus Rex: the king of the dinosaurs
</h3>

يتضمن تصميم الصفحات أحيانًا صورًا غرضها التزيين أو الديكور فقط. وسنلاحظ في الشيفرة السابقة أن الخاصية alt للصورة فارغة، وهذا ما يتيح لقارئ الشاشة تمييز الصورة دون محاولة وصفها، إذ ينطق فقط كلمة "صورة image" أو كلمةً مشابهة.

يعود سبب استخدام الخاصية الفارغة بدلًا من تجاهلها إلى حقيقة أن قارئ الشاشة يذيع عنوان URL لملف الصورة بأكمله إن لم نضع الخاصية alt؛ فلو عدنا إلى المثال السابق التي نستخدم فيه الصورة لمجرد التزيين للعنوان الرئيسي المتعلقة به، وليس لها أي غرض آخر، فلا بد من استخدام الخاصية ""=alt ضمن العنصر <img>. ومن البدائل المستخدمة الخاصية "role="presentation وفق مواصفة ARIA، فهي توقف أيضًا من قراءة النص البديل.

ملاحظة: يمكن استخدام CSS إن أمكن لعرض الصور التزيينية.

معلومات أكثر عن الروابط التشعبية

يمكن للروابط التشعبية مثل عناصر <a> وخاصيتها href، أن تحسّن أو تسيء إلى سهولة الوصول وفقًا لطريقة استخدامها. وللروابط مظهر يوحي بسهولة الوصول، ويمكنها تعزيزه لمساعدة المستخدم في التنقل بسرعة بين أقسام المستند المختلفة. كما قد تكون مسيئةً إلى سهولة الوصول إن أزيل التنسيق الخاص بسهولة الوصول أو سببت لها جافاسكريبت سلوكًا غير متوقع.

تنسيق الروابط التشعبية

تختلف الروابط التشعبية من حيث مظهرها عن المحتوى النصي المحيط من ناحيتي ديكور الخط واللون، فهي زرقاء وتحتها خط افتراضيًا، وبنفسجية وتحتها خط عندما يكون المستخدم قد زارها سابقًا، ولها إطار عندما تتلقى تركيز الدخل.

لا ينبغي استخدام اللون بمفرده لتمييز الرابط التشعبي عن المحتوى النصي، بل يجب أن يختلف كليًا عن لون الخلفية. إضافةً إلى ذلك، ينبغي أن يختلف الرابط بصريًا عن محيطه وفق تباين مقداره 3:1 كحد أدنى بين نص الرابط والنص المحيط، وبين حالات الرابط المختلفة سواءًا كانت من نوع افتراضي، أو مُزار سابقًا، أو تلقى تركيز الدخل، وذلك بنسبة 4.5:1 بين نص الرابط في جميع الحالات السابقة وخلفية الرابط.

الحدث onclick

عادةً ما يُساء استخدام وسم المربط anchor tag مع الحدث onclick لإنشاء زر ائف بضبط قيمة الخاصية href على # أو باستخدام الأمر "(javascript:void(0" لمنع الصفحة من إعادة تحديث نفسها.

تسبب هذه القيم سلوكًا غير متوقع عند نسخ أو جر الروابط أو فتحها في نافذة جديدة أو تخزينها كعلامة Bookmark أو أثناء تحميل جافاسكريبت أو وقوع خطأ أو عند تعطيل الرابط. ينقل هذا الأمر دلالةً غير صحيحة للتكنولوجيا المساعدة مثل قارئ الشاشة، وفي هذه الحالة يُفضّل استخدام العنصر <button>؛ إذ علينا استخدام الروابط التشعبية للتنقل فقط مستخدمين عناوين URL.

الروابط الخارجية والروابط إلى موارد غير HTML

لا بد من تضمين مؤشر يصف سلوك الرابط عندما ينقر عليه المستخدم في الحالة التي سيُفتح فيها ضمن صفحة جديدة، مثل التصريح "target="_blank، أو كانت قيمة href تشير إلى ملف.

قد يرتبك ضعيفو الرؤية الذي يستخدمون قارئات الشاشة أو من لديهم صعوبات فكرية عندما تظهر نافذة جديدة فجأةً، ودون متوقع، وقد لا تشير النسخ الأقدم من قارئات الشاشة إلى هذا الأمر أصلًا.

فيما يلي شيفرة توضح كيفية كتابة كود الروابط التي تفتح نافذة جديدة:

<a target="_blank" href="https://www.wikipedia.org/"
 >Wikipedia (opens in a new window)</a
>

أما هنا فشيفرة كتابة كود رابط إلى ملف ليس HTML:

<a target="_blank" href="2017-annual-report.ppt"
 >2017 Annual Report (PowerPoint)</a
>

من المهم عند استخدام أيقونة بدلًا من نص الرابط أن نتأكد من توضيح هذا السلوك للروابط بتضمين وصف بديل مناسب.

روابط التجاوز

رابط التجاوز Skip Link أو skipnav هو عنصر <a> يُوضع -قدر الإمكان- بالقرب من بداية العنصر <body> الذي يشير إلى بداية المحتوى الرئيسي للصفحة. يسمح رابط التجاوز للمستخدمين بتجاوز المحتوى المكرر عبر الصفحات المتعددة لموقع الويب مثل ترويسة مواقع الويب وشريط التنقل الرئيسي.

لروابط التجاوز فائدتها الخاصة لمستخدمي التكنولوجيا المساعدة، مثل مفتاح التحكم، أو الأوامر الصوتية، أو جهاز الفم Mouth Stick، أو عصبة الرأس Head Wands، فقد يكون التنقل عبر الروابط المكررة لهؤلاء أمرًا مضنيًا.

التقريب

يوضع كم كبير من المحتوى التفاعلي قريبًا من بعضه, بما فيه الروابط، ولا بد من توفير مساحة كافية للفصل بينها. ولهذه المساحة الفارغة أهميتها لمن يعاني من مشاكل في التحكم الدقيق, فقد يفعّل المحتوى التفاعلي الخاطئ أثناء التنقل. يمكن خلق هذه الفراغات باستخدام خاصيات CSS مثل margin.

خاتمة

بهذا نكون قد وضحنا كيفية كتابة شيفرة HTML سهلة الوصول في مختلف المناسبات، وحددنا لأساسيات التي تهم أي مطور يتعامل مع HTML. جرب تطبيق النصائح المذكورة بالمقال واحظى باحترافية أعلى في تطوير المواقع.

ترجمة -وبتصرف- لمقال HTML: A good basis for accessibility

اقرأ أيضًا


تفاعل الأعضاء

أفضل التعليقات

لا توجد أية تعليقات بعد



انضم إلى النقاش

يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.

زائر
أضف تعليق

×   لقد أضفت محتوى بخط أو تنسيق مختلف.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   جرى استعادة المحتوى السابق..   امسح المحرر

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • أضف...