Как сделать сайты доступнее для пользователей с нарушениями зрения
Комментарии (6)
11 августа 2017 в 16:17
0↑
↓
А если сделать отдельный сервис (или софт, например простенький браузер), который переваривает любые сайты и вообще любое содержимое страниц — включая пдф документы, если они не отсканированы — и адаптирует их для людей с нарушением зрения (а заодно и других функций)?
Причем, если делать браузер, то он может использоваться вообще во всем мире, и это поможет просто огромному количеству людей.Мне представляется, что лучше сделать один хороший инструмент, чем миллионы элементов подгонять под людей, тратя человекочасы и бюджеты (кстати о бюджетах, далеко не каждый заказчик сайта захочет заботиться о людях с ограниченными возможностями. Опять же потому, что это удорожает и увеличивает сроки).
11 августа 2017 в 16:50
+1↑
↓
Чтобы этот браузер работал, у страницы должна быть правильная разметка)11 августа 2017 в 16:54
+1↑
↓
Я бы не согласился — просто с обывательской точки зрения я думаю, что браузер можно «научить» понимать и «правильную» разметку, и неправильную. Собственно об этом и идет речь.
Есть же машинное обучение, например. Почему его нельзя использовать? Показывать браузеру сайты, корректировать его ошибки и т.д. чтобы в итоге он всё переводил в доступный вид. Разумеется, это время, и для такого проекта нужно иметь команду желающих11 августа 2017 в 17:21
+1↑
↓
Я не очень верю в это. Возьмем к примеру список задач. Если он помещен внутрь ul элемента, то скринридер дойдя до него скажет что-то типа: «Список элементов, пункт первый, полить цветы, пункт второй…» и т.д.
А если верстальщик засунет это все в div, то тогда скринридер будет просто читать всю страницу сплошным текстом без препинаний.Ну или навигация сайта: пока верстальщик в nav не поместит ссылки, машина не поймет какая семантика у этой разметки. Это ведь может быть и просто облако тегов и ссылки на сайты спонсоров и вообще что угодно, пока автор контента сам явно не укажет какова роль у этих элементов. И никакая нейронная сеть не поможет)
11 августа 2017 в 17:47
0↑
↓
Вы описали работу скринридера же. То есть подход все с «той же» стороны.Теоретически же можно научить браузер трансформировать тот же Список элементов или чего угодно, нужно лишь чтобы он их различал, а это возможно если он увидит всю страницу целиком — тогда сможет понимать различия и для отличающихся элементов подбирать знакомые ему категории.
В целом сделать один хороший умный инструмент гораздо эффективнее чем переделывать все страницы в мире (тем более что все не будут переделаны, а если и будут, то в разном качестве). И этот же инструмент расширяет возможности человека до максимума
Проблемы вижу только две:
Никому это не нужно, потому что на таком вряд ли заработаешь
Это серьезная объемная работа, для которой нужно много человекочасов хороших специалистов
11 августа 2017 в 17:07
0↑
↓
Привет. Есть вопрос по скринридерам:
Допустим на странице имеется элемент input type=text aria-invalid=false. Если введенное пользователем значение не проходит валидацию, то необходимо присвоить атрибуту aria-invalid значение true. Это можно сделать двумя способами:
1) классическим — поменять значение атрибута через js;
2) современным (angular, react) — отрендерить компонент заново с измененным значением атрибута;Так вот я давно читал о том, что второй способ не рекоммендуется, ибо скринридер не всегда может понять, что это изменился стэйт у старого элемента. Он иногда думает, что старый компонент исчез и вместо него появился новый, которого раньше небыло и от этого впадает в ступор. Интересно узнать ваш пользовательский опыт в этом моменте.