От автора: я консультант по доступности. Я решаю проблемы. Одна из самых распространенных проблем с веб-сайтами, которые меня просили исправить — это сломанные, деформированные, неполные недоступные формы. Есть несколько вещей, на которые прокуроры или адвокаты истцов с ограниченными возможностями обращают особое внимание, потому что пользователи с ограниченными возможностями не могут использовать по какой-либо причине.
Есть МНОГО способов «сломать» форму… но главные проблемы, с которыми я постоянно сталкиваюсь следующие:
Отсутствуют теги label.
Неправильное использование элементов формы в label и/или отсутствие отношений «for/id».
Использование placeholder=»» вместо label.
Отсутствие fieldset вокруг связанных наборов переключателей/чек-боксов или групп изменяемых пользователем элементов формы.
Использование исключительно JavaScript для работы форм.
Метки — это не что-то, что можно использовать по желанию, они должны использоваться по назначению!
Меня часто удивляет, что это единственное, что не так с формой. Если вам не хватает правильной метки вокруг 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, из-за незнания, когда правильная семантика — как это было выше — обеспечила бы больше чем достаточно для любого желаемого стиля без ущерба для доступности.
И нет, placeholder — это не метка!
Placeholder должен быть примером того, что будет вводиться, а не описанием того, что вводить. Серьезно, ребята, посмотрите!
Он создает иллюзию «ложной простоты», он не работает для большинства программ чтения с экрана или средств чтения шрифтов Брайля, и в целом это вычурная и невежественная ерунда, которую НЕ следует делать на веб-сайтах. И нет, репликация поведения с помощью JavaScript — тоже не лучший вариант!
Это тип мусора, который верстальщики, заблуждаясь, что они «веб-дизайнеры», часто выбрасывают на ветер из-за своего полного незнания HTML, CSS или норм доступности. Помните, что настоящий дизайн — это инженерия, включающая искусство, а не искусство само по себе. Если вы не учитываете стандарты, руководящие принципы, удобство использования или доступность … и все, что вы делаете, это перемещаете пиксели в программе рисования, такой как Photoshop или какой-то тупой WYSIWYG … ну, вы НЕ дизайнер!
Fieldsets, используйте их!
Возвращаясь к HTML 4, строгое требование к контейнерам уровня блока, как к дочерним элементам form, не были случайными или непреднамеренными. Это было сделано для поощрения использования fieldset в качестве площадки для невизуальной навигации, разделения форм на разделы. Он также группирует несколько элементов формы в связанные разделы. В то время как HTML 5 ослабил это ограничение, отсутствие fieldset все еще нарушается во многих невизуальных 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 также следует использовать для упаковки таких вещей, как radio.
<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, до сих пор не понимают for / id или что name для серверной стороны, а ID для клиентской стороны.
Если вы пропускаете fieldset, потому что вам не нравится, как он выглядит, или вы не думаете, что это необходимо, вы потенциально можете сказать огромному количеству пользователей, чтобы они отвалили. Меня даже не волнует, что это может быть простой поиск по заголовку, где есть только один input и один button!!!
Разве legend не «проблематичен» для style?
Если вы удаляете границы / отступы / поля из fieldset, сначала может показаться, что настройка внешнего вида тега legend бесполезна. Никакие два браузера не используют одинаковые значения по умолчанию для размещения тега legend в границах, поэтому простое обнуление позиционирования не совсем подходит для разных браузеров. В течение многих лет мы видели всевозможные уловки, такие как абсолютное позиционирование SPAN внутри него над отступом в родительском FIELDSET и т.д., и т.д.
Пять или шесть лет назад кто-то заметил, что если вы установите его как float, все лишнее форматирование будет удалено. В большинстве случаев, если вы просто установите:
float:left; width:100%;
Вы можете стилизовать его по всей ширине, как вам нравится, как если бы это был заголовок внутри набора полей. Если вы хотите расположить его слева / справа, просто добавьте сначала box-sizing:border-box;, чтобы случайно не сделать его шире, чем родительский набор полей.
Только JavaScript?
Снова и снова это самая большая проблема с точки зрения доступности, и она только усугублялась ментальными карликами, такими как React, Vue и другими интерфейсными фреймворками JavaScript.
Приношу извинения, если это грубо или оскорбительно, но ошеломляюще тупые люди с забитой головой разным мусором, которые изливают это скриптодерство, стало проклятием для пользователей с ограниченными возможностями. Если ваша форма не работает с отключенными скриптами на стороне клиента, вы говорите огромному количеству пользователей, чтобы они пошли в долгое эротическое путешествие! Независимо от того, насколько горячей, модной, яркой и блестящей будет ваша невежественная некомпетентная болванка.
На самом деле знаете что, никаких извинений. Я называю вещи своими именами!
Я не говорю, что вы не можете использовать JavaScript в формах, но форма или любая основная активность пользователя должны быть закодированы для работы без JavaScript Изначально! Как я сказал в своей предыдущей статье по этой теме, хороший JavaScript должен улучшать уже работающую страницу, а не быть единственным средством, с помощью которого все работает!
Это, наверное, самая простая часть, но то, как многие люди теперь неправильно создают формы и во всем полагаются на JavaScript? Что ж, это почти всегда главная проблема доступности на сайтах, над которыми я сейчас работаю. Совершенно отстойно говорить клиенту, который сталкивается с угрозой штрафов или урегулирования, что единственный способ исправить определенные разделы — это полностью избавиться от того, как они реализованы, и перекодировать их с нуля «в правильном направлении».
Много интерфейсных фреймворков, ориентированных на JavaScript — и люди, которые злоупотребляют ими или неправильно их используют — виноваты в этом!
Почему все это так важно?
Меня много критикуют за «заботу» об этом, но есть две важные причины, по которым вам действительно стоит беспокоиться.
1. Не будучи доступным, вы блокируете контакты, не можете развивать свой бизнес, предотвращаете возможные продажи и в целом отталкиваете пользователей. И не надо мне нести чушь про «целевую аудиторию». Это Интернет, единственное, что мы можем точно знать о том, кто будет посещать веб-сайт — это то, что мы абсолютно не знаем, кто посетит веб-сайт.
2. Во многих странах существуют законы, такие как ADA в США и 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! Вероятно, поэтому они так легко застревают в использовании невежественного, некомпетентного, раздутого мусора, известного как «фреймворки».
Автор: Jason Knight
Источник: levelup.gitconnected.com
Редакция: Команда webformyself.
