В моем случае добавьте что-то вроде className: "btn btn-default" к react-router Link.
Вот так: <Link className="btn btn-default" to={linkUrl}>Go!</Link>
Будет ли это сбивать с толку людей, которые используют вспомогательные технологии для просмотра сайта?
Несколько общих советов о том, когда использовать <a href>, а когда <button> или <input type="submit">:
<a href> (spec).<button> (спец.).<input type="submit"> или <button type="submit"> (spec< /а>).Я предостерегаю от изменения роли по умолчанию элемента с атрибутом role, так как это может в конечном итоге вызвать некоторую путаницу и привести к конфликту для некоторых вспомогательных технологий. Они также нарушают first и вторые правила использования ARIA.
Обратите внимание и на клавиатуру. Гиперссылку (<a href>) можно запустить, нажав клавишу ввода. Но настоящий <button> можно запустить, нажав клавишу ввода или пробел. Когда гиперссылка находится в фокусе и пользователь нажимает пробел, страница прокручивается на один экран. Пользователи некоторых вспомогательных технологий ожидают поведения, основанного на используемом элементе.
Я думаю, также стоит упомянуть, что события, запускаемые клавишей пробела, срабатывают только при отпускании клавиши, тогда как при использовании клавиши Enter событие срабатывает, как только вы нажимаете клавишу (до ее отпускания).
Поэтому начните с правильного элемента для задачи, используя приведенный выше список, а затем настройте его так, чтобы он выглядел так, как вы хотите.
В общем, лучшая практика — сделать так, чтобы вещи выглядели так, как будто они действуют, но у вас может не быть такой роскоши, так что теперь какую роль должен играть элемент?
Вы должны стилизовать и назначать роли своим ссылкам и кнопкам, чтобы они сообщали об этом пользователю. Это общая хорошая практика юзабилити.
Однако это работает только в мире, в котором люди, занимающиеся брендингом и маркетингом, не имеют права голоса. Вы когда-нибудь слышали аргумент «нам нужно сделать эту ссылку более заметной, чтобы посетители чаще нажимали на нее…» Именно здесь ссылки начинают превращаться в этих монстров, которых больше невозможно идентифицировать по тому, как они выглядят И действуют.
Итак, теперь вы наткнулись на один из великих споров о доступности: должно ли что-то иметь роль, соответствующую тому, как оно ведет себя, или роль, которая соответствует тому, как оно выглядит?
Ссылка — это элемент, который направляет браузер в другое место (либо на другую страницу, либо в другое место на той же странице). Вот как это было разработано.
Кнопки, с другой стороны, предназначены для взаимодействия со страницей или отправки данных.
Сложность заключается в том, что когда у вас есть ссылка, которая выглядит как кнопка, и слепой пользователь звонит в службу поддержки, и сотрудник службы поддержки говорит «нажмите кнопку X», а программа чтения с экрана объявляет ссылку Y (потому что текстовая альтернатива для кнопки неверна), тогда слепой пользователь очень расстраивается, потому что не может найти ни кнопку, ни что-то, что соответствует X.
Однако, если вы пытаетесь сделать доступность правильным способом, и текст вашей ссылки соответствует видимой информации для элемента, то, по моему мнению, у вас всегда должна быть роль для элемента, которая соответствует тому, как он себя ведет.
В вашем конкретном примере кто-то, использующий систему распознавания речи, такую как Dragon, с трудом нажмет ссылку, потому что он может использовать команду, такую как «кнопки», чтобы перечислить все кнопки и не увидеть элемент, который они ожидают. Затем этот пользователь должен будет догадаться, что это на самом деле ссылка, или использовать наведение мыши для взаимодействия с элементом.
Вопросы, поднятые aadrian и unobf выше, точны и хорошо изложены. Есть еще одна реальность, от которой не уйти и которая напрягает руку разработчика.
Дизайнеры часто преуменьшают значение одного или нескольких активный элемент в группе, например, кнопка удаления, потому что она используется реже или катастрофична, если используется по ошибке. Исследования показывают, что с помощью этой стратегии можно уменьшить количество катастрофических ошибок.
Поскольку многие опытные профессионалы требуют, чтобы разметка для контрольных совпадала презентации, первый порыв разработчика может состоять в том, чтобы пометить элемент управления удалением как ссылку.
Вспомогательные технологии для слабовидящих, такие как Jaws, полагаются на списки элементов управления одного типа. Опросы показывают, что слабовидящие довольно часто используют эту стратегию.
Принимая во внимание эти реалии доступности, очень плохой практикой является разметка списка действий в виде кнопок с одной или несколькими ссылками для таких действий, как удаление. Пользователь с ослабленным зрением, скорее всего, не свяжет ссылку с кнопками и может полностью ее пропустить.
Эта реальность, по сути, вынуждает разработчиков действовать. Если дизайн требует удалить ссылку в списке кнопок, разработчик должен пометить ссылку как кнопку, даже если навигация с помощью клавиатуры не будет идеально выровнена для зрячего пользователя.
