Визначення взаємодії

Більша частина сучасної Web активно використовує крім HTML додаткові технології. Навіть щось базове, таке як CSS, можна використовувати таким чином, що зробить сторінку або взаємодія значно менш доступними. Ключовим моментом доступності у взаємодії є початок з найпростіших взаємодій і використання їх як будівельних блоків більше складних взаємодій. Зазначимо, що завдання цього прикладу – змусити вас подумати про роль, яку відіграють різні об'єкти на Web-сторінці. Щоб забезпечити їх доступність, вони повинні бути семантично змістовні як з позиції використаних елементів HTML, так і використаної візуальної метафори. Якщо ви вважаєте це надто заплутаним, то перечитайте приклад кілька разів, і розгляньте кілька меню та інших компонентів Web-сторінки, думаючи при цьому не тільки про те, що використовується правильний код HTML, але також про те, що вдале подання компонента має сенс із точки зору його функції. Ви навряд чи будете чекати, що відвідувач Web-сторінки для пошуку буде використовувати текстове поле помічене "введіть свою адресу e-mail, щоб підписатися на цю розсилку", і також не будете чекати, що зрячий відвідувач зможе знайти що цікавить його контент, якщо всі заголовки будуть оформлені також як звичайний текст (аналогічно, ви не будете чекати, що сліпий користувач знайде цікавий для його контент, якщо всі "заголовки" будуть, насправді, просто параграфами, які зроблені крупніше за допомогою CSS або елементів font).

Гарним прикладом цього є широко використовувана візуальна метафора вкладок. Метафора вкладки створена на основі архівних папок, індексованих по темі. Це було перенесено на комп'ютери, щоб дозволити одній області на екрані виводити інформацію з різних тем, представленим вкладками, з'єднаними з цією областю - можна бачити гарний приклад використання вкладок на сайті http://dev.opera.com – подивіться на них вгорі сторінки. До цих пір все це досить просто. Проблема лежить в технологіях, що використовуються для створення вкладок – вони часто реалізуються за допомогою JavaScript. Як тільки вкладки починають використовуватися як частина взаємодії більш складного, ніж просто презентація користувачам можливості вибирати інформацію, вихідна метафора буде порушена, але часто використовується все ще такий же код для представлення вкладок. У прикладі нижче HTML показує, як виглядає елемент керування вкладками, який виводить інформацію:

<div class="tabcontrol">

<div class="hd">

<ul>

<li><a href="#dogs" class="selected">Dogs</a></li>

<li><a href="#cats">Cats</a></li>

<li><a href="#fish">Fish</a></li>

</ul>

</div>

<div class="bd">

<p id="dogs" class="selected">Some information about dogs.

The dogs tab is the default tab.</p>

<p id="cats">Some information about cats.</p>

<p id="fish">Some information about fish.</p>

</div>

</div>

У цьому прикладі буде використовуватися клас selected для визначення, яка вкладка повинна мати графічне представлення "вибраної вкладки". Така структура чудово підходить для інформаційного контенту. У цьому прикладі буде використовуватися class зі значенням selected для вказівки, яка вкладка є активною, тобто вкладкою, яка відкрита і показує свою інформацію; інші вкладки будуть закриті (тобто їх параграфи приховані), поки не будуть виконаний клацання на відповідних їм посиланнях. Вкладка dogs є використовуваної за замовчуванням активної вкладкою, як показано на Рис. 1.

Рис. 1. Простий елемент керування вкладками показує вкладку dogs, за замовчуванням, активною.

Коли буде зроблено клацання на іншій посиланням (Рис. 2), потім буде використовуватися JavaScript для динамічного переміщення class = "selected" в цю посилання, і в цьому випадку стильове оформлення буде застосовуватися для висновку до цієї вкладці, а та, яка виводилася раніше, буде прихована.

Рис. 2. Тепер було зроблено клацання на іншому посиланні, і відповідна йому вкладка стає активною.

Ви зустрінете реальні робочі приклади такого роду управління в деяких розділах про JavaScript, які слідують далі.

Вкладки стали також широко використовувати, щоб дозволити користувачам вибирати різні види пошуку. У цьому випадку концепція починає руйнуватися, якщо ви спробуєте використовувати стиль коду з попереднього прикладу:

<div class="tabcontrol">

<div class="hd">

<ul>

<li><a href="#dogs" class="selected">Dogs</a></li>

<li><a href="#cats">Cats</a></li>

<li><a href="#fish">Fish</a></li>

</ul>

</div>

<div class="bd">

<form id="dogs" class="selected" action="search.html" method="GET"><div><label for="dogsearch">

<input type="text" name="dogsearch" id="dogsearch">

<input type="submit" value="Search for Dogs"></div></form>

<form id="cats" action="search.html" method="GET"><div><label for="catsearch">

<input type="text" name="catsearch" id="catsearch">

<input type="submit" value="Search for cats"></div></form>

<form id="fish" action="search.html" method="GET"><div><label for="fishsearch">

<input type="text" name="fishsearch" id="fishsearch">

<input type="submit" value="Search for fish"></div></form>

</div>

</div>

