Я работаю над инициативой RAMP по борьбе с COVID-19. Мы выбрали Discourse для нашего форума и очень довольны им.
Коллега и я изучаем вопросы доступности. Я считаю, что проблемы с низким контрастом мы решили с помощью функциональности административных CSS-стилей. Однако, согласно отчету WAVE, у нас есть ряд проблем, которые, как нам кажется, мы не сможем решить самостоятельно:
Ссылка на изображение без альтернативного текста: речь идет об аватарах. Есть описательный заголовок, но атрибут alt пуст.
На каждой странице отсутствует метка:
<div><input type="text"></div>
На каждой странице есть пустой заголовок:
<div class="title"><h3></h3><!-- --></div>
Сообщается о множестве пустых кнопок, связанных с SVG.
Есть пустые ссылки, например: <a href="" aria-hidden="true" tabindex="-1" class="tabLoc"></a>
и <a href="" class="edit-topic" title="edit the title and category of this topic" data-ember-action="" data-ember-action-27="27"><svg class="fa d-icon d-icon-pencil-alt svg-icon svg-string" xmlns="http://www.w3.org/2000/svg"><use xlink:href="#pencil-alt"></svg></a>.
Есть пустой заголовок таблицы: <th data-sort-order="posters" class="posters"></th>
Меня очень удивит, если мы единственные, у кого возникают такие проблемы. Поэтому я спрашиваю: не слишком ли строго WAVE оценивает ситуацию, или, возможно, мы что-то упускаем? Любая помощь будет крайне ценной.
Спасибо за интерес. Есть один пункт, в котором я не уверен, что смогу найти (пустой заголовок), но остальные я получаю из функции WAVE «code» и могу найти (с некоторыми усилиями) с помощью инспектора F12.
Не уверен, что часовые пояса играют нам на руку (я нахожусь в Великобритании, UTC+01:00), но я с радостью проведу звонок в Teams или аналогичной платформе, чтобы продемонстрировать, если это будет полезно.
Сам по себе пустой атрибут alt — это нормально… он должен сигнализировать скринридеру, что изображение носит декоративный характер и его можно игнорировать… НО мы также добавляем атрибут title… поэтому это иногда может вызывать проблемы, согласно данным с `img` with null `alt `and non-null `title` attributes - Screen reader compatibility
Некоторые скринридеры корректно игнорируют аватары, но другие читают имя/имя пользователя дважды из-за этого.
Я создал PR для удаления атрибута title из аватаров в постах:
Это поле ввода, где показывается URL для копирования и распространения. PR для добавления здесь aria-метки:
Я не смог найти эту проблему… возможно, она зависит от настроек сайта? Нужно ещё немного разобраться.
Мы не добавляем метку для пользователей с нормальным зрением, так как они могут просто посмотреть на столбец и сделать вывод о его содержимом… Это гораздо сложнее сделать, если не видеть… Добавление метки для скринридеров имеет смысл:
Оставшиеся проблемы, которые я не затронул, связаны с кнопками — мне ещё нужно в них разобраться…
Большое спасибо за быстрые ответы и оперативные действия. Могу ли я подтвердить, что объединённые запросы теперь включены в код начиная с какой-то версии?
Также, было бы полезно, если бы я (привёл в порядок и) поделился темой, которую мы модифицировали, чтобы она соответствовала требованиям доступности WAVE?
Мой гениальный трюк, который я придумал в последний момент, — просто проверить страницу цветов на доступность.
Затем мы внесли множество изменений через CSS-редактор (admin/customize/themes/3/common/scss/edit), и я не уверен, как их передать (могу скопировать и вставить, но не знаю, нужно ли вам это и хотите ли вы видеть это в этой ветке). Думаю, если бы мы могли видеть другие упомянутые цвета (например, var(–primary-medium)) в высокоуровневом интерфейсе, всё стало бы проще. Например, классический случай: #919191 → #595959, но мой метод просто лечит симптомы, которые я каким-то образом замечаю при навигации по страницам (к тому же динамическая природа «сайта» означает, что то, что проходит сегодня, может не пройти завтра).
Готов попробовать и другой подход, просто дайте знать, хотя в любом случае я не смогу запустить демонстрационный сервис, проверить код и т. д.
Также хочу отметить, что мне не удалось исправить admin/upgrade вообще (там множество проблем с контрастностью); я не знаю, не следует ли оно стилям CSS или в чём причина.
Насколько я помню, административная часть Discourse использует отдельные (более сложные для редактирования) таблицы стилей, чтобы предотвратить случайную блокировку доступа к рабочему административному интерфейсу из-за изменений в CSS.
Я немного отстал от этого, хотя мы обновили форум. Но решил ответить тем, кто потратил время (большое спасибо!) на изучение этой темы.
Спасибо. Если я перейду по вашей ссылке, Wave найдёт 13 проблем с доступностью (низкий контраст), но не в самих цветах. Это потому, что, в отличие от страницы с цветами, она не показывает, как они используются (как фон или передний план с текстом).
Дайте знать, чем я могу помочь; в ней действительно много ошибок контрастности.
В оцениваемых постах (не уверен, насколько широко это используется в Discourse, это расширение, которое @angus любезно разработал для нас): Отсутствует метка формы
Множество (40 на странице, которую я рассматриваю, при этом два пользователя оценили её) случаев, выглядящих так: <input class=" disabled" type="radio" value="1" checked="" disabled="">. Это находится внутри <span class="star-rating">.
