Терминът du jour е уеб достъпност - по мое мнение, един от най-често неразбираните и слабо прилагани аспекти на уеб дизайна. The често срещано погрешно схващане е, че достъпността е предназначена само за хора с увреждания. Всъщност, всички се възползват от достъпно съдържание , и вашата аудитория ще се увеличи, като получи достъп до достъпно съдържание на различни платформи или по различни начини, защото те могат да използват съдържанието ви с по-малко ограничения.
За съжаление, много уеб разработчици не правят съдържанието им достъпно и не спазват указанията за достъпност в мрежата; по този начин много хора изпитват ненужни трудности, използвайки своите дизайни и наслаждавайки се на съдържание. В екстремни случаи определени групи потребители изобщо не могат ефективно да използват такъв уебсайт.
Изграждането на достъпно съдържание трябва да бъде второ естество за всеки разработчик, дизайнер или създател на съдържание, по същия начин, по който разглеждането на рампи, стълбища и асансьори е за архитекта, проектиращ нова сграда.
Нека разгледаме по-отблизо какво е зад кулисите и защо толкова много разработчици изглежда пренебрегват стандартите за достъпност в мрежата без основателна причина.
Достъпното съдържание е съдържание, което всеки може да използва . Не знаем всички аспекти на начина, по който потребителите имат достъп до нашето съдържание, така че трябва да проектираме с оглед на достъпността преди време.
Както подчертах по-рано, това не засяга хората с увреждания, които представляват около около 15% от населението на света . В реалния живот потребителите често в крайна сметка не консумират съдържание и взаимодействат с устройства по абсолютно същия начин, както е предвидено по време на разработката. Достъпно съдържание също се изисква по правни причини в много юрисдикции. Прочети ' Правни и политически фактори при разработването на бизнес казус за уеб достъпност за вашата организация ”За допълнителна информация относно спазването на достъпността.
Обмислете следните сценарии, докато мислите за достъпно съдържание за потребители, което може да бъде:
Не може да чуе добре. 360 милиона души по света имат слухови увреждания. Аудиосъдържанието трябва да има транскрипции, а видеото - надписи.
Не може да се види добре. 285 милиона души се изчисляват на хора със зрителни увреждания в световен мащаб: 39 милиона са слепи, а 246 са със слабо зрение Потребители с увредено зрение използват четци на екрана (които четат съдържанието с помощта на синтезирана реч), опресняващи се брайлови дисплеи (съдържанието на екрана се появява на брайловия дисплей и потребителят може да навигира и да взаимодейства с устройството си с помощта на клавишите на дисплея) или високо -контрастен режим.
Засегнати от дислексия. Хората с дислексия срещат трудности при четене и разбиране на съдържание, особено, например, оправдан текст или всички главни букви.
Страдащи от физически ограничения. Не всички хора могат да използват всички устройства. Например навигацията през съдържанието трябва да е достъпна не само за потребителите на мишката, но и за потребители, които не могат да използват мишка.
Използване на мобилни устройства. Адаптирайте съдържанието си за малки екрани. Позволете на потребителя да увеличава или увеличава размера на шрифта.
Хората използват много различни начини за навигация и консумация на съдържание. Има потребители, които трябва да бъдат подкрепени от допълнителни софтуерни инструменти, които им помагат да получат по-лесен достъп до съдържанието. Тези инструменти, известни като помощни технологии, варират от четци на екрани до сензорни екрани и указатели на главата.
Вашето приложение и помощните технологии обаче трябва да говорят помежду си. Не всичко, което е написано в HTML, е напълно разбираемо за помощните технологии. За да се подпомогне „превеждането“ на съдържание от „технически език“ на по-разбираем за човека език, допълнително стандарти за API за достъпност са създадени.
Тази основна диаграма за достъпност в мрежата трябва да ви даде по-добра представа за това как работят помощните технологии.
За да илюстрираме как работи, нека разгледаме прост пример за код:
https://www.w3.org/TR/wai-aria/ ), за да замени първоначалната роля. Променяме значението на връзка към бутон, като добавяме атрибут role='button'
. По този начин екранните четци ще го прочетат като бутон, а не като връзка. Което е по-подходящо. Накратко, атрибут ARIA:
-
Дава или подобрява семантиката на несемантични или други семантични елементи,
-
Гарантира, че динамичното (живо) съдържание е все още достъпно.
-
Предоставя ролята за описване на типа дефинирана джаджа (меню, елемент на дърво, плъзгач, измервателен уред и т.н.).
-
Предоставя ролята за описване на структурата на уеб страницата (заглавия, региони и таблици).
-
Осигурява състоянието на приспособленията (проверено, има изскачащи и т.н.).
-
Предоставя свойства за плъзгане и пускане, които описват източници на плъзгане и пускане на цели.
Какво е достъпност в уеб дизайна?
Винаги, когато проектирате съдържание, помислете за две неща: как съдържанието се възприема и как е оперативно . Нека разгледаме някои примери, за да илюстрираме достъпността в уеб дизайна.
Да предположим, че ще проектирате персонализиран падащ елемент за избор. Ето нещата, които трябва да имате предвид при проектирането на елемента:
-
Маркирайте различни състояния: разрешено, деактивирано, само за четене.
-
Маркирайте елемента, когато получи състоянието на фокус / задръжте.
-
Маркирайте всеки елемент от опцията, когато получи състояние на фокус / задържане.
-
Уверете се, че съдържанието все още може да се чете, когато само текстът е увеличен до ниво от 200%.
-
Уверете се, че има достатъчно контраст между текста и неговия фон. Помага на хората с умерено слабо зрение или на устройства при екстремни условия на осветление, например изложени на пряка слънчева светлина или на дисплей с ниска яркост, да четат съдържанието.
Друг пример може да бъде избор на цвят за описание на състояние. Ето нещата, които трябва да имате предвид при проектирането на раздел, където потребителят ще може да вземе цвят:
-
Има хора, които изпитват трудности при различаването на определени цветове. Така че зеленото не означава зелено за всички ваши посетители. За да го поправите, добавете описание за всеки цвят, който описва целта.
-
Маркирайте всеки елемент, когато получи състоянието на фокусиране / задържане.
-
Уверете се, че има достатъчно пространство между елементите, така че всеки елемент да може лесно да се активира, например на устройства с по-малък прозорец за гледане.
3. Тестване на достъпността: откъде да започна?
Няма еднопосочен за да проверите и да сте сигурни, че уеб съдържанието е напълно достъпно. Трябва да се използват множество техники, за да се проверят и отстранят проблемите с достъпността. Може да започнете от определяне на въпроси , решения , и приоритети .
Определяне на проблеми
Докато работите по проблеми с достъпността, винаги се опитвайте да създавате един билет за проблем с ясно заглавие. Това трябва да опрости разбирането на проблема и да помогне за определянето на приоритет.
Лош пример: Потребителят не може да използва клавиатурата на страницата.
Добър пример: Не може да се използва навигация с клавиатура в главното меню.
Лошият пример води до дело, което ще бъде доста трудно да се приключи за кратко време. Дискусиите по множество теми може да започнат и в раздела за коментари, тъй като заглавието на билета е твърде общо.
Добрият пример насочва точно към проблема и се фокусира само върху едно нещо: навигация с клавиатура в главното меню.
Приоритизирайте проблемите с уеб достъпността
Приоритетите са важни, защото те определят кои проблеми трябва да бъдат решени първо. Например WCAG се дели на три нива на съответствие : A, AA, AAA, което означава, че трябва да започнете от минимално ниво A, но това не означава автоматично, че нивата на AA и AAA са просто „приятни за притежание“. Всички нива са важни и е важно да не се дава приоритет, като се приеме, че само ниво А е достатъчно.
Въпреки това, нивата на WCAG (или всякакви други насоки) може да са доста трудни за разбиране понякога и за да го опростите малко, можете също да вземете предвид следните приоритетни дефиниции:
-
Критично - Проблеми, които пречат на потребителите да използват приложение. Няма налични заобикалящи решения.
-
Майор - Проблеми, които затрудняват и / или дезориентират използването на приложение, но не блокират възможността на потребителя да завърши операцията.
-
Незначителен - Проблеми, които са досадни, но не пречат на използването, или подобрения, които могат да бъдат направени в приложението.
-
Информация - Не се придържа към най-добрите практики. Общи препоръки за подобрения.
Решения
Нито една от насоките - под което имам предвид WCAG , Раздел 508 или ИМА —Ще ви даде пряко решение от гледна точка на техническия код за начина, по който трябва да се реши определен проблем. Те определят само очакваното поведение. Въпреки това, WCAG допълнително е определил тестови процедури, които трябва да помогнат да се разбере как да се възпроизведе проблема и има автоматизирана група на общността за наблюдение на WCAG, общност W3C с фокус върху разработването на надеждни правила за тестване на достъпността в мрежата, както автоматизирано, така и полуавтоматизирано.
Пример за WCAG technique G4 („Позволяване на съдържанието да бъде поставено на пауза и рестартирано от мястото, където е било поставено на пауза“):
Процедура за изпитване
На страница с движещо се или скролиращо съдържание,
-
Използвайте механизма, предоставен в уеб страницата или от потребителския агент, за да поставите на пауза движещото се или скролиращо съдържание.
- Проверете дали преместването или превъртането е спряло и не се рестартира от само себе си.
- Използвайте предоставения механизъм за рестартиране на движещото се съдържание.
- Проверете дали движението или превъртането е възобновено от мястото, където е било спряно.
Очаквани резултати
No2 и No4 са верни.
Както виждаме, няма технически решения, а дефинирано очаквано поведение. Как уеб разработчици изпълнете, зависи от тях.
Указания за уеб достъпност и стандарти W3C
Следването на основните уеб стандарти трябва да бъде вашата отправна точка:
-
Най-често срещаният е Указания за достъпност на уеб съдържание известен като WCAG. WCAG 2.0 е „Стабилен технически стандарт, който може да се използва. Той има 12 насоки, които са организирани под 4 принципа: разбираем, работещ, разбираем и здрав . За всяка насока има проверими критерии за успех, които са на три нива: A, AA и AAA . '
-
Техники за WCAG 2.0 е изчерпателно ръководство за автори на уеб съдържание.
-
Потребителски изисквания за достъпност на медиите на W3C - Този документ представя изискванията за достъпност, които потребителите с увреждания имат по отношение на аудио и видео в мрежата.
-
Закон за комуникациите и видеодостъпността на двадесет и първи век - CVAA е разделен на две широки заглавия или раздели. Заглавие I се отнася до комуникационния достъп, за да направят продуктите и услугите, използващи широколентова връзка, напълно достъпни за хора с увреждания. Дял II от Закона за достъпността пробива нова почва, за да улесни хората с увреждания да гледат видеопрограми по телевизията и в Интернет.
-
Раздел 508 - изисквания за достъпност за информационни и комуникационни технологии (ИКТ), които се прилагат за всички федерални агенции, когато разработват, набавят, поддържат или използват електронни и информационни технологии.
-
Достъпност на уебсайтове по дял II от Закон за американците с увреждания (ADA) - Там ще научите как изискванията за недискриминация от дял II от ADA се прилагат към уебсайтовете на държавата и местното правителство.
Тестване на уеб достъпността: Как да разбера дали съдържанието ми е достъпно или не?
Ето основни, основни контролни точки, които трябва да ви помогнат да направите вашето уеб съдържание по-достъпно от първа стъпка:
-
Проверете вашия HTML. Уверете се, че HTML структурата няма грешки, тъй като помощните технологии могат да имат проблеми при интерпретирането на съдържанието на страницата.
-
Тествайте само с клавиатура. Уверете се, че всички действащи елементи са достъпни само с помощта на клавиатура. Освен това трябва да можете да извършвате всички действия и с помощта на клавиатура, например изпращане на формуляр.
-
Тествайте с инструменти за проверка на достъпността и валидатори. Използвайте инструменти, които сканират и проверяват потенциални грешки в достъпността.
-
Динамично съдържание. Уведомявайте потребителите на екранен четец за динамични промени, напр. когато резултатите от търсенето се променят.
-
Не разчитайте на цветове, за да опишете значението. Използвайте цвят заедно с описанието, например предупреждение [жълто поле].
-
Не премахвайте контура на фокус. Това е често премахвана функция, използваща CSS свойството outline: 0;
Не правете това, тъй като потребителите на клавиатурата ще загубят ориентацията на страницата. Може да помислите за премахване на контура на фокуса за потребители, които не са от клавиатурата, но винаги осигуряват фокус за потребителите на клавиатурата.
-
Съобщения за грешки. Винаги казвайте на потребителя как да коригира грешка. Не заявявайте само, че данните са невалидни.
-
Подреждане на раздели. Уверете се, че навигацията, базирана на раздели, следва конвенциите, установени в графичния потребителски интерфейс. Най-малкото трябва да следва посоката на четене на езика по подразбиране на приложението. Например на английски език редът на четене е отгоре надолу, отляво надясно; на арабски е отгоре надолу, отдясно наляво.
-
Мащабиране. Уверете се, че съдържанието на страницата все още е четливо, докато мащабирате текста до 200%.
-
Изключете изображенията. Все още ли можете да използвате страницата по удобен начин? Има ли алтернативни текстове за всички изображения?
-
Екранен четец. Тествайте, за да видите дали можете да четете и да навигирате през съдържанието, използвайки поне един четец на екрана, например VoiceOver, Windows Narrator или NVDA.
-
Режим с висок контраст. Проверете дали съдържанието все още може да се чете, докато превключвате в режим с висок контраст.
-
Размер на шрифта. Уверете се, че размерът на шрифта на страницата е не по-малък от 10 пиксела.
4. Често срещани грешки в уеб достъпността
Най-често срещаната грешка е не успя да идентифицира изискванията за достъпност преди разработването . За съжаление, колкото по-късно достъпността ще бъде част от развитието, толкова по-трудно ще бъде прилагането на решения.
Ето списък с някои от най-често допусканите от разработчиците грешки при внедряването на достъпност:
-
Няма възможност за навигация чрез съдържанието, използвайки само клавиатура .
-
Неправилно използване на свойството на контура на CSS. В повечето случаи outline: 0;
се използва, което означава, че контурът около всеки действащ елемент вече не се вижда. Не използвайте outline: 0;
или outline: 0 !important;
. Потребителят ще загуби възможността да вижда текущо фокусирания елемент, докато се придвижва през съдържанието, освен ако няма друга алтернатива на това, например, използвайки border
CSS свойство.
-
Загуба на фокус от текущия елемент, например поради DOM манипулации или използване на blur()
метод. Това често се случва за приложения на една страница.
-
Няма известия за потребителите на екранен четец че нещо се е променило, напр. съдържанието е изтеглено с помощта на XMLHttpRequest API и са представени нови промени в потребителския интерфейс, но потребителят не е бил уведомен. Това често се случва с приложения на една страница.
-
Недостъпен инструмент за избор на дата. В много случаи се използват недостъпни инструменти за избор на дата. Потребителите не могат да навигират през опциите на календара с помощта на клавиатура.
-
Използване на разширения това твърдение за автоматично коригира проблеми с достъпността . Използвайте ги внимателно и проверете резултатите. Неправилното им използване може да създаде повече проблеми, отколкото решения.
-
Добавяне към елемента tabindex
атрибут с номер на индекс повече от 0. Целта на използването на tabindex
с индекс над 0 е най-вече да „коригира“ навигационния път. Помислете обаче за по-скоро промяна на структурата на HTML, за да получите естествения път на навигация. Манипулиране с помощта на tabindex
може да доведе до проблеми с поддръжката и непредсказуема навигационна пътека.
-
Грешна йерархия на заглавията. За съжаление все още се вижда често, но йерархията на заглавките не е правилно изградена, например
,
и
. Потребителите на екранния четец използват заглавки, за да се придвижват из секциите и неправилната структура е объркваща, тъй като е трудно да се разбере контекста.
-
Липсва поддръжка с висок контраст. Има хора, които използват своя софтуер в режим с висок контраст. Уверете се, че съдържанието ви все още се възприема.
-
Използване на недостъпно решение CAPTCHA. За съжаление, всички CAPTCHA, познати ми, са или недостъпни, или много трудни за използване.
-
Твърде много и / или неподлежащи на пауза анимации. Автоматичното възпроизвеждане на видеоклипове, реклами или въртележки за изображения са много разсейващи.
-
Големи парчета текст. Текст, който е кондензиран в много голям, единичен блок, без интервали, запетаи или точки. Много трудно за четене. Разделянето на по-малки парчета, повече абзаци и подзаглавия помага за по-добрата организация на текстовото съдържание.
-
Проблеми с мащабиране. Уверете се, че съдържанието все още е четливо и навигационно, когато е увеличено до 200%.
-
Разчитайки на цветовете. Много често състоянието на елемент се маркира само с цвят, напр. Състоянието на предупреждение се отбелязва само с жълт куршум; този цвят не се възприема по същия начин за далтонистите.
-
Малки цели за кликване / докосване. Областите, върху които може да се кликва / могат да се докоснат, често са твърде малки. Увеличаването му позволява на потребителите да ги активират по-лесно.
Но как да подобря уеб достъпността?
Определянето на проблемите е едно. Поправянето му е съвсем друго и много често не е толкова лесно, колкото изглежда. Това е така, защото внедряванията на API за достъпност не са последователни и понякога трябва да намерим заобиколни решения или дори да приемем факта, че нещо изобщо няма да работи, когато се опитваме да отстраним проблема.
По отношение на инструментите няма нито един инструмент, който може да провери всички възможни комбинации, но като добро начало тези инструменти трябва да помогнат:
-
W3C Услуга за проверка на маркирането - Само за да сме сигурни, че HTML съдържанието няма грешки. Ако HTML структурата има грешки, тогава изходът е непредсказуем и не може да бъде обработен правилно, особено от различни помощни технологии .
-
https://www.w3.org/WAI/ER/tools/ - Списък с програми или онлайн услуги, които ви помагат да определите дали уеб съдържанието отговаря на указанията за достъпност.
-
И моят инструмент, ASLint https://www.aslint.org/ , ви помага да намерите проблеми с достъпността.
Винаги имайте предвид, че няма инструмент за достъпност може да замени ръчното тестване , тъй като не всички сценарии могат да бъдат напълно или изобщо автоматизирани, например, проверка на съотношението на контраста на яркост върху елементи с position: fixed;
Фокусирайте се върху проблеми, които блокират използването на вашето приложение, напр. Потребителят не може да навигира в менюто с помощта на клавиатура.
Защо е важно да направите съдържанието достъпно
Всеки иска да разпространи съдържанието си възможно най-широко. Достъпността помага в тази област, на много нива, от достигане до по-голяма аудитория до подобряване на потребителското изживяване за всички потребители. Освен това достъпността не е само за това, което традиционно бихте могли да смятате за хора с увреждания. Независимо дали става въпрос за лице, което застарява и преминава през съпътстващите физически промени, някой, който джогира в слънчев ден, който се нуждае от автоматично регулиране на контраста на телефона си, или родител с ръце, пълни с пазарски чанти, които искат да изпратят текстово съобщение с глас, достъпно технологията е технология, която всички потребители могат да използват от време на време.
Като допълнителен бонус положителният ефект е, че достъпното съдържание, което напълно отговаря на стандартите на WCAG 2.0, е по-лесно да се обхожда и разбира от търсачките и това може да има значителен ефект върху класирането на сайта. По този начин достъпният дизайн може да привлече допълнителен трафик към уебсайта.
И накрая, ето няколко статистически данни, които трябва да вземете предвид:
-
Повече от един милиард души по света преживяват някакъв вид увреждания.
-
Стареене на населението . Между 2015 и 2030 г. броят на възрастните хора - на възраст над 60 години - в света се очаква да нарасне с 56%, от 901 милиона на повече от 1,4 милиарда.
-
Универсалният дизайн е ключов. Универсалният дизайн се отнася до широк спектър от идеи и практики за производство на услуги, продукти и среди, които са присъщи и използваеми от хора с всякакви способности.
-
Видове увреждания: Има пет широки категории увреждания, включително зрителни, мобилни, речеви, познавателни и слухови.
Всички ние се нуждаем от висококачествени услуги. Нека ги доставим и ние .
Разбиране на основите
Какво е достъпност в уеб дизайна?
Достъпността в мрежата е практиката за премахване на различни пречки пред достъпа и взаимодействието на потребителите с онлайн съдържание. Целта му е да осигури уеб достъп за хора с увреждания, както и за всички други потребители, които може да се наложи да получат достъп до съдържание неконвенционално.
Какво представлява спазването на WCAG?
Казано по-просто, ако отговаряте на WCAG, означава, че правилно прилагате Указанията за достъпност на уеб съдържание (WCAG). Вижте краткия справочник за WCAG 2.0 за допълнителна информация за това как да отговаряте на различни критерии.
Какво представлява стандартът WCAG 2.0?
WCAG 2.0 означава Насоки за достъпност на уеб съдържание. Това е технически стандарт, състоящ се от 12 насоки, следващи четири основни принципа. Всяка насока е тествана и оценена за съответствие.