Я консультант по специальным возможностям. Решаю проблемы.
Одна из самых распространенных проблем с веб-сайтами, которые меня вызывают, - это сломанные, искаженные, неполные и недоступные формы. Есть несколько вещей, на которых прокуроры или адвокаты истцов с ограниченными возможностями фокусируются как на форме, которую пользователи с ограниченными возможностями не могут использовать по какой-либо причине.
Есть МНОГО способов «сломать» форму… но главные проблемы, с которыми я постоянно сталкиваюсь, это:
- Нет тегов
<label>. <label>элементы формы неправильно упакованы и / или отсутствуют отношения «for / id».- Использование
placeholder=””для выполнения работы<label> - Нет
<fieldset>вокруг связанных наборов переключателей / флажков или вокруг групп изменяемых пользователем элементов формы. - JavaScript - единственный метод, с помощью которого форма может работать.
Этикетки не являются обязательными и ДОЛЖНЫ использоваться по назначению!
Я часто удивляюсь, как часто это единственное, что не так с формой. Если у вас нет правильного LABEL вокруг INPUT / SELECT / TEXTAREA - или вы создаете связь for=”inputId” - нет ничего, что могло бы сказать программам чтения с экрана, устройствам чтения Брайля или другим «неэкранным медиа-UA», для чего вообще нужны ваши элементы формы! У вас должен быть ВСЕГДА ярлык для КАЖДОГО элемента формы, даже если вы не хотите, чтобы он отображался в макете экрана.
Помните, ваш HTML должен быть БОЛЬШЕ, чем просто то, на что смотрит человек с прекрасным зрением, сидящий за экраном. Вот почему, если в вашей таблице стилей <link> или <style> отсутствует media=”screen” таблица стилей экрана, это некомпетентный мусор. Вот почему использование style=”” разметки в разметке в 90% + случаев является некомпетентным мусором. Вот почему, если вы используете теги, основанные на их внешнем виде по умолчанию, а не на их грамматическом / структурном значении, это некомпетентный мусор.
В любом случае код обычного ввода текста должен выглядеть примерно так:
<label> Username:<br> <input type="text" name="username" required><br> </label>
Или вот так:
<label for="login_username">Username:</label><br> <input type="text" name="username" id="login_username" required><br>
Если вы не следуете этому общему шаблону, вы делаете все неправильно! Почему так много людей, кажется, не понимают, как использовать эти теги, ускользает от меня… Хотя такой мусор, как W3Schools, может иметь к этому какое-то отношение. Опытные разработчики не зря называют это W3Fools!
Это шокирует, как много людей просто выгружают текст в форму без ярлыка вокруг него или неправильно используют и / или злоупотребляют тегами, такими как таблицы, списки, DIV и SPAN, из-за незнания, когда правильная семантика - как это было выше - дала бы больше чем достаточно крючков для любого желаемого стиля без ущерба для доступности.
И нет, заполнитель - это не этикетка!
Предполагается, что заполнитель должен быть примером того, что будет вводиться, а не описанием того, что вводить. Серьезно, ребята, посмотрите!
Он вызывает ложную простоту, он не работает для большинства программ чтения с экрана или брайлевских программ, и в целом это вычурный фарс и невежественная ерунда, которую НЕ следует делать на веб-сайтах. И нет, повторение поведения с помощью JavaScript - тоже не лучший вариант!
Это мусор, который художники, находящиеся в ИЛУЗИИ, что они «веб-дизайнеры», часто выбрасывают из строя из-за своего полного игнорирования HTML, CSS или норм доступности. Помните, реальный дизайн - это инженерия, включающая искусство, а не искусство само по себе. Если вы не учитываете стандарты, рекомендации, удобство использования или доступность ... и все, что вы делаете, это перемещаете пиксели в программе рисования, такой как Photoshop или какой-то тупой WYSIWYG ... ну, вы НЕ дизайнер!
ПОЛЕВЫЕ НАБОРЫ, используйте их!
Вернуться к HTML 4 Строгое требование к контейнерам уровня блока, поскольку дочерние элементы <form> не были случайными или непреднамеренными. Это было сделано для того, чтобы стимулировать использование <fieldset> в качестве площадки для невизуальной навигации, разделяя формы на разделы. Он также группирует несколько элементов формы в связанные разделы. В то время как HTML 5 ослабил это ограничение, отсутствие набора полей по-прежнему нарушается во многих невизуальных UA.
Это одна из многих причин, по которым я считаю HTML 5 пронизанным недостатками, которые доказывают, что WhatWG не смогла стать преемником HTML 4.
Они не означают «обернуть это двойной рамкой». Отсутствие тега HTML означает его внешний вид по умолчанию. Вам не нравится двойная рамка, отключите ее с помощью CSS!
Если вы возьмете приведенную выше информацию о LABEL и FIELDSET и сложите их вместе, хорошо сформированная форма будет / должна выглядеть следующим образом:
<form action="login.php" id="login" method="post">
<h2>Login</h2>
<fieldset>
<label>
Username:<br>
<input type="text" name="username" required><br>
</label><label>
Password:<br>
<input type="password" name="password" required><br>
</label>
</fieldset>
<div class="submitsAndHiddens">
<a href="forgotLogin.php">Forgot Your Password?</a>
<button>Submit</button>
<input type="hidden" name="securityHash" value="randomHashHere">
</div>
</form>
H2, чтобы пометить его как основной подраздел страницы - легенда не совсем справляется с этим - набор полей для отметки редактируемых / изменяемых пользователем элементов формы и DIV, чтобы содержать неизменяемое пользователем поведение и значения… , что также упрощает стилизацию.
И, как уже упоминалось, <fieldset> также следует использовать для упаковки таких вещей, как радиоприемники.
<fieldset> <legend>What was your first pet?</legend> <input type="radio" name="pet" id="pet_cat" value="cat"> <label for="pet_cat">Cat</label><br> <input type="radio" name="pet" id="pet_dog" value="dog"> <label for="pet_dog">Dog</label><br> <input type="radio" name="pet" id="pet_gerbil" value="gerbil"> <label for="pet_gerbil">Gerbil</label><br> <input type="radio" name="pet" id="pet_other" value="other"> <label for="pet_other">Other</label><br> </fieldset>
Видишь, как это работает? Обратите особое внимание на то, как for=”” указывает на идентификатор <input>, для которого <label> ... Как <legend> описывает то, о чем они все спрашивают. Как <fieldset> их группирует. Как у них у всех одно и то же название, потому что все они связаны с радио.
Замечание: просто удивительно, сколько людей, которые много лет писали HTML, до сих пор не понимают, что такое / id, или это имя используется на стороне сервера, а идентификатор - на стороне клиента.
Если вы опускаете <fieldset>, потому что вам не нравится, как он выглядит, или вы не думаете, что это необходимо, вы потенциально уговариваете большое количество пользователей уйти. Меня не волнует, будет ли это простой поиск по заголовку, где есть только один <input> и <button>, ПОЛУЧИТЕ СВОЮ ВЗРЫВНУЮ ЭТИКЕТКУ И НАБОР ПОЛЕЙ !!!
Разве ‹legend› не «проблемный» стиль?
Если вы удаляете границу / отступы / поля из своего <fieldset>, сначала может показаться, что настраивать внешний вид тега <legend> бесполезно. Никакие два браузера не используют одинаковые значения по умолчанию для размещения тега легенды в границах, поэтому простое обнуление позиционирования не работает в разных браузерах. В течение многих лет мы видели всевозможные уловки, такие как абсолютное позиционирование SPAN внутри него над отступом на родительском FIELDSET и т. Д., И т. Д.
Что ж, пять или шесть лет назад кто-то заметил, что если вы установите его как плавающее, все лишнее форматирование будет удалено. В большинстве случаев, если вы просто установите:
float:left; width:100%;
Вы можете стилизовать его на всю ширину, как вам нравится, как если бы это был заголовок внутри набора полей. Если вы хотите расположить его влево / вправо, просто сначала добавьте box-sizing:border-box;, чтобы случайно не сделать его шире, чем родительский набор полей.
Только JavaScript? / FAIL / При веб-разработке!
Снова и снова это самая большая проблема с точки зрения доступности, и она только усугубляется с такими ментальными карликами, как React, Vue и другими интерфейсными фреймворками JavaScript, которые попадают в смесь.
Приносим извинения, если это грубо или оскорбительно, но ошеломляюще тупые люди с разбитым мусором, которых рвет этим скриптардерством, стало проклятием для пользователей с потребностями в доступности. Если ваша форма не работает с отключенными сценариями на стороне клиента, вы говорите огромному количеству пользователей, чтобы они пошли на хуй! Какой бы горячей, модной, яркой и блестящей ни была ваша невежественная некомпетентная болвана.
Вообще-то, никаких извинений. Я называю это тем, что есть!
Я не говорю, что вы не можете использовать JavaScript в своих формах, но форма или любое важное действие пользователя должны быть закодированы для работы без JavaScript ПЕРВЫЙ! Как я сказал в своей предыдущей статье по этой теме, хороший JavaScript должен улучшать уже работающую страницу, не быть единственным средством, с помощью которого все работает!
Это, наверное, самая простая часть, но как многие люди теперь неправильно создают формы и во всем полагаются на JavaScript? Что ж, это почти всегда основная проблема доступности на сайтах, над которыми я сейчас работаю. Совершенно отстойно говорить клиенту, который сталкивается с угрозой штрафов или урегулирования, что единственный способ исправить определенные разделы - это полностью избавиться от того, как они реализованы, и перекодировать их с нуля «правильным способом».
И многие из этих интерфейсных фреймворков, ориентированных на JavaScript - и сколько людей злоупотребляют ими или злоупотребляют ими - виноваты в этом!
Почему все это так важно?
Меня много кричат за то, что я «беспокоюсь» по этому поводу, но есть две важные причины, по которым вам действительно стоит беспокоиться.
- Не будучи доступным, вы блокируете контакты, не можете развивать свой бизнес, предотвращать возможные продажи и в целом отталкивать пользователей. И не надо мне чушь про "целевую аудиторию". Это Интернет, единственное, что мы можем знать наверняка о том, кто будет посещать веб-сайт, - это то, что мы абсолютно не знаем, кто будет посещать веб-сайт.
- Во многих странах есть законы, такие как ADA США и UK EQA, несоблюдение этих минимумов в определенных отраслях может повлечь за собой судебное разбирательство по уголовным или гражданским делам. Обычно в прошлом это было ограничено банками, государственными учреждениями, коммунальными службами и медицинским обслуживанием. Это закончилось, когда Верховный суд США отказался рассматривать апелляцию Domino и оставил в силе решение суда низшей инстанции! Теперь открыт сезон на ВСЕХ розничных сайтах. Если инвалиды не могут получить доступ к вашей странице для выполнения транзакции или другой услуги, что ж ... вы просто можете оказаться в притоке навоза, не имея средств передвижения.
Я имею в виду серьезно, если громкие имена с глубокими карманами, такие как Domino’s или Beyonce, могут быть загребены за угли за это, какие шансы есть у малого бизнеса? Вот почему, как веб-разработчики, мы должны приложить дополнительные усилия и взять на себя ответственность за свою работу!
Я слышу множество глупых, невежественных и неубедительных оправданий от разработчиков о том, почему они не могут позаботиться о правильном / доступном написании HTML. Каждое последнее из этих утверждений - «Эта структура не предназначена для работы», или «Почему у нас проблемы, это было хорошо в течение многих лет», или «Это просто HTML, это не так важно» - сводятся к не более чем отклонение от ответственности; либо из-за умственных недостатков, таких как предвзятость подтверждения, предвзятость выживания и когнитивный диссонанс; или из-за того, что они были слишком ленивы и слишком плохо осведомлены в этой теме, чтобы выполнять свою работу должным образом.
Вывод
К сожалению, на большинстве сайтов с вакансиями всегда есть пара людей, которые завязывают свои трусики в узел, когда я говорю им, что их код нужно выбросить. Я часто чувствую себя «Волком» в мире, где у каждого клиента есть Винсент Вега в штате. Мне не раз приходилось говорить: «Я здесь, чтобы помочь. Если моя помощь не оценена, удачи, джентльмен! "
Почему так много людей считают этот элементарный элемент HTML таким «сложным» или «бессмысленным», или почему существует этот параноидальный вздор «отправка нормальных форм и загрузка страниц - зло», совершенно вне моего понимания.
Правильно структурированные формы довольно легко кодировать, как только вы усвоите основные правила, обеспечите мгновенную доступность и удобство использования и у вас будет более чем достаточно крючков для применения стиля, которые вам, как правило, даже не нужно добавлять к вещам дополнительные классы, DIV или SPAN. .
Есть несколько оправданий, если они вообще существуют, для того, чтобы не потрудиться с правильным использованием HTML.
Или, по крайней мере, то, что было «правильно» до того, как HTML 5 появился вместе с живым документом BS и начал ссать все вокруг.
Приложение / За кадром
Внимание, выходите вперед.
Я написал эту статью из-за того, как потенциальный клиент отреагировал на мой первый ответ на его просьбу о помощи. Они пришли ко мне, потому что их беспокоили проблемы доступности и угрожали как уголовным, так и гражданским иском. Хотя у них есть ряд проблем, таких как волей-неволей, когда смесь PX и EM нарушается для пользователей с крупным шрифтом, неразборчивый веб-шрифт и проблемы с цветовым контрастом и т. Д.… Их формы - большая часть проблемы.
Но когда я отправил им это:
Что ж, на первый взгляд серверная часть Angular выдает сломанную / неполную форму, которая не работает с отключенным JavaScript. Кажется, это самая большая часть жалоб пользователей, которые вы мне отправляли; хотя указанные пользователи не знали, в чем проблема. Они знали только, что у них это не работает. Все эти клиентские сценарии необходимо удалить, а форму переписать, как обычно, с использованием правильного семантического HTML и без JavaScript. То, что делает сценарий, является либо работой новых атрибутов HTML 5, либо гораздо более простыми сценариями, которые просто улучшают страницу, не жертвуя изящной деградацией.
Они ответили таким тоном и языком, как будто я только что вылил их кукурузные хлопья, одновременно предполагая, что у них история кровосмешения с их матерью в сортире. Они особенно оскорбились, когда я предположил, что Angular был частью проблемы и что его нужно было заставить работать, когда JavaScript отсутствует / неприменим / заблокирован / нерелевантен.
Откровенно говоря, это отношение, которое я часто вижу, сводится к: «Вот почему мы не можем вам помочь!». Я сейчас уже ищу дверь и считаю ее пустой тратой времени.
Затем люди задаются вопросом, почему я так отношусь к этому, когда разговариваю с не-клиентами на форумах.
По мере того, как эти мусорные фреймворки продолжают оставаться любимцами СМИ, их фанаты изрыгают лживую ложь о том, насколько они «хороши», тем чаще я сталкиваюсь с таким отношением.
Что-то усугублялось тем, что владельцы сайтов или их сотрудники пытались демонизировать истца / обиженных вместо того, чтобы просто признать правонарушения и исправить ситуацию.
Что честно показывает, какие полные мешки с грязью есть у некоторых людей. Тип социопатов и психопатов, которые припарковываются под углом посреди стоянки для инвалидов, недовольны стоимостью пандусов для инвалидных колясок и их бельмом на глазу и стирают следы шрифта Брайля на банкоматах и автоматах с газировкой.
Случай Domino - потрясающий пример этого, где вместо того, чтобы сказать «наше плохое», бросить парню бесплатную пиццу и решить эту чертову проблему, они обострили ее через суд, отрицая какие-либо нарушения. Результат? Истец получил действительно хорошую машину скорой помощи, гонорары адвоката, которые, вероятно, стоили больше, чем кровавое урегулирование, и то, что его тащили по грязи в СМИ. Всего этого, вероятно, можно было бы избежать, если бы они просто признались: «Мы не знали, мы исправим это, мы можем что-то придумать?»
… И я сталкиваюсь с этим уровнем подлого, высокомерного, невежественного обострения их проблем и безответственности хотя бы одного человека почти на каждого клиента, который у меня был за последние пять лет! Обычно тот, кто действительно отвечает за выбор своих наборов технологий.
К сожалению, по большей части это сводится к тому, что люди, ответственные за создание веб-сайтов, не имеют права писать одну чертову строчку HTML, CSS или JavaScript! Наверное, поэтому их так легко втянуть в использование невежественного, некомпетентного, тратящего время и раздуваемого мусора, известного как« фреймворки ».
