Изучаю доступность

Про верстку я тоже забывать не хочу. Оттачиваю и улучшаю свои скиллы на заказах или на проектах в портфолио. А ещё глубже изучаю разные темы, например, доступность.

Вот недавно прочитала статью про доступность в таблицах и вынесла от туда следующие полезности, которые буду стараться применять на практике:

1️⃣ С помощью тега caption можно добавлять заголовок к таблице

2️⃣ Для более сложных структур можно использовать теги thead, tfoot и tbody (tbody браузер создает всегда сам). Эти теги не помогают в доступности, но могут пригодиться при стилизации

3️⃣ Для ячеек, которые являются заголовками можно использовать атрибут scope. Он сообщает скринридеру какие ячейки точно являются заголовками — например, заголовок строки в которой он находится или столбца.

Лекции на ютубе тоже не игнорирую. Посмотрела доклад Вадима Макеева «Людоедский интерфейс», уже давно рекомендовали мне эту лекцию, но все уши не доходили). Неправильные правила по доступности — тоже шикарное видео от Вадима. Ещё понравилась лекция по тестированию Accessibility от Ольги

И рискнула я начать читать документацию про ARIA на английском! На русском вообще мало информации по доступности, а так ещё и английский прокачаю

#верстка #доступность #теория

Формы

Есть ещё одна тема, которая немного связана с доступностью — формы. Как правильно написать разметку в формах, чтобы пользователь скрин ридера понял, что от него хотят, а бекендерам было удобно работать с твоим кодом?

Я стала копать в эту сторону. Посмотрела пару видео, почитала несколько статей. И вот какие выводы для себя сделала.

1️⃣ С чекбоксами и радиокнопками нужно использовать атрибуты name и value. Тогда на сервер данные придут в таком формате. { “name” : “value” }. Стоит отметить, что у радиокнопок, которые относятся к одной группе должно быть одинаковое значение атриубута name. И этот формат сильно упростит жизнь бекенд разработчикам

2️⃣ Для группирования полей форм можно использовать тег fieldset, а чтобы озаглавить эту группу — тег legend. Думаю, что эти теги стоит использовать, даже если их нет в дизайне. С их помощью люди люди со скрин ридерами будут лучше понимать вашу структуру. И для семантики лишним тоже не будет

3️⃣ Мое правило, которому я следую очень давно — всегда использовать тег label. Если он не предусмотрен в дизайне, то его можно скрыть с помощью класса sr-only или visually-hidden, ведь есть ситуации, когда без него пользователь с ограниченными возможностями не поймет, что это за поле ввода и что туда нужно ввести. А если дизайн предполагает наличие такой «подсказки», то точно нужно использовать label. а не какой-нибудь там span или div, в таком случае это добавит удобства всем пользователям

#теория #доступность

Работа над крупным интернет-магазином

Хочу рассказать вам про работу и про проекты, но для этого нужно вернуться немного назад. Есть у вас машина времени?)

В июле мне написал один человек и предложил в работу проект. Я его выполнила в кратчайшие сроки (так как они горели) и за достаточно небольшой бюджет. Правок почти не было и, наверное, заказчика устроило качество выполненный работы, так как через пару дней он вернулся ко мне с ещё одним проектом. Как оказалось, это не совсем заказчик, а скорее посредник, но это не так важно, главное, что есть работа 😄 после второго проекта мне нужно было уехать на пару недель

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

Изначально нужно было исправииь три страницы: главная, каталог, страница товара и сдать их бекендерам (бек на Битриксе). Но исправить — это мягко сказано, мне пришлось полностью все переделывать (и не зря, как оказалось позже). Однако некоторые решения в коде были достаточно интересными и я переписала их на свой лад, ещё мне понравилась сборка — gulp + webpack, это подтолкнуло меня обновить свою текущую сборку

Макет не был полностью готов. Отсутствовали меню, выпадашки, модалки. Сам дизайн не подготовлен к вёрстке: дробные значения в размерах элементах и шрифтах, куча разных отступов и стилей. К дизайнеру накопился ряд вопросов, а он через пару дней просто перестал выходить на связь 🤦‍♀️