Застосування тієї ж структури коду більше не має сенсу – в цьому випадку ви отримаєте ті ж елементи форми, повторювані знову і знову, щоб відповідати концепції заміни контенту, що є марною тратою коду розмітки. Замість візуального мислення важливо подумати про взаємодію. У цьому прикладі замість вибору нової інформації для перегляду вкладок необхідно змінити взаємодія користувача з формою пошуку. Насправді вкладка повинна тільки вибирати, який тип тваринного шукає користувач. Якщо застосувати все це на практиці, то можна створити значно кращу взаємодію для всіх користувачів сайту, з більш чіткою, легко підтримуваної розміткою:

<form action="search.html" method="GET">

<fieldset>

<legend>Search within:</legend>

<ul>

<li><label for="dogs">Dogs</label><input id="dogs" type="radio" name="animal" value="dog" checked></li>

<li><label for="cats">Cats</label><input id="cats" type="radio" name="animal" value="cat"></li>

<li><label for="fish">Fish</label><input id="fish" type="radio" name="animal" value="fish"></li>

</ul>

</fieldset>

<input type="text" id="searchfield" name="search">

<input type="submit" value="Search">

</form>

Створюючи спочатку взаємодія, розмітка буде більш чіткою, і всі користувачі сайту отримають найкращий можливий досвід роботи. Коли ми почали з розширення візуальної метафори, ми швидко зруйнували взаємодія і створили деяку жахливу розмітку на основі припущень попереднього прикладу. Якби ми використовували AJAX для вставки контенту замість розміщення його повністю на сторінці, то було б ще гірше. Користувачі без JavaScript повинні будуть завантажити повністю нову сторінку, щоб отримати форму пошуку для cats або fish. Продумавши спочатку базове взаємодія (а не візуальні питання), можна спростити проблему. Тепер можна і раніше підтримувати метафору вкладки (хоча і з невеликим стильовим оформленням і сценарієм), використовуючи при цьому одну форму для будь-якого пошуку. Це є основою розуміння, як реалізувати доступне взаємодію. Одним з великих переваг HTML є те, що основна робота з визначення, як зробити взаємодію в HTML доступним, вже була зроблена. Поки що для руйнування метафори не використовуються інші технології поверх HTML, можна без великих зусиль змусити працювати більшість речей для більшості людей.

Стандарти доступності

У цьому розділі ми розглянемо деякі наявні стандарти і рекомендації, які націлені на визначення доступності Web і допомога в розробці Web у створенні доступних сайтів. Більшість цих систем включають деяку різновид системи контрольного списку, щоб розробники могли перевірити, як їх сайти відповідають різними критеріями доступності.

Рекомендації по доступності контенту Web версія 1.0

Консорціум W3C є одним з основних органів стандартизації в Інтернет. Його підрозділ Web Accessibility Initiative (WAI) опублікувало першу версію своїх рекомендацій щодо створення Web-сайтів доступними в травні 1999 р. Рекомендації по доступності контенту Web (WCAG, Web Content Accessibility Guidlines) є найбільш широко використовуваним стандартом для доступності в Web. Використання WCAG 1.0 було запропоновано або дозволяється низкою урядових органів, включаючи EU і уряд Італії.

WCAG 1.0 є набором з 14 Рекомендацій, які намагаються охопити цілі, які необхідно реалізувати для отримання доступної сторінки. У кожному документі рекомендацій міститься ряд контрольних точок, які складають реальний зміст документа. У той час як рекомендації пояснюють концепції, які автори мають на увазі, контрольні точки є тим, що використовується для перевірки відповідності стандартам. Кожна з контрольних точок має пріоритет від 1 до 3, що вказати на їх важливість. Щоб відповідати WCAG 1.0, необхідно задовольнити всім контрольним точкам з пріоритетом 1. Дотримання всіх контрольних точок з пріоритетом 1 надає рейтинг відповідності "А". Якщо ви задовольняєте також контрольним точкам з пріоритетом 2, то ви будете відповідати рейтингом "АА". Якщо ви задовольняєте всім контрольним точкам з пріоритетами 1, 2 і 3, то ви будете відповідати рейтингу "AAA", який є найвищим.

У дійсності WCAG 1.0 трохи застарів. Безліч компаній почали з відповідності рівню "А" або "АА", а потім намагалися реалізувати інші рекомендації, такі як See it Right з RNIB. WCAG 1.0 є гарною початковою точкою, але потрібно рухатися вперед до нових стандартів, особливо, якщо ви використовуєте у великому обсязі JavaScript, або інші технології, які розвинулися після 1999 р., коли були випущені Рекомендації WCAG 1.0.

Інший важливий момент щодо стандарту WCAG 1.0 полягає в тому, що він створювався як частина пакету з 3 документів. Інший документ, озаглавлений "Агенти користувача", який описує браузери (такі як "Opera") і всі додаткові технології, які можуть знадобитися людям для використання Web (такі як зчитувачі екрану). Третій документ, який охоплює засоби розробки, такі як "Dreamweaver" або системи управління контентом – його завдання було змусити ці інструменти робити велику частину роботи для створення доступних сторінок. На жаль, цей намір не було реалізовано і єдиним стандартом з трьох, який був загальновизнаний, став WCAG 1.0. Це означає, що часто очікування WCAG 1.0 щодо агентів користувачів не задовольнялися, і дуже невелика частина роботи по створенню доступних Web-сайтів була перенесена на засоби розробки. Це не означає, що немає сенсу використовувати WCAG 1.0; це означає просто, що він розглядає тільки частину питань доступності і не є повним рішенням.