Pull to refresh

Comments 13

Для textarea можно использовать resize: vertical, сохраняется возможность изменить размер и не ломает макет.
А вообще советы, как будто, из далёкого прошлого.

Последний вообще странный, вместо 3ёх пустых span будем использовать два вложенных span с текстом.

Тут больше про доступность. В предложенном варианте кнопка имеет синтаксический текст который будет обработан разными читалками.

Про картинки годно, действительно часто начинающие так делает, да и сам когда-то так делал, но остальное — очень странно.


Плейсхолдер вместо лейбла — это требование дизайна, не будет же кто-то долбиться с перекрытием слоев, когда у тебя подпись плейсхолдером и делать подпись поверх поля такое себе решение, тем более иных вариантов данного кейса я не придумаю.


Про ресайз уже писали, и вот мне лично непонятно что за предпочтения такие могут так сильно убить UX что это нужно было вынести отдельным пунктом ошибки. Я понимаю, что неудобно когда высота ограничивается там где текст может быть длинным, но ведь реально зачем городить пляски с высотой, когда специально для этого есть своё решение, кроме того, возможно ограничение высоты или ширины все равно придётся делать и это тогда пляски с вложенными элементами.


Лишний дисплей блок вообще никого не трогает. Понимаю, что это увеличивает размер файла, но это экономия на спичках.


Аутлайн — согласен, лучше так и делать, НО кроме разработчиков вообще мало кто использует клавиатуру для навигации, а разработчики — это зачастую не целевая аудитория. Ну а пример с гамбургером даже смысла комментировать нет — это вкусовщина, да непонятно, но если просто три спана заменить одним с классом и использовать псевдоэлементы — это более грамотное решение, чем ещё один вложенный спан, подпись также просто делается псевдоэлементом.

UFO just landed and posted this here
они размечают социальные иконки
Но браузер устанавливает значение блока по умолчанию.
Нет значения для свойства структуры
Если вам нужно отключить фокусировку по умолчанию, не забудьте сделать состояние альтернативной фокусировки.
После гуглопереводчика текст нужно обязательно вычитывать.
Использование атрибута placeholder вместо элемента label

А ничего, что это обуславливается дизайном, а не хотелаками верстака? Как бы наличие лейбла это прерогатива дизигна
Использование элемента img для разметки декоративной графики
Весьма спорная реализация. Я бы сделал через спрайт. Или base64 на крайний случай. А то получается недопример.

Если вопрос про доступность, то странные немного советы.
Если говорить про label то у него есть атрибут for. А в случае если его не нужно отображать, то добавляют дополнительный стиль sr-only, который выводит елеммент далеко за пределы экрана. И placeholder этому не помеха.
Картинки можно рамещать в верстке, если они не влияют, достаточно указать alt с пустым значением.
Фокус на все ссылки и контролы должен быть, это факт. При этом не важны есть стили или нет. Просто доступность по кнопке tab и shift+tab.

Если речь идёт про доступность, то никакие модификации со стилями не должны менять содержимое сайта, ибо пользователи могут подключать свои stylesheet.
Хороший способ протестировать доступность — это открыть в текстовом браузере
Я вас возможно расстрою, но любые модификации возможны, и кнопки из div делать можно и из ссылок, и любые капризы за ваши деньги.
Открываем WAI-ARIA Authoring Practices 1.1 или ARIA Landmarks Example

Да семантическая верстка рулит, но если у вас что-то не так, это не значит, что нельзя это исправить. И скорее даже не исправить, а доделать все что бы обеспечить доступность, дописать и заполнить атрибуты для ридеров, добавить компоненты и меню доступные только с клавиатуры и тд и тп.
Практика показвает, что использование нестандартных элементов приводит к такому объёму работ для обеспечения доступности, что, спасибо, лучше не надо.

Не совсем понятно, зачем вы прислали ссылку на Landmarks.
А aria — это в некотором смысле костыль. Даже если пройдёте по вашей ссылке, то увидите например
Unlike HTML input elements, ARIA roles do not cause browsers to provide keyboard behaviors or styling.


Я довольно долго занимался accessibility чтобы утверждать, что требования доступности предъявляют наивысшие требования к качеству и логичности/стандартности вёрстки.
И если у вас что-то не так, то есть шанс, что вы «попали», и придётся всё переделывать.
К примеру, у вас локализовано 5% текста. Теперь для обеспечения доступности вам надо локализовать всё ибо lang атрибут прикреплён ко всей странице целиком.

Более того кроме WCAG рекомендаций, есть ещё дополнительные, основанные на здравом смысле. Пользователи могут подключать свои стили и они имеют высший приоритет в браузерах. Найдите кастомные стили для слабозрячих, подключите. И если ваш сайт нормально отображается то да значит всё хорошо
С картинками в background — лучше так не делайте. Точнее какой-то философский смысл в этом есть, но, на практике, часто пригодиться прописывать для иконки hover и/или focus, а это плюс одна картинка, которую надо отрабатывать. И не дай боже делать это на гос.сайте или сайте крупной конторы. Потому что там будет "«версия для слабовидящих» — это ещё 3-5 иконок для каждой цветовой схемы…

Так что, в этом случае, все иконки лучше через svg, инлайно или через svg-спрайт вставлять. Либо вообще не верстать тк, иногда, проще вставить блок «поделиться», например, от Яндекса
Sign up to leave a comment.

Articles