Случаи, действительно, бывают разные. На гитлабе, например, очень сложно комментировать код в merge request. Там кнопка комментария появляется только на фокус мышки. Сначала я вообще сделал кастомный js-скрипт, открывающий все подобные кнопки на странице. Но сейчас приноровился с помощью специальных фокусов скринридера наводиться на строку и приводить горячей клавишей туда фокус мышки. Так что у незрячих порой есть особые инструменты даже на такие запущенные случаи. :)
Постараюсь осветить эти вопросы во второй части. Если кратко, то бекенд доступен весь. На фронте тоже можно многое сделать, но для визуальных вещей нужен зрячий рядом.
Под каждой формой как правило есть кнопка «Отправить».
Насильно спрятанные outline
Это про css? Большая контрастность может помочь слабовидящим, но скринридер эти стили не озвучивает.
не указанные tab-index'ы
Придется перемещаться между полями ввода стрелочками. Обычно текстовые метки у них какие-нибудь все равно есть.
текстовые поля которые ими не являются (задизайненые div'ы)
Не знаю, насколько часто такие вещи реально встречаются, но вот когда поля форм плохо доступны, это чувствуется сразу. На хабр-карьере, кстати, самые ужасные формы, которые я встречал.
И по моему опыту сайты которыми я не могу пользоваться без мышки составляют 1/3 рунета… или даже больше...
Не все так плохо. На целом ряде сайтов есть труднодоступные элементы, но их обычно можно обойти. А вот когда десктопное или мобильное приложение толком не озвучивается, тут уж ничего не попишешь.
Да чего далеко ходить. Тот же вконтакте без мышки не юзабелен.
Вроде бы кто-то приноравливается и к нему. Но проще использовать m.vk.com. Он очень удобен.
Лично я когда делаю что-то на фронте, не парюсь особо о доступности. Но всегда делаю так что бы этим можно было пользоваться клавиатурой.
Это хорошо. В целом же нативные элементы, подписанные элементы управления, удобно расставленные заголовки — по моему субъективному мнению все, что нужно для хорошей доступности.
У того парня прям, да, синтезатор быстро работает. Я же привык уже к более человечным голосам и не на такой высокой скорости. Так что тут все индивидуально.
А в чем проблема? Смартфоны сейчас есть практически у всех. А у кого нет — пусть по-старинке по паролю заходят. Но остальные смогли бы обойтись вовсе без него, подтверждая, что это реально они с помощью своего смартфона. Это ведь удобно? Что-то похожее уже существует, когда вместо смс-кодов приложения просто просит нажать кнопку во всплывающем на привязанном устройстве окне.
Кроме того, в ситуации, когда контракт вам известен заранее, вы можете сразу написать все тесты, а потом уже весь код, который им соответствует. Формально, это будет не TDD, вы не будете менять код после добавления каждого теста.
У того же Бека много раз упоминается, что описываемые в книге микрошаги — лишь способ детально показать новичкам саму концепцию и общий ход мыслей. При этом длину шагов красный — зеленый — рефакторинг каждый определяет сам, исходя из своих потребностей. Но в случае возникновения серьезных трудностей всегда можно вернуться к практике микрошагов.
Лично я очень люблю tdd, т.к. при таком подходе тесты реально становятся опорой разработки. Они подскажут архитектуру, контракты, практически гарантируют, что каждый отдельный модуль делает то, для чего он предназначен. Что в совокупности с небольшим количеством функциональных тестов дает очень хорошую надежность, а следовательно уверенность.
Лично у меня бывали случаи, когда я был уверен, что тест будет красным, а он почему-то проходил. Не все вы можете полностью контролировать. Иногда в ритуалах все-таки есть смысл.
Забавно, я в полной мере согласился бы только с 3 пунктом. Правильные заголовки действительно очень помогают при навигации. А по остальным…
1. Это по-моему вообще слабо относится к скринридерам. По плохо подписанной кнопке или ссылке вроде бы всем сложно будет навигировать. Тут чаще проблема в другом — когда кнопку или ссылку делают не используя соответствующие теги html, заменяя их css и js. Вот тогда, да, скринридер их вообще не распознает и объявит, как обычный текст.
2. По-моему вообще не надо тратить время на атрибуты alt, если это не графическое отображение какого-нибудь элемента взаимодействия (кнопки, ссылки, галочки вкл/выкл и т.д.). Например, на одном из моих проектов статусы заявок выводились картинками. Вот тут, да, тег alt обязателен. А во всяких статьях, новостях и т.д — нет. Во-первых тот же google chrome самостоятельно распознает текст на картинках, к тому же их можно прогнать через специальные сервисы где ии их вполне адекватно опишет. Не хуже, чем это будет сделано в alt.
4. С плохо доступными формами сталкиваюсь редко. И чаще вопрос тут в навешанных на них js действиях, меняющих содержимое страницы на onChange onKeyUp и т.д. Что выкидывает с них фокус скринридера. Капчи сейчас вполне нормально решаются через специальные сервисы. Да, иногда приходится обращаться ко зрячим, но очень редко.
5. Это для всех неприятно, но для незрячих — несмертельно. В конце концов можно во вкладке звук отключить.
Спасибо, было очень интересно! Помню, как на первых курсах ВУЗа меня тоже смущали неправдоподобные экономические люди с бесконечной рациональностью и неограниченными потребностями. Но потом я лучше понял эту модель и какие-то ее части стал воспринимать, как метафору.
Мне в статье разве что не хватило примеров того, как изменившееся понимание поведения человека при совершении экономических действий повлияло на науку в целом. Что-то ведь изменилось? Оценка происходящих событий, прогнозы и т.д.
менеджер принимает удар вышестоящего начальства на себя, вместо того, чтобы разделить его с виновниками происходящего.
А мне казалось, что в такой ситуации как раз менеджер и должен принимать удар от вышестоящих, а потом уже самостоятельно «перетирать» с тем, кому он делегировал полномочия. Разве нет?
Прогон функциональных тестов может занимать немало времени. Например, полный прогон набора из 77 тестов и 524 предположений может занять 3-4 минут.
Только вот зачем прогонять полный набор функциональных тестов локально. Для этого есть ci. А с phpunit можно и по одному нужные во время разработки тесты запускать.
Я обнаружил, что прекрасный способ очистки БД — загрузить пустые фикстуры в особый метод setUp в PHPUnit.
Есть куда более практичный способ. Пакет dama/doctrine-test-bundle предоставляет удобный апи для оборачивания тестов в бд транзакцию. Которую после его выполнения откатывается. Просто, быстро, удобно. Чаще всего даже отдельная бд для тестов не нужна.
Этого достигли с помощью многочисленных функциональных тестов Symfony и некоторых модульных тестов, которые заполнили некоторые пустоты.
Тоже был такой опыт на нескольких проектах. Это и правда хорошо работает. Но на текущем мы используем tdd. И это работает еще лучше. Вопрос, по сути, лишь в том, как много заказчик готов платить за тесты. Если мало — можно ограничиться функциональными. А если надежность системы для него важнее — можно и нормальную пирамиду тестирования наладить.
Привет, menelion_elensule! Приятно видеть знакомый по тифлокомповским рассылкам ник на хабре. :) Очень рад, что у тебя все успешно развивается! Дальнейших целей и их достижения!
У меня, кстати, конкретно из-за того, что я незрячий, не сильно много вакансий срывается. Я даже не всегда говорю, что совсем не вижу. Просто в общем указываю на то, что я бекенд разработчик и с css из-за проблем со зрением не дружу. Мой текущий менеджер, по-моему, даже не знает, что я тотально незрячий. Хотя я там работаю уже несколько месяцев и ничего не скрываю. Просто даже повода говорить об этом не было. А что, задачи я делаю, МР-ки создаю, code review провожу, а большего мы и не обсуждаем.
P.S. Про радость от перехода конференций в онлайн очень точно подмечено. :)
Поправьте, если ошибаюьс. Но php ведь не позволяет из коробки использовать асинхронность? Этого и не хватает. Также хотелось бы услышать размышления об этой проблематике в общем от разработчиков ядра и план продвижения в этом направлении. Когда в php появятся стандартные инструменты и подходы работы с асинхронностью, тогда уже и можно будет говорить об экосистеме.
С интересом прочитал виденье Никиты Попова по развитию php без слома обратной совместимости. Интересно, есть ли что-нибудь подобное от основных разработчиков ядра php по вопросам асинхронности? Вроде бы тема очень актуальная и дискуссионная, но вот взгляд на эту проблему основных разработчиков php сходу найти не получилось.
Под каждой формой как правило есть кнопка «Отправить».
Это про css? Большая контрастность может помочь слабовидящим, но скринридер эти стили не озвучивает.
Придется перемещаться между полями ввода стрелочками. Обычно текстовые метки у них какие-нибудь все равно есть.
Не знаю, насколько часто такие вещи реально встречаются, но вот когда поля форм плохо доступны, это чувствуется сразу. На хабр-карьере, кстати, самые ужасные формы, которые я встречал.
Не все так плохо. На целом ряде сайтов есть труднодоступные элементы, но их обычно можно обойти. А вот когда десктопное или мобильное приложение толком не озвучивается, тут уж ничего не попишешь.
Вроде бы кто-то приноравливается и к нему. Но проще использовать m.vk.com. Он очень удобен.
Это хорошо. В целом же нативные элементы, подписанные элементы управления, удобно расставленные заголовки — по моему субъективному мнению все, что нужно для хорошей доступности.
У того же Бека много раз упоминается, что описываемые в книге микрошаги — лишь способ детально показать новичкам саму концепцию и общий ход мыслей. При этом длину шагов красный — зеленый — рефакторинг каждый определяет сам, исходя из своих потребностей. Но в случае возникновения серьезных трудностей всегда можно вернуться к практике микрошагов.
Лично я очень люблю tdd, т.к. при таком подходе тесты реально становятся опорой разработки. Они подскажут архитектуру, контракты, практически гарантируют, что каждый отдельный модуль делает то, для чего он предназначен. Что в совокупности с небольшим количеством функциональных тестов дает очень хорошую надежность, а следовательно уверенность.
1. Это по-моему вообще слабо относится к скринридерам. По плохо подписанной кнопке или ссылке вроде бы всем сложно будет навигировать. Тут чаще проблема в другом — когда кнопку или ссылку делают не используя соответствующие теги html, заменяя их css и js. Вот тогда, да, скринридер их вообще не распознает и объявит, как обычный текст.
2. По-моему вообще не надо тратить время на атрибуты alt, если это не графическое отображение какого-нибудь элемента взаимодействия (кнопки, ссылки, галочки вкл/выкл и т.д.). Например, на одном из моих проектов статусы заявок выводились картинками. Вот тут, да, тег alt обязателен. А во всяких статьях, новостях и т.д — нет. Во-первых тот же google chrome самостоятельно распознает текст на картинках, к тому же их можно прогнать через специальные сервисы где ии их вполне адекватно опишет. Не хуже, чем это будет сделано в alt.
4. С плохо доступными формами сталкиваюсь редко. И чаще вопрос тут в навешанных на них js действиях, меняющих содержимое страницы на onChange onKeyUp и т.д. Что выкидывает с них фокус скринридера. Капчи сейчас вполне нормально решаются через специальные сервисы. Да, иногда приходится обращаться ко зрячим, но очень редко.
5. Это для всех неприятно, но для незрячих — несмертельно. В конце концов можно во вкладке звук отключить.
Мне в статье разве что не хватило примеров того, как изменившееся понимание поведения человека при совершении экономических действий повлияло на науку в целом. Что-то ведь изменилось? Оценка происходящих событий, прогнозы и т.д.
А мне казалось, что в такой ситуации как раз менеджер и должен принимать удар от вышестоящих, а потом уже самостоятельно «перетирать» с тем, кому он делегировал полномочия. Разве нет?
Только вот зачем прогонять полный набор функциональных тестов локально. Для этого есть ci. А с phpunit можно и по одному нужные во время разработки тесты запускать.
Есть куда более практичный способ. Пакет dama/doctrine-test-bundle предоставляет удобный апи для оборачивания тестов в бд транзакцию. Которую после его выполнения откатывается. Просто, быстро, удобно. Чаще всего даже отдельная бд для тестов не нужна.
Тоже был такой опыт на нескольких проектах. Это и правда хорошо работает. Но на текущем мы используем tdd. И это работает еще лучше. Вопрос, по сути, лишь в том, как много заказчик готов платить за тесты. Если мало — можно ограничиться функциональными. А если надежность системы для него важнее — можно и нормальную пирамиду тестирования наладить.
У меня, кстати, конкретно из-за того, что я незрячий, не сильно много вакансий срывается. Я даже не всегда говорю, что совсем не вижу. Просто в общем указываю на то, что я бекенд разработчик и с css из-за проблем со зрением не дружу. Мой текущий менеджер, по-моему, даже не знает, что я тотально незрячий. Хотя я там работаю уже несколько месяцев и ничего не скрываю. Просто даже повода говорить об этом не было. А что, задачи я делаю, МР-ки создаю, code review провожу, а большего мы и не обсуждаем.
P.S. Про радость от перехода конференций в онлайн очень точно подмечено. :)
Если он работает, то почему не масштабируется? Я, например, ничего не слышал о регулярных операциях по имплантированию глаз или сетчаток.