Когда главная страница была переделана, то мы стали показывать её заказчику. Тот сказал, что все слишком огромное и надо уменьшить раза в 2-3 все элементы. А я вот стесняюсь спросить, где же он был, когда принимал дизайн? Как он принял контенйер в 1700px и обычный шрифт в 24px?

Переделывать дизайн уже не было времени. Поэтому я стала вносить изменения прямо в вёрстку. Многое пришлось переделывать по третьему разу, но удалось уменьшить контейнер до 1300px

С такими мучениями нам удалось сдать эти три страницы. Сроки горят, дизайн кривой, заказчик с причудами, но продолжение следует...

#работа #верстка

Навигация

#инкубатор
#работа
#верстка
#дизайн
#теория
#книги

Темы:

#паттерны
#иммутабельность
#инструменты
#доступность
#цвет
#принципы
#архитектура
#fsd
#лексическоеОкружение
#замыкание
#this
#промисы
#оптимизация
#карты
#redux
#ts

Работа над крупным интернет-магазином продолжается

Через несколько дней к нам в команду добавили нового дизайнера, то есть дизайнершу. И она стала работать над остальными страницами, которых было ещё около 10-12

Тем временем я раз пять переделывала главную, каталог и страницу товара, так как заказчику не нравилось то, что он сам утвердил на этапе дизайна.

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

Теперь работа прилетала с их стороны. В основном требовалось внести изменения под битрикс. Где-то добавить новый скрипт, где-то обработать отправку формы и тому подобное

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

--------------

Теперь хочу рассказать о некоторых сложностях, с которыми столкнулась на этапе вёрстки

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

Сами линии делала через svg тег, но это было не совсем корректным решением. Так как для каждого плюсика пришлось рисовать отдельную линию, подгонять её пиксель в пиксель (не забываем, что я уменьшала контейнер на 400px и все элементы соответственно) и копировать её svg код, а затем добавлять тоже в html

Сейчас я бы старалась это реализовать через canvas в javascript, но тогда я ещё не прочитала об этом в книге Javascript для детей))

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

#работа #верстка

Теперь чуть-чуть вернемся назад, чтобы я могла вам рассказать про продолжение верстки крупного-интернет магазина

Через недельку - две завершилась работа над дизайном оставшихся страниц (напомню, их 10-15, вот те, что я вспомнила: история, о компании, контакты, сервис, доставка, сборка, установка). Теперь настала моя очередь

Я решила верстать их на своей новой сборке (пост про неё) С одной стороны, это хороший выбор, если бы я продолжила работать с таким объемом страниц на старой сборке от другого верстальщика, то я бы с ума сошла. Все же моя сборка лучше приспособлена для больших сайтов.

С другой стороны, я очень боялась, что потом будут конфликты, так как одна часть сайта сделана на одной сборке, а другая — на другой. И новую сборку я использую первый раз, поэтому при работе приходилось её ещё дорабатывать, модернизировать и фиксить некоторые баги

С работой я справилась дней за 10. Сейчас хочу рассказать о сложностях, с которыми столкнулась

1️⃣ «Аналог плюсиков». Естественно, я делала с учетом на то, что заказчик сможет менять количество и расположение этих кнопок, почти тоже самое, что и с плюсами (читайте в этом посте).

Дизайнер почему-то нарисовала все кнопки слишком огромными и разного размера. А ещё не будем забывать, что в верстке контейнер на 300px меньше. То есть мне нужно было разместить все таким образом, чтобы оно не наезжало друг на друга, смотрелось не слишком огромным и был соблюден масштаб

А при сдаче этой страницы заказчик стал возмущаться, что блок не помещается в экран (в этом блоке ещё есть текст над фото, который не попал на скрин). А как можно уместить текст и фото в одном экране, когда даже одно изображение еле-еле помещается. Но в дизайне же это тоже видно! Почему нужно было ждать верстку, чтобы сообщить об этом?!

