Pull to refresh

Comments 14

А если сделать отдельный сервис (или софт, например простенький браузер), который переваривает любые сайты и вообще любое содержимое страниц — включая пдф документы, если они не отсканированы — и адаптирует их для людей с нарушением зрения (а заодно и других функций)?
Причем, если делать браузер, то он может использоваться вообще во всем мире, и это поможет просто огромному количеству людей.

Мне представляется, что лучше сделать один хороший инструмент, чем миллионы элементов подгонять под людей, тратя человекочасы и бюджеты (кстати о бюджетах, далеко не каждый заказчик сайта захочет заботиться о людях с ограниченными возможностями. Опять же потому, что это удорожает и увеличивает сроки).
Чтобы этот браузер работал, у страницы должна быть правильная разметка)
Я бы не согласился — просто с обывательской точки зрения я думаю, что браузер можно «научить» понимать и «правильную» разметку, и неправильную. Собственно об этом и идет речь.
Есть же машинное обучение, например. Почему его нельзя использовать? Показывать браузеру сайты, корректировать его ошибки и т.д. чтобы в итоге он всё переводил в доступный вид. Разумеется, это время, и для такого проекта нужно иметь команду желающих
Я не очень верю в это. Возьмем к примеру список задач. Если он помещен внутрь ul элемента, то скринридер дойдя до него скажет что-то типа: «Список элементов, пункт первый, полить цветы, пункт второй...» и т.д.
А если верстальщик засунет это все в div, то тогда скринридер будет просто читать всю страницу сплошным текстом без препинаний.

Ну или навигация сайта: пока верстальщик в nav не поместит ссылки, машина не поймет какая семантика у этой разметки. Это ведь может быть и просто облако тегов и ссылки на сайты спонсоров и вообще что угодно, пока автор контента сам явно не укажет какова роль у этих элементов. И никакая нейронная сеть не поможет)
Вы описали работу скринридера же. То есть подход все с «той же» стороны.

Теоретически же можно научить браузер трансформировать тот же Список элементов или чего угодно, нужно лишь чтобы он их различал, а это возможно если он увидит всю страницу целиком — тогда сможет понимать различия и для отличающихся элементов подбирать знакомые ему категории.

В целом сделать один хороший умный инструмент гораздо эффективнее чем переделывать все страницы в мире (тем более что все не будут переделаны, а если и будут, то в разном качестве). И этот же инструмент расширяет возможности человека до максимума

Проблемы вижу только две:
Никому это не нужно, потому что на таком вряд ли заработаешь
Это серьезная объемная работа, для которой нужно много человекочасов хороших специалистов
Теоретически, если сторонний верстальщик может с довольно высокой точностью понять что есть что в разметке другого верстальщика, то и машину можно научить думать подобным алгоритмом. Но опять же, лично мое мнение, что к тому времени и браузеров то не останется в привычном для нас виде и необходимость в этих разработках может отпасть сама собой)
Насчёт работы скрин ридеров вы не совсем правы. Я не отвечаю за JAWS, но NVDA, которым пользуются наверное 70% незрячих и я в том числе, читает немного не так. ul это маркерованный список, поэтому читать он его будет так:
мы доходим до списка и выбираем первый элемент
«список из 5 элементов маркер полить цветы»
жмём стрелку вниз
«маркер сходить в магазин»
доходим до последнего элемента или «прыгаем» на другой элемент уже вне списка
«вне список»

немного криво, но изначально скрин ридер был американским, поэтому читает, как перевели.
Насчет ul это я ошибся, надо было ol в пример ставить)
Я давно тестировал на маке через их встроенный voiceover и там примерно так все работало)
В общем отличия от NVDA видимо не значительные.
Прочитал все ваши комментарии на эту тему, но отвечаю именно на первый. Во-первых, такой браузер будет требовать огромную процессорную мощность, так как это самообучение и анализ больших объёмов информации. Скрин ридеры сами по себе на слабых компьютерах очень подтормаживают систему, а такой браузер будет просто ронять её. Я согласен, что не все будут заниматься доступностью, но крупные компании ради сохранения имиджа точно будут. Не сразу, но они реагируют на отзывы и все-таки что-то меняют.
Браузер лишь гипотеза — может быть что-то другое.
Вообще, я считаю что техническая реализация в любом случае есть, был бы проект.

А самообучение, оно же будет только в процессе разработки и далее в фоновом режиме на серверах будет анализировать, а результаты пользователям выдавать уже в виде готового материала. Да хотя бы просто кодом с кучей условий
Привет. Есть вопрос по скринридерам:
Допустим на странице имеется элемент input type=text aria-invalid=false. Если введенное пользователем значение не проходит валидацию, то необходимо присвоить атрибуту aria-invalid значение true. Это можно сделать двумя способами:
1) классическим — поменять значение атрибута через js;
2) современным (angular, react) — отрендерить компонент заново с измененным значением атрибута;

Так вот я давно читал о том, что второй способ не рекоммендуется, ибо скринридер не всегда может понять, что это изменился стэйт у старого элемента. Он иногда думает, что старый компонент исчез и вместо него появился новый, которого раньше небыло и от этого впадает в ступор. Интересно узнать ваш пользовательский опыт в этом моменте.
Как вы понимаете, я не всегда смотрю исходный код проблемной страницы, поэтому не могу сказать, в каких именно случаях возникают проблемы, но да, такое бывает, что скрин ридер после нескольких неверных символов сбрасывается на начало страницы или зависает, а потом все равно сбрасывается. Если вы приведёте пример сайта с такой валидацией в формах, я могу посмотреть и сказать вам результат.
Хорошо, как мне на глаза попадется нечто похожее, то обращусь в личку с просьбой помочь протестировать, если Вы не против)
Конечно, обращайтесь обязательно. Я только за то, чтобы тестировать сайты на доступность и помогать в её улучшении.
Sign up to leave a comment.

Articles

Change theme settings