Фото предоставлено Давейниным
Поля пароля довольно часто имеют функцию «Показать пароль» — флажок или кнопку, которые временно преобразуют поле в простой текст, чтобы пользователи могли видеть вводимый ими пароль.
Однако мне пришло в голову, что это может быть небезопасно для пользователей программ чтения с экрана, потому что слепой человек может не знать, смотрит ли кто-то на их экран (например, в полупубличном пространстве, например в офисе или конференц-зале).
Поля пароля запутываются для программ чтения с экрана так же, как они визуально — программа чтения с экрана будет произносить звездочку
или подобное для каждой набранной буквы, а не объявлять само письмо. Как и для зрячих пользователей, пользователь программы чтения с экрана не имеет интерактивной обратной связи, чтобы подтвердить, что они правильно ввели свой пароль.
Поэтому я хотел изучить возможность написания сценариев для этой функции, чтобы пользователь программы чтения с экрана мог слышать, что он печатает, в то время как поле остается визуально запутанным. Тогда пользователь, который слушает через наушники, может быть уверен, что его пароль не раскрывается никому из окружающих.
Это не сработало!
Но по пути мне напомнили некоторые домашние истины о доступном JavaScript и о печальной проблеме с живыми регионами ARIA, которая имеет более широкие последствия для доступных сценариев в целом.
Первый прототип
Основная идея, которую я имел в виду, была довольно простой: элемент с aria-live="assertive" будет добавлен на страницу, а затем, когда поле пароля будет отредактировано, его значение будет скопировано в этот элемент. Поскольку это живая область , новое значение будет немедленно объявлено программами чтения с экрана, но оно также будет скрыто с позиционированием влево и не будет располагаться в порядке табуляции, поэтому в противном случае оно не будет очевидно.
Вот код для этого (или посмотрите первый прототип на своей странице ):
Если вы используете программу чтения с экрана, поддерживающую ARIA, кнопка « Слышать пароль»
должна включить эту функцию и сразу же сказать, какое значение уже есть в поле. Затем, пока он остается включенным, программа чтения с экрана объявит значение по мере его ввода (а также произнесет звездочку
).
Если вы не используете программу чтения с экрана, вы ничего не услышите. Хотя было бы возможно реализовать прямое преобразование текста в речь, используя что-то вроде meSpeak.js , я не думаю, что это хорошая идея — потому что у любого, кому нужна эта функциональность, уже есть средство чтения с экрана.
Более того, у них есть программа для чтения с экрана, в которой они контролируют скорость голоса и речи ; внешний TTS будет просто мешать.
Следующее видео демонстрирует то, что бы испытал пользователь программы чтения с экрана (используя Firefox + NVDA):
Теперь одна проблема, которая сразу становится очевидной, заключается в том, что копирование всего значения в область реального времени означает, что значение рассматривается как слово; каждый раз, когда пользователь вводит букву, объявляется все значение, а не только буква, которую он набрал. Это сильно отличается от поведения стандартного текстового поля, где устная обратная связь сообщает вам отдельные буквы по мере их ввода.
В этом примере я набрал пароль, который можно интерпретировать как слово, но что, если значение будет более запутанным, например, "NCC-1701" ? Ну, в этом случае NVDA скажет ncc одна тысяча семьсот один
, что проблематично по другой причине: она не говорила нам, что первые три буквы были прописными, а не строчными, и не объявляла тире совсем. Ситуация несколько лучше в «Челюстях», которые говорят о тире, но в них все еще не упоминаются столицы.
Это довольно фундаментальная проблема. Если ваш пароль представляет собой одно строчное слово, то это решение будет работать достаточно хорошо, но если это смесь специальных символов, вы можете вообще не услышать весь пароль. Например, вы можете подумать, что вы набрали "ncc1701" а не "NCC-1701" , и разница, очевидно, значительна, когда мы проверяем пароль!
И это даже не особенно сложный пример. Что если бы ваш пароль был чем-то сложным, например, "goHuE&-A" — NVDA объявила бы это как go hooey и a
, что на самом деле не помогает вообще! Или что, если ваш пароль был чем-то вроде "gate" , но вы на самом деле набрали "gaite" — "gaite" обратная связь в обоих случаях была бы абсолютно одинаковой.
Второй прототип
Может быть, мы могли бы улучшить это, предоставив более подробную обратную связь. Вместо того, чтобы произносить полное значение всякий раз, когда значение изменяется, мы могли бы произносить отдельные буквы в ответ на события keypress .
Вот модифицированный код для этого подхода (или посмотрите второй прототип на его собственной странице ):
И вот он используется в Firefox + NVDA:
В одном смысле это лучше, так как при вводе выдает более детальную обратную связь, но в другом смысле это хуже, потому что ограничивает вашу скорость ввода. В каждой букве все еще написано « звезда»,
прежде чем она произнесет реальный символ, поэтому вам нужно подождать, чтобы это произошло, чтобы услышать символ; если вы печатаете быстрее, вы не услышите ни одной буквы, пока не остановитесь, после чего вы услышите только последнюю (как показано на видео).
Таким образом, все, что делает этот обновленный прототип, — это решить одну проблему, создав другую.
Нет больше прототипов!
Может быть, есть способы, которыми мы можем улучшить это. Возможно, мы могли бы разделить значение на пробелы, например, чтобы вывести "hello" вместо "hello" , чтобы отдельные буквы произносились вместо всего слова. Это будет работать для писем, но это не решит проблему не говорящих заглавных букв и знаков препинания, а только усугубит проблему с паролями, которые содержат пробелы.
В любом случае, мы сейчас находимся в сфере безобразного взлома! Иногда доходит до того, что больше взлома приводит к большему количеству взлома, и мы вынуждены отступить от того, что делаем, и спросить — была ли эта идея плохой? Если мы не сможем заставить его реагировать так же, как обычное текстовое поле, у нас никогда не будет интуитивного решения.
И поскольку лозунги идут, это довольно полезно. Если мы не можем создать интуитивно понятное решение — если единственный способ что-то сделать — это бесконечно взламывать мелкие неряшливые решения — тогда, возможно, это не стоило делать в первую очередь.
Это живое?
Но есть большая проблема, с которой приходится бороться, что делает все это довольно неактуальным, это то, что он не работает в IE + Jaws ; так как это самая популярная комбинация , то если не работает, это довольно большое дело.
Вот первый прототип, снова используемый в IE + Jaws:
Вы можете видеть, как нажатие кнопки « Слышать пароль»
просто объявляет об обновленном состоянии кнопки, но не считывает значение в активной области. Причина этого сводится к поведению aria-live="assertive" .
Атрибут aria-live имеет три возможных значения, которые определяют, насколько убедительным должно быть сообщение:
-
"off"означает, что изменение содержания не объявлено. -
"polite"означает, что изменение должно быть объявлено только тогда, когда пользователь бездействует (т.е. ждет, пока программа чтения с экрана не остановит все, что говорит в данный момент) -
"assertive"означает, что изменение должно быть незамедлительно объявлено (то есть прерывать все, что говорит экранный читатель в данный момент)
Но недавно Расс Уикли и я провели некоторое тестирование с живыми регионами ARIA в рамках подготовки к предстоящему курсу « Learnable» , и то, что мы обнаружили, настолько важно, что само по себе заслуживает смелого абзаца:
Уверенные живые регионы обычно не являются напористыми.
Другими словами, большинство комбинаций браузера и программы чтения с экрана на самом деле не учитывают "assertive" значение, они относятся к нему так же, как и "polite" . В частности — только VoiceOver с Chrome или Safari фактически прервет пользователя, чтобы объявить напористое сообщение; все другие протестированные комбинации (включая NVDA или Jaws с любым браузером) не сообщат об этом, пока программа чтения с экрана не будет молчать.
То, что мы имеем в этих прототипах, — это напористый регион, рассматриваемый как вежливый. Значение было объявлено в Firefox + NVDA, потому что нажатие кнопки « Слышать пароль» больше
ничего не вызывает — NVDA не читает обновленный текст кнопки, и, поскольку больше ничего не говорится, вежливое сообщение может быть объявлено. Однако в IE + Jaws нажатие кнопки приводит к тому, что она читает обновленный текст кнопки, что означает, что читатель не находится в режиме ожидания, и, следовательно, текущий регион не объявляется.
Вывод
Ничто из этого не должно восприниматься как причина, по которой не реализована стандартная функциональность Show Password
(т.е. это просто переключает тип поля). Эти решения могут быть доступны для программ чтения с экрана, единственная проблема — потенциальный риск безопасности / конфиденциальности, который они представляют.
Но если альтернативой не является предоставление каким-либо способом пользователям доступа к их паролю, то, возможно, лучше сделать это, чем ничего не делать. (Хотя можно было бы с практической точки зрения сказать, что поля пароля просто не должны маскироваться вообще, но такие вопросы выходят за рамки данной статьи.)
Возможно, мы могли бы смягчить риск, объяснив его для пользователей программ чтения с экрана, что мы можем сделать, добавив aria-label к кнопке запуска. Когда кнопка или ссылка имеют aria-label , средство чтения с экрана будет произносить текст метки вместо содержимого элемента — поэтому оно должно, по крайней мере, содержать ту же информацию, но также может иметь дополнительную информацию, которая важна только для пользователей программы чтения с экрана (и эта техника имеет целый ряд применений ):
<button aria-label = "Показать пароль в виде обычного текста. Примечание. Это позволит визуально отобразить ваш пароль на экране."> Показать пароль Кнопка </>
В конечном счете, что важно извлечь из этого эксперимента, так это основная истина о доступных сценариях: если он не может решить проблему удобным и интуитивно понятным способом, то он не решил проблему .
Доступность — это не упражнение при выполнении абстрактных проверок, а улучшение юзабилити для людей с особыми потребностями . Таким образом, решение, которое технически доступно, но неприменимо для этих групп пользователей, на самом деле не может считаться доступным вообще.