2️⃣ Блок с главными датами. И сразу же вспоминаем про контейнер. К сожалению, этот блок у меня не получилось сделать гибким. То есть если количество строк текста будет разным, то все начнет ломаться. Но зато у меня получилось нормально его адаптировать. Как считаете, его действительно нельзя сделать динамичным или я не нашла подходящего способа?

3️⃣ Форма с прикреплением файла. Долго искала плагин, который позволит нормально застилизовать это инпут. Нашла, подключила, застилизовала... Оказалось, что на битрексе для этой задачи есть специальный модуль и нужно просто под некоторые классы написать стили

4️⃣ Бегущая строка. Тоже много времени потратила на писки решения. Зато найденное решение добавила в шаблон в сборке и теперь на подключение уйдет минут 5)

#работа #верстка

Сегодня хочу рассказать об очень важной концепции в js

В javascript все виды данных делятся на две большие категории: примитивный тип данных и ссылочный

Пример примитивных данных: числа, строки, булевое значение. С ними все просто, особо никаких тонкостей при работе с ним нет

А вот с ссылочным типом все интереснее. Суда относятся объекты (а ещё функции и массивы, так как они тоже объекты). Переменная, содержащая ссылочный тип, фактически его значения не содержит. Она содержит ссылку на место в памяти, где размещаются реальные данные

Давайте создадим две переменные, которым присвоим одинаковое значение примитивного типа данных

const example = 5
const example2 = 5

Как вы думаете, переменная example и example2 равны? Правильный ответ: да! Вы можете проверить это самостоятельно

А теперь давайте проведем подобный эксперимент с ссылочным типом данных

const example = {}
const example2 = {}

А сейчас равны ли эти переменные? Правильный ответ: нет. Почему? Потому что переменная example это ссылка на объект в памяти.. example2 это тоже ссылка на объект в памяти, но уже на другой объект

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

Предлагаю провести ещё один эксперимент. Создадим переменную simple и присвоим ей примитив (к примеру 5), создадим ещё одну переменную — simple2 и присвоим ей simple. Simple и simple2 равны между собой и в этих переменных хранится 5. Давайте изменим значение переменной simple2 (к примеру на 10)

let simple = 5
let simple2 = simple
simple2 = 10

Чему равна переменная simple сейчас? Правильный ответ: 5

А теперь сделаем тоже самое, но с ссылочным типом данных. Переменной obj присвоим пустой объект, а переменной obj2 присвоим obj

let obj = {}
let obj2 = obj

Теперь давайте объекту, на который ссылается obj2 добавим свойство

obj2.name = "Anna"

Как вы думаете, что сейчас находится в переменой obj? Правильный ответ: {name: "Anna"}

Почему так произошло? Потому что obj это ссылка, которая ссылается на объект в памяти (ключ для шкафчика). Переменой obj2 мы присваиваем эту же ссылку (точно такой же ключ). И получается, что через две эти переменные мы обращаемся к одному и тому же объекту (это одинаковые ключи от одного шкафчика)

#теория #иммутабельность

Четыре принципа веб-доступности (POUR)

В этом посте я рассказывала о том, что активно начала интересоваться темой доступности

И недавно я нашла супер полезный ресурс по этой теме — дока. Прочитала первую статью, в которой рассказывается о четырех принципах доступности. Мне стало интересно и я нашла ещё несколько статей на эту же тему. Почти все статьи были на английском языке, я уже давно заметила, что в СНГ многим наплевать на удобство пользователей…

Ладно, не будем о грустном. Давайте лучше расскажу об этих принципах

POUR — аббревиатура от четырёх принципов, на которые опирается веб-доступность. Они описывают, какими должны быть веб-интерфейсы, их отдельные элементы и контент

1️⃣ Воспринимаемость (perceivable) — интерфейс можно воспринимать разными органами чувств, например глазами и ушами. То есть если на сайте есть какой-то аудио файл, то было бы замечательно добавить к нему текстовое описание. Если у пользователя будет отит, то он сможет усвоить информацию через зрение, а не напрягать свое пострадавшее ухо

