Проектування сайтів для людей з обмеженими можливостями

1. Увага меншості
2. важливі деталі
3. складнощі
4. взаємодіє дизайн
5. Гнучка верстка = flexible grid
6. Кожній тварі по парі - медіа-типи і запити
7. Веселі, гнучкі, адаптивні картинки
8. Змістовний контекст

Виживає не найсильніший і не найрозумніший, а той, хто краще за всіх відгукується на зміни, що відбуваються Леон Меггінсон, перефразовуючи Чарльза Дарвіна

Універсальна доступність це властивість інформаційної системи враховувати різний спектр аудиторії і пристроїв при взаємодії. Зокрема це може бути оптимізація для мобільної версії сайту, для друку або Siri , Але не варто обмежується тільки цим.

Увага меншості

Доступність як правило відрізняють від простого зручності (useability) у використанні, саме в тому що система починає враховувати людей з порушеннями:

1. Зору (сліпота, короткозорість, дальтонізм) - вирішується синтетичним вимовою, екраном Брейлі, сильним збільшенням екрану
2. слуху
3. Опорно-рухової системи (вивих, параліч, Квадріплегія, тремор) - вирішується допоміжними технологіями введення , Великими областями для кліка.
4. Сприйняття (дислексія, перевантаження пам'ять і уваги ) - необхідна логічна і зрозуміла структура сайту

З огляду на що таких людей 7-10% і саме їм важливіше доступність електронних послуг (державних, онлайн-магазинів), то продовжуючи минулої тему про цілісність суспільства , Особливо важливо що багато держав зобов'язали свої ІнфоРесурс бути доступними (accessible). Поважають себе, аналогічно займаються цими питаннями. Парадоксально, але для доступного сайту досить зробити все якісно. Це безпосередньо позначиться на зручності дизайну, SEO та швидкості. Основи також лежать в машинної доступності даних, семантичної верстки і правильному UI.

важливі деталі

З стандартів і рекомендацій WAI, WCAG , ARIA по суті можна виділити пункти:

1. Видимість (Perceavable).
   Картинки, відео та інші об'єкти повинні мати альтернативний текст (або субтитри) - alt, title, longdesc параметри.
   Текст повинен бути читабельним (соответсвенно треба піклується про колір, розмір, шрифті і інших характеристиках).
   
2. Керованість (Operable).
   По всьому документу можна пройтися однією лише клавіатурою (використовуючи Tab + tabindex параметр), фокусна стан посилань видно за допомогою: focus (все забути outline: 0), блокам варто мати role параметр
   Немає ніяких обмежень по часу, блокувань - не використовуйте що випадають меню.
   Посилання мають сенс (ніяких "читати далі" і "click here").
   Заголовки семантичні h1..h6, а не strong або span.
   Використовуються пов'язані label і input.
   
3. Зрозумілість (Understandable).
   Вказується мова елементів, скорочення, наголоси в двозначних словах. Підтримується єдина навігація і стиль в повідомленнях.
   
4. Здоров'я (Robust) - HTML Дійсний, теги не постарілого (i, b, font та ін.)

складнощі

Є проблеми з сучасними практиками ..

• CAPTCHA це та перешкода безпеки яка природно суперечить доступності. Так, зі спамом треба боротися, але для цього треба використовувати Байесови алгоритми. На крайній випадок - re: captcha з можливістю аудіо-перевірки. І звичайно капча ховається для зареєстрованих користувачів.
  
• AJAX вже давно не новинка, але завантажуються блоки треба відзначати з промощью параметрів aria-live = "off, polite, assertive"
• Drag and drop не повинен бути єдино можливим способом взаємодії
• PDF формат як правило закритий для читання, має сенс публікувати альтернативний текст

• JAWS
• NVDA
• VoiceOver (Mac, IOS)
• Window + Eyes
• Zoomtext
• Fangs (Firefox plugin)
• WebbIE

Аналогічно всяким онлайн-валідатора HTML, є і автоматичні тести на хороші практики. Втім завжди треба проходити вручну.

взаємодіє дизайн

Progressive Enchantment, Graceful Degradation, Responsive Design - всі ці три словосполучення (і останнім особливо), пропагують універсальність структури документа. Для цього використовуються різні трюки frontend- і backend-розробки. Зокрема, оскільки у нас більше немає фіксованого розміру екрана (скажімо 1024 * 768) і він сильно розмитий, то за замовчуванням всі стилі повинні бути для мобільних пристроїв. І лише в разі великих екранів, елементи групуються в більш складні горизонтальні структури. Почнемо зі шрифтів ..

Гнучка верстка = flexible grid

Пікселі застаріли, тепер в моді em. Конвертація віри відбувається дуже просто .. беремо стандартний розмір шрифту .. скажімо 16px і ділимо на нього розмір вашого елемента .. скажімо 28px у заголовка. Отримуємо 1.75em - тепер він буде масштабується. Те ж саме з шириною блоків - просто вказуємо замість пікселів відсотки

aside {
font-size: 1.75em; / * 28/16 * /
width: 31.25%; / * 300/960 * /
}

Кожній тварі по парі - медіа-типи і запити

CSS дозволяє тепер групувати всі правила в залежності від властивостей екрану і комбінувати їх логічно за допомогою ключових слів and, or, not, only

@media screen and (min-width: 500px)
@media print and (max-device-height: 600px;)
@media handheld and (max-aspect-ratio: 5) and (orientation: landscape)

Крім того є поняття viewport, що задає початкове положення і здатності зуму.

<Meta name = "viewport" content = "width = device-width; initial-scale = 1; maximum-scale = 1; user-scalable = no">

Зрозуміло що цього не достатньо. За допомогою таких CSS - правил можна додати поведінку, але не можна

Веселі, гнучкі, адаптивні картинки

По-перше, зрозуміло що картинки для мобільників до якоїсь межі, повинні бути на всю ширину екрану. Або повністю, або частково з центруванням і збільшенням:

max-width: 100%
background-position: 50%;

Тепер проблема в тому що ми картинки для мобільників надто великі. CSS не може обмежити завантаження важких фонів. Тому можна піти двома шляхами - встановити в куки розмір екрану і на сервері пропускати всі картинки через зменшений розмір.

document.cookie = 'resolution =' + Math.max (screen.width, screen.height) + '; path = / ';

Або використовувати дві версії якості картинок і використовувати data- атрибут для зберігаючи шлях до більш якісної версії. Зрозуміло що javascript тоді повинен все картинки замінити починаючи з якоюсь ступені дозволу екрану (або швидкості завантаження?).

Більшість користувачів при скануванні очима сторінки цікавляться двома об'єктами - заголовками (де я?) І посиланнями (куди піти далі?).

<Form role = "search">
<Input name = "name" aria-required = "true" />
<Button aria-pressed = "true" />
</ Form>

Змістовний контекст

Уявіть що ви їдете на конференцію. Якщо ви заходите на сайт з мобільника (і ви поспішаєте), то вам буде важливо відразу ж зверху побачити адресу, контактні телефони, календар з часом виступів і їх авторами, інформацію про паркування. А якщо ви вже приїхали, розкрили лептоп і почали вивчати детальніше, то вам цікаво стане і фото / відео учасників, архівні документи, форми по зворотного зв'язку. Все це стосується будь-якого іншого сайту. При цьому повинна бути можливість вийти за межі цієї оптимізації.

По-моєму тут стоїть велика складність. Так само як і з картинками, по-правді, недостатньо просто ховати великі блоки для мобільників. Ви все-одно вантажите js-бібліотеки на сотні кілобайт і монстоідальний DOM. Тому компанії який стикаються з цією проблемою не можуть зарефакторіть всю свою систему з нуля так, що-б DOM довантажувати через ajax в залежності від клієнта, що-б javascript теж довантажувати в міру необхідності (див. require.js ), Що-б відео і флеш довантажувати тільки коли це можливо (див. modernizr ). Природно вони просто роблять урізану мобільну версію, яка по-уродски виглядає на iPad і інших планшетника.

Див. також