Комментарии 5
Желание автоматизировать рутинные проверки, как и готовность контрибьютить в опенсорс - это прекрасно, рад, что вы решили поделиться своим решением с другими.
Не могу, однако, не отметить некоторые моменты, которые меня смутили:
Отдельное правило для обработки декоративных изображений — по спеке 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) плагине и попробовать законтрибьютить улучшения туда, так намного больше шансов, что люди этим воспользуются. Готов посодействовать в этом, если есть интерес.
Спасибо большое за вдумчивый и доброжелательный комментарий! Очень приятно получить такой фидбэк — особенно по теме, где действительно важно внимание к деталям.
По поводу alt и role="presentation" — да, вы правы: по спецификации пустой alt — предпочтительный способ скрыть изображение из дерева доступности. В моём правиле это поведение поддерживается, и, скорее всего, я ещё улучшу формулировки и описание в документации, чтобы избежать недопонимания. Основная цель — подсветить ситуации, когда <img> вообще без alt, что до сих пор довольно часто встречается в коде.
Насчёт aria-labelledby — полностью согласна, что линтер не всесилен. Но он может помочь в простых и частых случаях, когда нужный id должен быть в пределах одного компонента. Такие локальные ошибки легко пропускаются, особенно в переиспользуемых шаблонах — и в этом смысле правило скорее страховка, чем универсальное решение.
Что касается идеи внести что-то в jsx-a11y — очень откликается. Я изначально хотела пройти путь “от и до”, чтобы разобраться, как всё устроено внутри: AST, RuleTester, публикация. Но теперь, когда получилось, я как раз думаю, куда двигаться дальше — и возможность внести что-то в существующий инструмент звучит отлично. Спасибо за предложение помощи — обязательно обращусь, если решусь!
В исходном плагине есть маппинг своих компонентов и атрибутов на нативные, т.е. можно ему сказать, что MyButton это button
Спасибо за комментарий! Да, про возможность маппинга кастомных компонентов в jsx-a11y я знаю — это действительно полезная фича, и здорово, что она есть.
При помощи settings.jsx-a11y.components можно явно указать, что, например, MyButton — это button, и тогда плагин начнёт применять к нему соответствующие правила. Но у этого подхода есть пара ограничений, которые мне хотелось бы закрыть по-другому.
Во-первых, не всегда удобно прописывать маппинг вручную для десятков компонентов — особенно если проект активно развивается или дизайн-система не финализирована. Во-вторых, хочется больше гибкости и возможности писать правила под свой UI-контекст, включая, например, локализацию (t('...')) или поведение (tabIndex, onKeyDown), а не только семантику.
Так что моя цель — не заменить jsx-a11y, а скорее дополнить его там, где он хорош как основа, но не покрывает специфику конкретного продукта. И если получится, чтобы оба плагина работали рядом — это будет только плюсом.
Cringe
Всё, что можно автоматизировать, должно быть автоматизировано. Даже aria-label