2️⃣ Управляемость (operable) — с интерфейсом можно взаимодействовать разными способами, например, с помощью мышки и клавиатуры. У пользователя может сломаться мышка, и у него должна быть возможность заказать новую мышку с помоom. клавиатуры (телефон он потерял). Поэтому прорабатывайте состояние фокуса для кликабельных элементов или хотя бы не отключайте outline 😠

3️⃣ Понятность (understandable) — интерфейс понятен для взаимодействия, пользователю должно быть интуитивно понятно, как совершить то или иное действие на сайте (как оставить заявку, как добавить товар в корзину и т.п). Тоже самое можно сказать и о контенте. Не надо писать слишком сложный и запутанный текст, использовать профессиональные термины. Пользователю должно быть все максимально понятно

4️⃣ Устойчивость (robust) — интерфейс соответствует техническим спецификациям и работает на разных устройствах, в разных браузерах и с разными вспомогательными технологиями

#теория #доступность

Пожалуй, это последний пост по теме верстки крупого интернет-магазина

В одном из прошлых постов писала, о верстке оставшихся страниц. Хочу сказать, что эту работу приняли без особых сложностей

Но проект мы ещё не сдали. Нам предстояла работа над меню и, наверное, это была одна из самых сложных частей при создание данного сайта. Изначально заказчик хотел три совершенно разных выпадающих меню: одно для каталога, а два других — подменю для пунктов основного меню (и это не обычная выпадашка, а полноценное меню на всю ширину сайта, внутри которого табы!). Повторюсь, он хотел, чтобы они были абсолютно разные! Кроме того, дизайнер сделала так, что на десктопе — одно выпадающее меню, а на планшете и смартфоне — другое! То есть адаптировать их никак нельзя, только верстать отдельное меню под мобильную версию. И получается, что всего должно быть 6 разных меню…

К счастью, нам удалось уговорить заказчика сделать одинаковые по стилю подменю для пунктов основного меню. Ещё долго времени я потратила на работу с js кодом, хотела сделать так, чтобы такое выпадающее меню можно было добавить к любому пункту. Можно сказать, что у меня это удалось. Но потратила я на это часов 10-12

Дальше заказчик захотел немного переделать первый экран и добавить туда слайдер, а каждый слайд должен быть уникальным. Обычно слайды одинаковые по структуре, например, справа текст, а слева картинка. Меняется слайд — меняется текст и картинка, но структура остается. А тут нет, такая легкотня его не устраивала… Кроме того, клиент моментально принял дизайн, но раз пять приходилось переделывать верстку: менять размер всех элеметов и отступы между ними

Ещё добавляли несколько модальных окон и валидацию форм. Это не так сложно, но если бы заказчик об этом сказал заранее, а не в конце работы, то мне было бы проще

На этом я завершу серию постов по данному проекту. Ещё были дополнительные работы, были странности заказчика, но все это не так интересно. Хотя… давайте я напишу ещё один пост, в котором расскажу о тех выводах, что сделала для себя при данной работе

#работа #верстка

В одном из предыдущих постов закончила рассказывать про рабочий проект, верстку большого интернет-магазина. Сегодня, как и обещала, хочу поделиться некоторыми выводами, которые сделала за время работы и которых буду стараться придерживаться в дальнейшем

1️⃣ Сразу делать на совесть. Нужно всегда рассчитывать на то, что проект может масштабироваться и изменяться. Нельзя делать по принципу «и так сойдет». Нужно писать гибкий и понятный код. Нужно быть готовым к тому, что через неделю заказчик захочет добавить такой-то блок на все страницы, а этот блок переиспользовать на другой. А тут добавить вот это, а там убрать вот то

2️⃣ Рассказать заказчику, как правильно утверждать дизайн. Чтобы он смотрел на макет в 100% масштабе!!! Постараться донести ему, что вносить изменения в фигме проще и быстрее, чем в верстке. Если макет уже будет сверстан, а ему придется в голову шикарная идея — поменять дизайн, то это будут дополнительные работы, за которые придется дополнительно платить. Так как с дизайном работают на этапе дизайна, а не на этапе верстки

