Желание автоматизировать рутинные проверки, как и готовность контрибьютить в опенсорс - это прекрасно, рад, что вы решили поделиться своим решением с другими.
Не могу, однако, не отметить некоторые моменты, которые меня смутили:
Проверка aria-labelledby и других атрибутов, использующих ID, на уровне линтера верстки - элементы совсем не обязательно будут в одном файле, плюс реально проверить, что атрибут указывает на нужный нам элемент (а не на другой элемент с таким же ID) можно только в тесте реальной страницы.
В целом идеально было бы найти подходящие по контексту правила в существующем jsx-a11y (или i18next) плагине и попробовать законтрибьютить улучшения туда, так намного больше шансов, что люди этим воспользуются. Готов посодействовать в этом, если есть интерес.
Не знаю, чем конкретно руководствовались дизайнеры стандартной библиотеки компонентов андроида, но полагаю, что основная причина в том, что текстовые поля или вот такие вот spin buttons просто-напросто покрывают больше сценариев использования, и уровень доступности дают наивысший — работают и с тачем, и с клавиатурой, и с чем угодно ещё, и не требуют ни инструкций для пользователя, ни дополнительного дизайна/тестирования.
Хорошо бы иметь возможность добавить циферблат (или вот календарь) в тех редких случаях, когда они действительно нужны (для планирования дат поездок или быстрой установки будильника) в конкретное приложение или как вариант кастомизации, но в большинстве случаев компактный набор полей работает хорошо.
Но на практике VoiceOver не воспринимает списки, если тегу списка не продублировать соответствующую роль:
Это не совсем правда :) VoiceOver отлично воспринимает списки, таблицы, и многие другие HTML-элементы без дополнительных атрибутов. Логика зашита конкретно в WebKit / Safari, которые убирают семантические роли с элементов, у которых убраны стили, соответствующие ожидаемой семантике. Можно называть такое решение команды разработки Safari спорным, и иногда оно реально требует хаков, как у вас, но сделано это примерно по тем же причинам, из-за которых не озвучиваются теги типа b, i, s — из-за того, что разработчики злоупотребляют некоторыми тегами (с помощью таблиц, например, до сих пор многие верстают имейлы).
Safari, кстати, не единственный браузер, который так делает: большинство браузеров те же таблицы не считает таблицами, если в них нет заголовков (th). Для списков же в том же Safari есть другая эвристика: если список находится внутри навигации (nav), роль сохраняется независимо от стилей
Ох, ответ на этот вопрос стоит отдельного поста (или даже нескольких) от людей, которые эту систему сбора и визуализации аналитики строили, и не все из них до сих пор работают в Райке, а я там скорее мимо проходил, поэтому в самых общих чертах опишу, как всё работает.
Начну с самого простого, сложности компонента: это просто выдуманное число наподобие оценки задачи в story points для условной кросс-функциональной команды. Мы примерно, опираясь на опыт нашей платформенной команды, оцениваем, что сделать гибкий и доступный с клавиатуры компонент Select стоит 80 попугаев, а переиспользуемую директиву для закрытия попапов по Escape всего 16. Таким образом, команда, подключившая себе наш готовый компонент, сэкономила эти 16 или 80 попугаев (если возможности компонента не используются на 100%, то меньше).
Про процентное соотношение и список используемых компонентов: мы берем все упоминания наших компонентов в HTML-шаблонах (для Angular, во всяком случае, для React-стека пока эта фича не реализована) и делим на общее количество элементов верстки. Эта метрика не является целевой, и мы не ожидаем, что она где-то будет существенно превышать 50%, верстка по месту — это нормально.
Теперь про то, что есть "фича" вроде той же канбан-доски с точки зрения кода. Райк состоит из большого числа пакетов в формате npm или же pub (пакетного менеджера Dart), и фичи продукта обычно представляют из себя один или несколько пакетов с кодом UI-компонентов и бизнес-логики, которые называются как-нибудь в духе wrike_featurename_app, wrike_featurename_components, etc. Это позволяет верхнеуровнево понять, из каких пакетов / реп та или иная фича состоит. Мы, однако, пошли намного дальше: каждый файл с кодом (или папка целиком) размечается специальной аннотацией, в которой конкретно указано, к какой фиче код относится, без этой аннотации код в мастер не попадает. Попутно это позволяет не держать в уме или каких-то отдельных табличках, кому какой код принадлежит и кто отвечает за разбор инцидентов, информация о владельцах прописана прямо в самой фиче.
Хорошо, что автор статьи сформировал для себя «правила хорошего тона» в чатах и делится ими с сообществом.
Меня очень расстраивает, что изложены эти правила с непроверенной орфографией и пунктуацией, и притом отвратительно канцелярским языком.
Вдобавок ко всему автор умудряется, утверждая о недопустимости оскорбительно-оценочных суждений в одном из правил, использовать эти же самые оскорбительно-оценочные суждения (с совершенно эталонными исключениями для «начальников и людей, от которых вы материально зависимы»), иллюстрируя другое правило.
Пожалуйста, исправьте ссылку на этот чат:
> pro.js.noobs — Чат про JavaScript (для новичков)
К сожалению, овнер этого и других pro.чатов больше не выходит с остальными админами на связь, поэтому мы решили пересоздать его. Чат называется JavaScript Noobs и расположен по адресу t.me/js_noobs_ru
Процессы внесения средств и инкассации максимально автоматизированы, в этом случае намного вероятнее решение проблем клиента, если они возникают. Пополнение через [оператора денежных переводов] или кассу в отделении [банка какого-нибудь другого цвета] за комиссию, возможно, ощущается более надежным из-за присутствия за стеклом живого материально ответственного человека, но не всегда таковым является.
Правильно сделали, что не продались. И дело тут не в деньгах (хотя и тут не прогадали), а в том, что Dropbox стал бы эксклюзивной фичей Apple-экосистемы, и остальным бы вообще ничего не досталось.
Желание автоматизировать рутинные проверки, как и готовность контрибьютить в опенсорс - это прекрасно, рад, что вы решили поделиться своим решением с другими.
Не могу, однако, не отметить некоторые моменты, которые меня смутили:
Отдельное правило для обработки декоративных изображений — по спеке HTML для этого атрибут alt можно оставить пустым (но все равно указать, так как он обязательный у img), и изображение будет убрано из дерева доступности, jsx-a11y уже это поддерживает и рекомендует делать вместо ручного переопределения ARIA роли в presentation https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/blob/91e39b45ade789c86ae14df869a86b0ea468ed95/src/rules/alt-text.js#L57
Проверка aria-labelledby и других атрибутов, использующих ID, на уровне линтера верстки - элементы совсем не обязательно будут в одном файле, плюс реально проверить, что атрибут указывает на нужный нам элемент (а не на другой элемент с таким же ID) можно только в тесте реальной страницы.
В целом идеально было бы найти подходящие по контексту правила в существующем jsx-a11y (или i18next) плагине и попробовать законтрибьютить улучшения туда, так намного больше шансов, что люди этим воспользуются. Готов посодействовать в этом, если есть интерес.
Не знаю, чем конкретно руководствовались дизайнеры стандартной библиотеки компонентов андроида, но полагаю, что основная причина в том, что текстовые поля или вот такие вот spin buttons просто-напросто покрывают больше сценариев использования, и уровень доступности дают наивысший — работают и с тачем, и с клавиатурой, и с чем угодно ещё, и не требуют ни инструкций для пользователя, ни дополнительного дизайна/тестирования.
Хорошо бы иметь возможность добавить циферблат (или вот календарь) в тех редких случаях, когда они действительно нужны (для планирования дат поездок или быстрой установки будильника) в конкретное приложение или как вариант кастомизации, но в большинстве случаев компактный набор полей работает хорошо.
Это не совсем правда :) VoiceOver отлично воспринимает списки, таблицы, и многие другие HTML-элементы без дополнительных атрибутов. Логика зашита конкретно в WebKit / Safari, которые убирают семантические роли с элементов, у которых убраны стили, соответствующие ожидаемой семантике. Можно называть такое решение команды разработки Safari спорным, и иногда оно реально требует хаков, как у вас, но сделано это примерно по тем же причинам, из-за которых не озвучиваются теги типа b, i, s — из-за того, что разработчики злоупотребляют некоторыми тегами (с помощью таблиц, например, до сих пор многие верстают имейлы).
Safari, кстати, не единственный браузер, который так делает: большинство браузеров те же таблицы не считает таблицами, если в них нет заголовков (th). Для списков же в том же Safari есть другая эвристика: если список находится внутри навигации (nav), роль сохраняется независимо от стилей
https://www.scottohara.me/blog/2019/01/12/lists-and-safari.html
Человек растянул на несколько тысяч знаков мем “There are No Girls on the Internet” вперемешку с нытьем про «повесточку» в фильмах. Ставлю класс.
Ох, ответ на этот вопрос стоит отдельного поста (или даже нескольких) от людей, которые эту систему сбора и визуализации аналитики строили, и не все из них до сих пор работают в Райке, а я там скорее мимо проходил, поэтому в самых общих чертах опишу, как всё работает.
Начну с самого простого, сложности компонента: это просто выдуманное число наподобие оценки задачи в story points для условной кросс-функциональной команды. Мы примерно, опираясь на опыт нашей платформенной команды, оцениваем, что сделать гибкий и доступный с клавиатуры компонент Select стоит 80 попугаев, а переиспользуемую директиву для закрытия попапов по Escape всего 16. Таким образом, команда, подключившая себе наш готовый компонент, сэкономила эти 16 или 80 попугаев (если возможности компонента не используются на 100%, то меньше).
Про процентное соотношение и список используемых компонентов: мы берем все упоминания наших компонентов в HTML-шаблонах (для Angular, во всяком случае, для React-стека пока эта фича не реализована) и делим на общее количество элементов верстки. Эта метрика не является целевой, и мы не ожидаем, что она где-то будет существенно превышать 50%, верстка по месту — это нормально.
Теперь про то, что есть "фича" вроде той же канбан-доски с точки зрения кода. Райк состоит из большого числа пакетов в формате npm или же pub (пакетного менеджера Dart), и фичи продукта обычно представляют из себя один или несколько пакетов с кодом UI-компонентов и бизнес-логики, которые называются как-нибудь в духе
wrike_featurename_app,wrike_featurename_components, etc. Это позволяет верхнеуровнево понять, из каких пакетов / реп та или иная фича состоит. Мы, однако, пошли намного дальше: каждый файл с кодом (или папка целиком) размечается специальной аннотацией, в которой конкретно указано, к какой фиче код относится, без этой аннотации код в мастер не попадает. Попутно это позволяет не держать в уме или каких-то отдельных табличках, кому какой код принадлежит и кто отвечает за разбор инцидентов, информация о владельцах прописана прямо в самой фиче.Меня очень расстраивает, что изложены эти правила с непроверенной орфографией и пунктуацией, и притом отвратительно канцелярским языком.
Вдобавок ко всему автор умудряется, утверждая о недопустимости оскорбительно-оценочных суждений в одном из правил, использовать эти же самые оскорбительно-оценочные суждения (с совершенно эталонными исключениями для «начальников и людей, от которых вы материально зависимы»), иллюстрируя другое правило.
> pro.js.noobs — Чат про JavaScript (для новичков)
К сожалению, овнер этого и других pro.чатов больше не выходит с остальными админами на связь, поэтому мы решили пересоздать его. Чат называется JavaScript Noobs и расположен по адресу t.me/js_noobs_ru
Это был бы очень остроумный комментарий, если бы не тот факт, что разработка ATM была анонсирована на VC за полгода до публикации ролика этих чудаков.
Так почему зарёкся-то, раз всё вернули?