3️⃣ Мне, как верстальщику, нужно внимательнее смотреть макет, анализировать его. Заранее подмечать те блоки, которые переиспользуются и те блоки, что могут переиспольоваться. Уже на этом этапе продумывать, что и как лучше сделать

4️⃣ Не бояться задавать вопросы. Лучше обсудить все берегу, чем отправиться в плавание и понять, что ты плывешь куда-то не туда. Не бояться общаться с коллегами: верстальщиками, дизайнерами, бекенд разработчиками. Всегда думать о следующем этапе в создание сайта, подумать, как тебе лучше сделать этот блок, чтобы следующим ребятам было с ним работать, и опять же, не бояться обсуждать такие моменты с коллегами. Лучше задолбать их вопросами, чем задолбать их своим кривым кодом)

#работа

Вспомогательные технологии

Из предыдущего поста про доступность мы пришли к выводу, что сайтами и приложениями пользуются разные люди. Но одни люди делают это самостоятельно, а другим нужны вспомогательные технологии

Вспомогательные технологии (assistive technology) — это программы, которые упрощают взаимодействие пользователя с контентом. К примеру, выносные кнопки, трекболы, брайлевские дисплеи, экранные лупы и скринридеры

Скринридер (screen reader) — программа, которая превращает контент в речь. Они нужны людям с плохим зрением, а также пользователям с когнитивными особенностями, которым легче воспринимать информацию на слух

Ещё одна вспомогательная технология — экранная лупа (screen magnification). Частенько слабовидящие пользователи используют её вместе со скринридерами. Она увеличивает контент на экране и тоже его озвучивает, если это нужно

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

#доступность #теория

Как работают скринридеры

В одном из предыдущих постов мы с вами разбирали вспомогательные технологии. И договорились, что особое внимание будем уделять скринридеам. Напомню, что скринридер — это специальная программа, которая зачитывает контент с сайта

В этом посте хочу разобрать принцип работы этих программ

Скринридеры не берут контент из вкладки браузера. Существует Accessibility API — это посредник, который берет информацию из браузера и передает её скринридерам, не не просто передает, а делает это в виде дерева доступности

Ещё accessibiliry api получает от браузеров сообщения о событиях на странице, обрабатывает их и помогает скринридерам реагировать на них (выбор чекбокса или радиокнопки, открытие / закрытие модального окна, информация об ошибке и прочее). Небольшая загвоздка заключается в том, что браузеры могут работать с разными accessibiliry api, которые в свою очередь могут отличаться в передаче и обработке информации, поэтому скринридеры на разных операционных системах и в разных браузерах могут работать по-разному, это необходимо учитывать при разработке и тестирование

Пару слов о дереве доступности. Оно очень похоже на DOM, но состоит из доступных объектов и не включает в себя скрытые элементы (с display: none или visibility: hidden)

Доступной объект дерева доступности состоит из следующих свойств:

✅ role. Соответствует типу элемента, например, button или link

✅ name. Помогает лучше понять, что это за объект. Имя — это текст между открывающимся и закрывающимся html тегом, поэтому оно есть не всегда

✅ description. Дополнение к имени. Озвучивается, если выбрана такая настройка в скринридере.

Источник

#доступность #теория

Куки

Куки — это маленькие текстовые файлики, которые хранятся в браузере и для каждого сайта свой файлик. В таком файле информация хранится в формате ключ — значение, значение может быть зашифровано, а шифр знает только сервер.

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

Раньше куки часто использовались для хранения рекламных предпочтений пользователя, но если не ошибаюсь, то это сейчас не приветствуется. С появлением localStorage, о котором мы обязательно поговорим в одном из следующих постов, куки стали отходить на второй план, но совсем они не исчезли

В настоящее время самое частое применение куков — регистрация и авторизация. Например, когда человек хочет попасть в вк, то в поисковой строке он пишет адрес, а это своего рода get запрос на сервер и вместе с ним отправляется кука. Если в куке хранится информация о том, что пользователь авторизован, то его перебрасывает на страницу «новости», а если такой информации нет, то предлагают авторизоваться или зарегистрироваться

#теория