Русский
Русский
English
Статистика
Реклама

Доступность

Из песочницы Делаем модальные окна для сайта. Заботимся об удобстве и доступности

18.09.2020 12:15:01 | Автор: admin

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


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


В итоге было задумано сделать собственное простое решение.



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


  • Arctic Modal,
  • jquery-modal,
  • iziModal,
  • Micromodal.js,
  • tingle.js,
  • Bootstrap Modal (из библиотеки Bootstrap) и др.

(в статье не рассматриваем решения на базе Frontend-фреймворков)


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


Что мы ждём от модальных окон? Отвечая на этот вопрос, я основывался на докладе Знакомьтесь, модальное окно Анны Селезнёвой, а так-же на относительно старой статье NikoX arcticModal jQuery-плагин для модальных окон.


Итак, чтобы нам хотелось видеть?


  • Окна должны открываться как можно быстрее, без тормозов браузера, с возможностью анимировать открытие и закрытие.
  • Под окном должен быть оверлей. Клик/тап по оверлею должен закрывать окно.
  • Страница под окном не должна прокручиваться.
  • Окон может быть несколько. Открытие одного определенного окна должно осуществляться кликом на любой элемент страницы с data-атрибутом, который мы выберем.
  • Окно может быть длинным прокручиваемым.
  • Желательно поработать над доступностью, а также с переносом фокуса внутрь окна и обратно.
  • Должно работать на IE11+

Дисклеймер: Прежде чем мы рассмотрим подробности, сразу дам ссылку на готовый код получившейся библиотеки (HystModal) на GitHub, а также ссылку на демо+документацию.


Начнём с разметки.


1. Разметка HTML и CSS


1.1. Каркас модальных окон


Как открыть окно быстро? Самое простое решение: разместить всю разметку модального окна сразу в HTML странице. Затем скрывать/показывать это окно при помощи переключения классов CSS.


Набросаем такую разметку HTML (я назвал этот скрипт hystmodal):


<div class="hystmodal" id="myModal">    <div class="hystmodal__window">        <button data-hystclose class="hystmodal__close">Close</button>          Текст модального окошка.        <img src="img/photo.jpg" alt="Изображение в окне" />    </div></div>

Итак, разместим перед закрывающим тегом </body> наш блок с окном (.hystmodal). Он будет фоном. Удобно указать уникальный атрибут id (например #myModal) каждому окну (ведь их у нас может быть несколько).


Сделаем так, чтобы .hystmodal растягивался на всё окно браузера и закрывал собой содержимое страницы. Чтобы этого добиться, установим фиксированное позиционирование в CSS и приравняем свойства top, bottom, left и right к нулю.


.hystmodal {    position: fixed;    top: 0;    bottom: 0;    right: 0;    left: 0;    overflow: hidden;    overflow-y: auto;    -webkit-overflow-scrolling: touch;    display: flex;    flex-flow: column nowrap;    justify-content: center; /* см. ниже */    align-items: center;    z-index: 99;    /* Чтобы окно не прилипало к границе    браузера установим отступы */    padding:30px 0;}

В этом коде сделаны ещё две вещи:


  1. Так как мы хотим центрировать окно внутри страницы, превращаем .hystmodal в flex-контейнер с выравниваем его потомков по центру по вертикали и горизонтали.
  2. Окно может быть больше высоты экрана браузера, поэтому мы устанавливаем overflow-y: auto, чтобы при переполнении возникала полоса прокрутки. Также, для сенсорных экранов (в основном для Safari) нам стоит установить свойство -webkit-overflow-scrolling: touch, чтобы сенсорная прокрутка работала именно на этом блоке а не на странице.

Теперь установим стили для самого окна.


.hystmodal__window {    background: #fff;    /* Установим по умолчанию ширину 600px    но она будет не больше ширины браузера */    width: 600px;    max-width: 100%;    /* Заготовка для будущих анимаций */    transition: transform 0.15s ease 0s, opacity 0.15s ease 0s;    transform: scale(1);}

Кажется возникли сложности.


Проблема 1. Если высота окна больше высоты окна браузера, то контент окна будет обрезан сверху.



Это возникает из-за свойства justify-content: center. Оно позволяет нам удобно выровнять потомков по основной оси (по вертикали), но если потомок становится больше родителя то часть его становится недоступной даже при прокручиваемом контейнере. Подробнее можно посмотреть на stackoverflow. Решение установить justify-content: flex-start, а потомку установить margin:auto. Это выровняет его по центру.


Проблема 2. В ie-11 если высота окна больше высоты окна браузера, то фон окна обрезается.


Решение: мы можем установить flex-shrink:0 потомку тогда обрезки не происходит.


Проблема 3. В браузерах кроме Chrome нет отступа от нижней границы окна (т.е. padding-bottom не сработал).


Сложно сказать баг это браузеров или наоборот соответствует спецификации, но решения два:


  • установить псевдоэлемент ::after после потомка и дать ему высоту вместо padding
  • обернуть элемент в дополнительный блок и дать отступы уже ему.

Воспользуемся вторым методом. Добавим обертку .hystmodal__wrap. Так мы заодно обойдём и проблему 1, а вместо padding у родителя установим margin-top и margin-top у самого .hystmodal__window.


Наш итоговый html:


<div class="hystmodal" id="myModal" aria-hidden="true" >    <div class="hystmodal__wrap">        <div class="hystmodal__window" role="dialog" aria-modal="true" >            <button data-hystclose class="hystmodal__close">Close</button>              <h1>Заголовок модального окна</h1>            <p>Текст модального окна ...</p>            <img src="img/photo.jpg" alt="Изображение" width="400" />            <p>Ещё текст модального окна ...</p>        </div>    </div></div>

В код также добавлены некоторые aria и role атрибуты для обеспечения доступности.


Обновленный код CSS для обертки и окна.


.hystmodal__wrap {    flex-shrink: 0;    flex-grow: 0;    width: 100%;    min-height: 100%;    margin: auto;    display: flex;    flex-flow: column nowrap;    align-items: center;    justify-content: center;}.hystmodal__window {    margin: 50px 0;    flex-shrink: 0;    flex-grow: 0;    background: #fff;    width: 600px;    max-width: 100%;    overflow: visible;    transition: transform 0.2s ease 0s, opacity 0.2s ease 0s;    transform: scale(0.9);    opacity: 0;}

1.2 Скрываем окно


Сейчас наше окно всегда видно. Когда говорят о скрытии элементов, первое что приходит на ум это переключать свойство display со значения none до нашего значения flex.


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


Нам поможет другое свойство visibility:hidden. Оно скроет окно визуально, хотя и зарезервирует под него место. А так как все будущие окна на странице имеют фиксированное
позиционирование они будут полностью скрыты и не повлияют на остальную страницу. Кроме того, на элементы с visibility:hidden нельзя установить фокус с клавиатуры, а от скрин-ридеров мы уже скрыли окна с помощью атрибута aria-hidden="true".


Добавим также классы для открытого окна:


.hystmodal--active{    visibility: visible;}.hystmodal--active .hystmodal__window{    transform: scale(1);    opacity: 1;}

1.3 Оформление подложки


В лучшем случае, нам нужен отдельный html-элемент в качестве оверлея. Можно использовать и имеющийся элемент модального окна .hystmodal в качестве оверлея, но тогда анимация на этом элементе (например переход opacity) будет затрагивать и внутренние элементы. В итоге, не получится анимировать разные свойства для окна и оверлея отдельно.


Просто разместим элемент .hysymodal__shadow прямо перед закрывающие </body>. В будущем, сделаем так, чтобы этот элемент создавался автоматически из js при инициализации библиотеки.


Его свойства:


.hystmodal__shadow{    position: fixed;    border:none;    display: block;    width: 100%;    top: 0;    bottom: 0;    right: 0;    left: 0;    overflow: hidden;    pointer-events: none;    z-index: 98;    opacity: 0;    transition: opacity 0.15s ease;    background-color: black;}/* активная подложка */.hystmodal__shadow--show{    pointer-events: auto;    opacity: 0.6;}

1.4 Отключение прокрутки страницы


Когда модальное окна открывается, мы хотим, чтобы страница под ним не прокручивалась.
Самый простой способ этого добиться повесить overflow:hidden для body или html, когда окно открывается. Однако с этим есть проблема:


Проблема 4. В браузере Safari на iOS страница будет прокручиваться, даже если на тег html или body повешен overflow:hidden.
Решается двумя способами, либо блокированием событий прокрутки (touchmove, touchend или touchsart) из js вида:


targetElement.ontouchend = (e) => {    e.preventDefault();};

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


ps: можно конечно применить библиотеку scroll-lock, в которую заложено это решение, но в статье было решено воспользоваться другим вариантом.


Другое решение основано частично на CSS. Пусть когда окно открывается, на элемент <html> будет добавляться класс .hystmodal__opened:


.hystmodal__opened {    position: fixed;    right: 0;    left: 0;    overflow: hidden;}

Благодаря position:fixed, окно не будет прокручиваться даже в safari, однако здесь тоже не всё гладко:


Проблема 5. При открытии/закрытии окна страница прокручивается в начало.
Действительно, это происходит из-за изменения свойства position, текущая прокрутка окна сбрасывается.


Для решения, нам нужно написать следующий JS (упрощенно):


При открытии:


// Находим тег html и сохраняем егоlet html = document.documentElement;//сохраним текущую прокрутку:let scrollPosition = window.pageYOffset;//установим свойство top у html равное прокруткеhtml.style.top = -scrollPosition + "px";html.classList.add("hystmodal__opened");

При закрытии:


html.classList.remove("hystmodal__opened");//прокручиваем окно туда где оно былоwindow.scrollTo(0, scrollPosition);html.style.top = "";

Отлично, приступим к JavaScript коду.


2. Код JavaScript


2.2 Каркас библиотеки


Нам нужна совместимость со старыми браузерами включая IE11 поэтому нам нужно выбрать из 2 вариантов кодинга:


  • Разрабатывать на старом стандарте ES5, и использовать только те фичи, которые поддерживают все браузеры.
  • Применить современный синтаксис ES6, но подключить транспайлер Babel, который автоматически преобразует код для всех браузеров и встроит необходимые полифилы.
    Было принято решение использовать второй вариант, с прицелом на будущее.
    Приступим.

Основа нашей библиотеки единственный класс HystModal. Ниже я приведу скелет кода с комментариями, а потом добавим остальной функционал.


class HystModal{    /**     * При создании экземпляра класса, мы передаём в него     * js-объект с настройками. Он становится доступен     * в конструкторе класса в виде переменной props     */    constructor(props){        /**         * Для удобства некоторые свойства можно не передавать         * Мы должны заполнить их начальными значениями         * Это можно сделать применив метод Object.assign         */        let defaultConfig = {            linkAttributeName: 'data-hystmodal',            // ... здесь остальные свойства        }        this.config = Object.assign(defaultConfig, props);        // сразу вызываем метод инициализации        this.init();    }    /**      * В свойство _shadow будет заложен div с визуальной     * подложкой. Оно сделано статическим, т.к. при создании     * нескольких экземпляров класса, эта подложка нужна только     * одна     */    static _shadow = false;    init(){        /**         * Создаём триггеры состояния, полезные переменные и.т.д.         */        this.isOpened = false; // открыто ли окно        this.openedWindow = false; //ссылка на открытый .hystmodal        this._modalBlock = false; //ссылка на открытый .hystmodal__window        this.starter = false, //ссылка на элемент "открыватель" текущего окна        // (он нужен для возвращения фокуса на него)        this._nextWindows = false; //ссылка на .hystmodal который нужно открыть        this._scrollPosition = 0; //текущая прокрутка (см. выше)        /**         * ... остальное         */        // Создаём только одну подложку и вставляем её в конец body        if(!HystModal._shadow){            HystModal._shadow = document.createElement('div');            HystModal._shadow.classList.add('hystmodal__shadow');            document.body.appendChild(HystModal._shadow);        }        //Запускаем метод для обработки событий см. ниже.        this.eventsFeeler();    }    eventsFeeler(){        /**          * Нужно обработать открытие окон по клику на элементы с data-атрибутом         * который мы установили в конфигурации - this.config.linkAttributeName         *          * Здесь мы используем делегирование события клика, чтобы обойтись одним         * лишь обработчиком события на элементе html         *          */        document.addEventListener("click", function (e) {            /**             * Определяем попал ли клик на элемент,             * который открывает окно             */             const clickedlink = e.target.closest("[" + this.config.linkAttributeName + "]");            /** Если действительно клик был на              * элементе открытия окна, находим              * подходящее окно, заполняем свойства             *  _nextWindows и _starter и вызываем             *  метод open (см. ниже)             */            if (clickedlink) {                 e.preventDefault();                this.starter = clickedlink;                let targetSelector = this.starter.getAttribute(this.config.linkAttributeName);                this._nextWindows = document.querySelector(targetSelector);                this.open();                return;            }            /** Если событие вызвано на элементе             *  с data-атрибутом data-hystclose,             *  значит вызовем метод закрытия окна             */            if (e.target.closest('[data-hystclose]')) {                this.close();                return;            }        }.bind(this));        /** По стандарту, в обработчике события в this         * помещается селектор на котором события обрабатываются.         * Поэтому нам нужно вручную установить this на наш          * экземпляр класса, который мы пишем с помощью .bind().         */         //обработаем клавишу escape и tab        window.addEventListener("keydown", function (e) {               //закрытие окна по escape            if (e.which == 27 && this.isOpened) {                e.preventDefault();                this.close();                return;            }            /** Вызовем метод для управления фокусом по Tab             * и всю ответственность переложим на него             * (создадим его позже)             */             if (e.which == 9 && this.isOpened) {                this.focusCatcher(e);                return;            }        }.bind(this));    }    open(selector){        this.openedWindow = this._nextWindows;        this._modalBlock = this.openedWindow.querySelector('.hystmodal__window');        /** Вызываем метод управления скроллом         * он будет блокировать/разблокировать         * страницу в зависимости от свойства this.isOpened         */        this._bodyScrollControl();        HystModal._shadow.classList.add("hystmodal__shadow--show");        this.openedWindow.classList.add("hystmodal--active");        this.openedWindow.setAttribute('aria-hidden', 'false');        this.focusContol(); //вызываем метод перевода фокуса (см. ниже)        this.isOpened = true;    }    close(){        /**         * Метод закрытия текущего окна. Код упрощён         * подробнее в статье далее.         */        if (!this.isOpened) {            return;        }        this.openedWindow.classList.remove("hystmodal--active");        HystModal._shadow.classList.remove("hystmodal__shadow--show");        this.openedWindow.setAttribute('aria-hidden', 'true');        //возвращаем фокус на элемент которым открылось окно        this.focusContol();        //возвращаем скролл        this._bodyScrollControl();        this.isOpened = false;    }    _bodyScrollControl(){        let html = document.documentElement;        if (this.isOpened === true) {            //разблокировка страницы            html.classList.remove("hystmodal__opened");            html.style.marginRight = "";            window.scrollTo(0, this._scrollPosition);            html.style.top = "";            return;        }        //блокировка страницы        this._scrollPosition = window.pageYOffset;        html.style.top = -this._scrollPosition + "px";        html.classList.add("hystmodal__opened");    }}

Итак, мы описали класс HystModal. Чтобы всё работало, нужно всего лишь подключить наш скрипт и создать экземпляр класса:


const myModal = new HystModal({    linkAttributeName: 'data-hystmodal', });

Тогда по клику по ссылке/кнопке с атрибутом data-hystmodal, например такой: <a href="#" data-hystmodal="#myModal">Открыть окно</a> будет
открываться окно. Однако у нас появляются новые нюансы:


Проблема 6: если в браузере есть фиксированный скроллбар (который влияет на ширину страницы), то при открытии/закрытии окна происходит сдвиг контента, когда полоса прокрутки то появляется то пропадает.



Действительно скроллбар пропадает и контент страницы перераспределяется. Чтобы решить эту проблему, можно добавить отступ справа к тегу html, равный ширине скроллбара когда он пропадает.


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


Дополним метод _bodyScrollControl()


//при открытии окнаlet marginSize = window.innerWidth - html.clientWidth;//ширина скроллбара равна разнице ширины окна и ширины документа (селектора html)if (marginSize) {    html.style.marginRight = marginSize + "px";} //при закрытии окнаhtml.style.marginRight = "";

Почему код метода close() упрощён? Дело в том, что просто убирая классы CSS у элементов, мы не можем анимировать закрытие окна.


Проблема 7. При закрытии окна, свойство visibility:hidden применяется сразу и не даёт возможности анимировать закрытие окна.


Причина этого известна: свойство visibility:hidden не анимируется. Конечно, можно обойтись без анимации, но, если она нужна, сделаем следующее.


  • Создадим дополнительный CSS-класс .hystmodalmoved почти такой-же как и .hystmodal--active

.hystmodal--moved{    visibility: visible;}

  • Затем при закрытии сначала добавим этот класс к окну и повесим обработчик события transitionend на модальном окне. Затем удалим класс `.hystmodalactive, таким образом вызывая css-переход. Как только переход завершится, сработает обработчик события transitionend, в котором сделаем всё остальное и удалим сам обработчик события.

Ниже: новая версия методов закрытия окна:


close(){    if (!this.isOpened) {        return;    }    this.openedWindow.classList.add("hystmodal--moved");    this.openedWindow.addEventListener("transitionend", this._closeAfterTransition);    this.openedWindow.classList.remove("hystmodal--active");}_closeAfterTransition(){    this.openedWindow.classList.remove("hystmodal--moved");    this.openedWindow.removeEventListener("transitionend", this._closeAfterTransition);    HystModal._shadow.classList.remove("hystmodal__shadow--show");    this.openedWindow.setAttribute('aria-hidden', 'true');    this.focusContol();    this._bodyScrollControl();    this.isOpened = false;}

Вы заметили, что мы создали ещё один метод _closeAfterTransition() и перенесли основную логику закрытия туда. Это нужно, чтобы удалить обработчик события transitionend после закрытия окна, ведь в метод removeEventListener необходимо передать именно ту функцию, которую мы привязывали.


Кроме того, если анимация не будет нужна, можно просто вызвать this._closeAfterTransition() не вешая его на событие.


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


//внутри конструктораthis._closeAfterTransition = this._closeAfterTransition.bind(this)

2.2 Закрытие окна по клику на оверлей


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


document.addEventListener("click", function (e) {    const wrap = e.target.classList.contains('hystmodal__wrap');    if(!wrap) return;    e.preventDefault();    this.close();}.bind(this));

Это будет работать, но есть один малозаметный недостаток.


Проблема 8. Если кнопку мыши нажать внутри окна, а отпустить за его пределами (над подложкой), окно закрывается.


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


Окно закрывается потому что по спецификации, если нажатие и отпускание мыши были на разных элементах, то событие click сработает на самом ближайшем общем для них элементе, а у нас это как раз .hystmodal__wrap.


Мы могли бы решить это изменением html, добавляя ещё один div сразу после .hystmodal__window и размещая его визуально под окном. Но нам бы не хотелось добавлять лишний пустой div ещё сильнее усложняя разметку.


Мы можем разбить наш addEventListener на два отдельных обработчика: для событий mousedown и mouseup и будем проверять чтобы оба события происходили именно на .hystmodal__wrap. Добавим новые обработчики событий в наш метод eventsFeeler()


document.addEventListener('mousedown', function (e) {    /**    * Проверяем было ли нажатие над .hystmodal__wrap,    * и отмечаем это в свойстве this._overlayChecker    */    if (!e.target.classList.contains('hystmodal__wrap')) return;    this._overlayChecker = true;}.bind(this));document.addEventListener('mouseup', function (e) {    /**    * Проверяем было ли отпускание мыши над .hystmodal__wrap,    * и если нажатие тоже было на нём, то закрываем окно    * и обнуляем this._overlayChecker в любом случае    */    if (this._overlayChecker && e.target.classList.contains('hystmodal__wrap')) {        e.preventDefault();        !this._overlayChecker;        this.close();        return;    }    this._overlayChecker = false;}.bind(this));

2.3 Управление фокусом


У нас заготовлено два метода для управления фокусом: focusContol() для переноса фокуса внутрь окна и обратно при его закрытии, а также focusCatcher(event) для блокирования ухода фокуса из окна.


Решения для фокуса были реализованы аналогично js-библиотеке Micromodal (Indrashish Ghosh). А именно:


1.В служебный массив сохраним все css селекторы на которых может быть установлен фокус (свойство помещаем в init()):


//внутри метода init или конструктораthis._focusElements = [    'a[href]',    'area[href]',    'input:not([disabled]):not([type="hidden"]):not([aria-hidden])',    'select:not([disabled]):not([aria-hidden])',    'textarea:not([disabled]):not([aria-hidden])',    'button:not([disabled]):not([aria-hidden])',    'iframe',    'object',    'embed',    '[contenteditable]',    '[tabindex]:not([tabindex^="-"])'];

2.В методе focusContol() находим первый такой селектор в окне и устанавливаем на него фокус, если окно открывается. Если же окно закрывается то переводим фокус на this.starter:


focusContol(){    /** Метод переносит фокус с элемента открывающего окно     * в само окно, и обратно, когда окно закрывается     * см. далее в тексте.     */    const nodes = this.openedWindow.querySelectorAll(this._focusElements);    if (this.isOpened && this.starter) {        this.starter.focus();    } else {        if (nodes.length) nodes[0].focus();    }}

3.В методе focusCatcher() находим в окне и превращаем в массив коллекцию всех элементов на которых может быть фокус. И проверяем, если фокус должен был выйти на пределы окна, то вместо этого устанавливаем фокус снова на первый или последний элемент (ведь фокус можно переключать как по Tab так и по Shift+Tab в обратную сторону).


Результирующий код метода focusCatcher:


focusCatcher(e){    /** Метод не позволяет фокусу перейти вне окна при нажатии TAB     * элементы в окне фокусируются по кругу.     */    // Находим все элементы на которые можно сфокусироваться    const nodes = this.openedWindow.querySelectorAll(this._focusElements);    //преобразуем в массив    const nodesArray = Array.prototype.slice.call(nodes);    //если фокуса нет в окне, то вставляем фокус на первый элемент    if (!this.openedWindow.contains(document.activeElement)) {        nodesArray[0].focus();        e.preventDefault();    } else {        const focusedItemIndex = nodesArray.indexOf(document.activeElement)        if (e.shiftKey && focusedItemIndex === 0) {            //перенос фокуса на последний элемент            focusableNodes[nodesArray.length - 1].focus();        }        if (!e.shiftKey && focusedItemIndex === nodesArray.length - 1) {            //перерос фокуса на первый элемент            nodesArray[0].focus();            e.preventDefault();        }    }}

По сути мы реализовали все необходимое для успешного создания модальных окон, осталось ещё несколько дел:


Проблема 9. В IE11 не работают методы Element.closest() и Object.assign().


Для поддержки Element.closest, воспользуемся полифилами для closest и matches от MDN.


Можно их вставить просто так, но так как у нас проект всё равно собирается webpack, то удобно воспользоваться пакетом element-closest-polyfill который просто вставляет этот код.


Для поддержки Object.assign, можно воспользоваться уже babel-плагином @babel/plugin-transform-object-assign


3. Заключение и ссылки


Повторяя начало статьи, всё изложенное выше, я оформил в маленькую библиотеку hystModal под MIT-лицензией. Вышло 3 кБ кода при загрузке с gzip. Ещё написал для неё подробную документацию на русском и английском языке.


Что вошло ещё в библиотеку hystModal, чего не было в статье:


  • Настройки (вкл/выкл управление фокусом, варианты закрытия, ожидание анимации закрытия)
  • Коллбеки (функции вызывающиеся перед открытием окна и после его закрытия (в них передаётся объект модального окна))
  • Добавлен запрет на какие-либо действия пока анимация закрытия окна не завершится, а также ожидание анимации закрытия текущего окна перед открытием нового (если окно открывается из другого окна).
  • Оформление кнопки-крестика закрытия в CSS
  • Минификация CSS и JS плагинами Webpack.

Если вам будет интересна эта библиотека, буду рад звёздочке в GitHub, или напишите в Issues о найденных багах. (Особенно большие проблемы, наверное, в грамматике английской версии документации, так как мои знания языка пока на начальном уровне. Связаться со мной также можно в Instagram

Подробнее..

Перевод Безжалостное избавление от Layout Shift на netlify.com

04.12.2020 00:04:03 | Автор: admin

Приветствую. Представляю вашему вниманию перевод статьиRuthlessly Eliminating Layout Shift On Netlify.com, опубликованной 25 ноября 2020 года автором Zach Leatherman.

На сайте Netlify у нас есть небольшой баннер, который появляется вверху для привлечения трафика к новым и интересным вещам, происходящим в мире Netlify.

Этот баннер состоит из двух частей:

  1. Расширенная фича HTML, о которой знают только разработчики старой школы: гиперссылка.

  2. Кнопка закрытия (которая сохраняет предпочтение для будущих загрузок страницы)

В жизненном цикле этого компонента есть несколько ключевых этапов производительности, и вот как это работало раньше:

  1. Первоначальный рендеринг страницы. По умолчанию баннер скрыт. До загрузки JavaScript или без JavaScript баннер не отображается.

  2. После загрузки JavaScript мы проверяем localStorage, чтобы узнать, закрывал ли пользователь баннер ранее. Значение - URL-адрес ссылки, чтобы при изменении баннера он снова отображался, даже если пользователь его закрыл. Если нужно - рендерим баннер.

  3. Наконец, мы вешаем события на кнопку закрытия. Для гиперссылки это не нужно, потому что ее поведение предоставляется исключительно в HTML (вааау).

Шаги 2 и 3 объединены и выполняются вместе в одном компоненте. В некоторых предедущих версиях сайта время между шагами 1 и 2 могло достигать ~600 мс.

При редизайне нашего сайта (заметьте, быстрее) мы вставили JavaScript шагов 2 и 3 в конец <body>, и задержка все еще была:

Решение

Что нам нужно сделать? Сделать поведение наоборот. Обычно баннер по умолчанию скрыт. Мы должны сделать баннер видимым по умолчанию и с помощью JavaScript скрывать его, если нужно.

Это изменяет наш выше упомянутый Шаг 1, первоначальный рендеринг страницы. Теперь без JavaScript или до загрузки JavaScript баннер будет виден.

Мы также разделили код JavaScript-компонента на две отдельные части: в одной проверяем, есть ли у пользователя флаг для скрытия, и отдельный веб-компонент для привязки событий.

Update: Я собрал этот код и выложил на GitHub для повторного использования.

HTMLи CSS

Мы используем opacity для скрытия кнопки закрытия, чтобы изза неё не перерисовывался компонент, когда он отобразится с помощью JavaScript.

.banner--hide announcement-banner,announcement-banner[hidden] {  display: none;}[data-banner-close] {  opacity: 0;  pointer-events: none;}.banner--show-close [data-banner-close] {  opacity: 1;  pointer-events: auto;}
<announcement-banner>  <a href="http://personeltest.ru/aways/www.netlify.com/sustainability/">Read about our Sustainability</a>  <button type="button" data-banner-close>Close</button></announcement-banner>

JavaScript

banner-helper.js, вставленный в<head> страницы:

// Адрес CTA ссылки, мы инжектим его из JSON файлаlet ctaUrl = "https://www.netlify.com/sustainability/";let savedCtaUrl = localStorage.getItem("banner--cta-url");if(savedCtaUrl === ctaUrl) {  document.documentElement.classList.add("banner--hide");}

banner.js, отоложен на потом (на сколько позже - зависит от вас):

class Banner extends HTMLElement {  connectedCallback() {    // Независимо от того, когда это выполняется, кнопка закрытия будет скрыта,     // пока этот класс не будет добавлен - он предотвращает призрачные клики     // по кнопке до добавления обработчика событий.    this.classList.add("banner--show-close");    let button = this.getButton();    if(button) {      button.addEventListener("click", () => {        this.savePreference();        this.close();      });    }  }  getButton() {    return this.querySelector("[data-banner-close]");  }  savePreference() {    let cta = this.querySelector("a[href]");    if(cta) {      let ctaUrl = cta.getAttribute("href");      localStorage.setItem("banner--cta-url", ctaUrl);    }  }  close() {    this.setAttribute("hidden", true);  }}window.customElements.define("announcement-banner", Banner);

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

Результат

Обратите внимание, что первый рендер содержит баннер! Это одинаковый рендеринг вне зависимости от того, задействован ли JavaScript или нет.

На этой диаграмме видно, что мы снизили показатели Layout Shift до нуля.

И поскольку мы вставили скрипт для повторных просмотров в <head>, когда пользователь скрывает баннер и переходит на новую страницу, баннер также будет скрыт перед первым рендерингом.

Довольно неплохо для таких маленьких изменений!

Следующей целью будет улучшение отображения веб-шрифтов.

Подробнее..

Доступность это не так просто

22.12.2020 14:23:50 | Автор: admin


Привет, Хабр! В предыдущей статье я рассказывал о простых случаях проблем с доступностью, исправив которые можно сделать свой сайт или web-приложение гораздо доступнее. Я упоминал о правиле 80/20 и писал о проблемах, которые при наименьших затратах дают наибольший результат. Сегодня я бы хотел поговорить о другой группе проблем, которые входят в 20% и для решения которых нет готовых рецептов вроде всегда заполняйте атрибут alt или используйте верные заголовки.

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

Формализуем проблему


Как я уже говорил, для некоторых проблем в сфере доступности невозможно предложить какое-то простое решение. Эти проблемы очень вариативны, а иногда и вовсе уникальны для конкретного приложения. Помимо этого, ситуация осложняется различиями в работе разных скринридеров в разных браузерах и на разных операционных системах. Дополняет всё это то, что решение лежит на стыке двух дисциплин: доступности с её стандартами и Interaction Design (Проектирование взаимодействия) с её достаточно гибкими правилами.

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

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

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

К таким элементам можно отнести:

  • табы;
  • модальные окна;
  • аккордеон;
  • меню (в том числе с большой вложенностью).

Каждый компонент их этого списка можно условно разделить на две составляющие:

  • триггер элемент, запускающий действие;
  • целевой контент элемент, который содержит в себе кусочек видоизмененного контента.

Реализация триггера


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

В итоге я прихожу к первому вопросу: должен ли быть триггер ссылкой или кнопкой?

Ответ на этот вопрос звучит примерно так: в зависимости от ситуации, но в целом, вы не ошибётесь, если будете всегда использовать кнопку.

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

Поэтому я задаю себе второй вопрос: должен ли изменившийся контент получить фокус?
И опять ответом на этот вопрос будет фраза в зависимости от ситуации. Но можно помочь себе, просто посмотрев на DOM-дерево и оценив, насколько далеко триггер находится от целевого контента.

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

<button>Trigger Text</button> <div id="target">   <p>Target content.</p></div>

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

<a href="#target">Trigger Text</a>  <div id="target">  <p>Target content.</p></div>


Реальный пример


Предположим, в макете, предоставленном дизайнером, имеется элемент Войти, расположенный в шапке сайта. И, согласно дизайну, по нажатию должно открыться модальное окно с формой входа. Сам код модального окна, скорее всего, находится в конце DOM-дерева. В этом случае использование ссылки не кажется мне плохой идеей.

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

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

Далее я добавляю на страницу немного JavaScript, чтобы убедиться, что пользователи клавиатуры и мыши могут взаимодействовать с созданным компонентом. Конечно, не обходится без небольшой магии с tabindex и методом focus(), которые заслуживают отдельной статьи.

Теперь самое время подумать о пользователях скринридеров. Первое, что стоит сделать это добавить атрибуты aria-expanded в триггер и aria-hidden в целевой контент.

// Таргет не активирован
Триггер - aria-expanded="false",
Целевой контент - aria-hidden="true".

// Пользователь нажал на таргет элемент
Триггер - aria-expanded="true",
Целевой контент - aria-hidden="false".


Ещё существует атрибут aria-controls, который позволяет явно указать взаимосвязь между целевым компонентом и триггером.

<button aria-controls="target">Trigger Text</button><div id="target">  <p>Target content.</p></div>

Правда, он не всегда работает так, как это можно ожидать.

В качестве заключения


Для более наглядного примера я реализовал два codepan: один с триггером в виде кнопки, а второй со ссылкой (кнопка, ссылка). В чём разница, спросите вы? Всё просто: в примере со ссылкой целевой контент сразу получил фокус без каких-то дополнительных телодвижений со стороны разработчика.

Это наводит меня на мысль, что, возможно, если вы работаете над SPA, то стоит задуматься, стоит ли делать SPA, а потом пытаться сделать его доступным, продумывая, куда перевести фокус в появившемся контенте. Где должен оказаться фокус после исчезновения появившегося контента, что будет с фокусом, когда целевой контент скроется? Ведь очень часто, пытаясь делать SPA доступным, вы во много повторяете функциональность, уже заложенную в браузеры.

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

И помните, что тот факт, что вы дочитали этот материал до конца, означает, что вы знаете, как решать проблемы с доступностью лучше, чем большинство разработчиков.

Спасибо за внимание, всем добра!
Подробнее..

Забудьте про div, семантика спасёт интернет

11.03.2021 14:15:49 | Автор: admin

Давным-давно (лет пятнадцать назад) почти все делали сайты инепереживали отом, что под капотом. Верстали таблицами, использовали всё, что попадётся под руку (апопадались восновном <div> и<span>) инеособо заморачивались одоступности. Апотом случился HTML5 ипонеслось.

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

Дисклеймер: статья может обидеть тех, кто прикипел к вёрстке дивами. Но <div> не приговор, и мы не призываем от него целиком отказываться. Ну и всегда можно договориться.

Почему семантика важна

Чтобы сделать сайт доступным. Зрячие пользователи могут без проблем спервого взгляда понять, где какая часть страницы находится где заголовок, списки или изображения. Для незрячих или частично незрячих всё сложнее. Основной инструмент для просмотра сайтов небраузер, который отрисовывает страницу, аскринридер, который читает текст состраницы вслух.

Этот инструмент зачитывает содержимое страницы, исемантическая структура помогает ему лучше определять, какой сейчас блок, апользователю понимать, очём идёт речь. Таким образом семантическая разметка помогает большему количеству пользователей взаимодействовать свашим сайтом. Например, наличие заголовков помогает незрячим внавигации постранице. Ускринридеров есть функция навигации позаголовкам, что ускоряет знакомство синформацией насайте.

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

Классический пример расписание поезда Сапсан ввыдаче Google.

Разработчики tutu.ru сверстали таблицу тегом <table> вместо <div>и ихсниппет оказался ввыдаче Google поважному коммерческому запросу.

Семантика прописана встандартах. Многие разработчики постаринке пользуются конструкциями типа <div id="nav"> для обозначения навигации или других структурных элементов страницы. Тем временем встандарте HTML есть несколько семантических тегов, которые рекомендуется использовать для разметки страниц вместо <div> и <span>. Вспецификации для каждого семантического элемента описана его роль.

Нуипредставьте, насколько проще читать <nav></nav> вместо <div class="nav"></div>. Или вот такой код. Смотрите исразу понятно, что тут изачем.

<!DOCTYPE html><html lang="ru">  <head>    <meta charset="utf-8">    <title>Заголовок страницы</title>  </head>  <body>    <header class="main-header">      <! Шапка сайта >    </header>    <main>      <! Основное содержимое страницы >    </main>    <footer class="main-footer">      <! Подвал сайта >    </footer>  </body></html>

Основные семантические теги HTML

Среди старых тегов изранних версий HTML тоже есть семантические например, тег <p>, который обозначает параграф. При этом теги <i> или <b> несемантические, потому что они недобавляют смысла выделенному тексту, апросто определяют его внешний вид.

Новактуальной версии стандарта HTML Living Standard есть семантические теги почти для всех основных частей сайта, илучше пользоваться ими. Вот несколько примеров семантических тегов.

<article>

  • Значение: независимая, отделяемая смысловая единица, например комментарий, твит, статья, виджетВК итак далее.

  • Особенности: желателен заголовок внутри.

  • Типовые ошибки: путают стегами <section> и <div>.

<section>

  • Значение: смысловой раздел документа. Неотделяемый, вотличиеот <article>.

  • Особенности: желателен заголовок внутри.

  • Типовые ошибки: путают стегами <article> и <div>.

<aside>

  • Значение: побочный, косвенный для страницы контент.

  • Особенности: может иметь свой заголовок. Может встречаться несколько раз настранице.

  • Типовые ошибки: считать <aside> тегом для боковой панели иразмечать этим тегом основной контент, который связан сокружающими его элементами.

<nav>

  • Значение: навигационный раздел соссылками надругие страницы или другие части страниц.

  • Особенности: используется для основной навигации, анедля всех групп ссылок. Основной является навигация или нет наусмотрение верстальщика. Например, меню вподвале сайта можно необорачивать в <nav>. Вподвале обычно появляется краткий список ссылок (например, ссылка наглавную, копирайт иусловия) это неявляется основной навигацией, семантически для такой информации предназначен <footer> сам посебе.

  • Типовые ошибки: многие считают, что в <nav> может быть только список навигационных ссылок, носогласно спецификации там может быть навигация влюбой форме.

<header>

  • Значение: вводная часть смыслового раздела или всего сайта, обычно содержит подсказки инавигацию. Чаще всего повторяется навсех страницах сайта.

  • Особенности: этих элементов может быть несколько настранице.

  • Типовые ошибки: использовать только как шапку сайта.

<main>

  • Значение: основное, неповторяющееся надругих страницах, содержание страницы.

  • Особенности: должен быть один настранице, исходя изопределения.

  • Типовые ошибки: включать вэтот тегто, что повторяется надругих страницах (навигацию, копирайты итак далее).

<footer>

  • Значение: заключительная часть смыслового раздела или всего сайта, обычно содержит информацию обавторах, список литературы, копирайт итак далее. Чаще всего повторяется навсех страницах сайта.

  • Особенности: этих элементов может быть несколько настранице. Тег <footer> необязан находиться вконце раздела.

  • Типовые ошибки: использовать только как подвал сайта.

Как разметить страницу сточки зрения семантики

Процесс разметки можно разделить нанесколько шагов сразной степенью детализации.

  1. Крупные смысловые блоки накаждой странице сайта. Теги: <header>, <main>, <footer>.

  2. Крупные смысловые разделы вблоках. Теги: <nav>, <section>, <article>, <aside>.

  3. Заголовок всего документа изаголовки смысловых разделов. Теги: <h1>-<h6>.

  4. Мелкие элементы всмысловых разделах. Списки, таблицы, демо-материалы, параграфы ипереносы, формы, цитаты, контактная информация ипрогресс.

  5. Фразовые элементы. Изображения, ссылки, кнопки, видео, время имелкие текстовые элементы.

Сомневаюсь, какие теги использовать

Есть простые правила для выбора нужных тегов.

  • Получилось найти самый подходящий смысловой тег использовать его.

  • Для потоковых контейнеров <div>.

  • Для мелких фразовых элементов (слово или фраза) <span>.

Правило для определения <article>, <section> и <div>:

  1. Можете дать имя разделу ивынести этот раздел надругой сайт? <article>

  2. Можете дать имя разделу, новынести надругой сайт неможете? <section>

  3. Неможете дать имя? Получается что-то наподобие новости ифотогалерея или правая колонка? <div>

Как точно ненужно делать

Неиспользуйте семантические теги для украшательств. Для этого есть CSS.

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

Здесь сразу несколько ошибок:

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

  2. Тег <ul> тоже использован для визуального сдвига текста. Это неверно, потому что этот тег должен быть использован только для обозначения списков, аво-вторых, втег <ul> можно вкладывать только теги <li> иничего больше.

  3. Тег <p> использован, чтобы визуально раздвинуть текст. Насамом деле этот тег используется для выделения параграфов.

Алюбое выделение, сдвиг или иные превращения текста можно выполнить спомощью CSS.

Поэтому используйте семантические теги поназначению.


Более подробно методика создания семантической разметки описана внавыке Создание семантической разметки помакету икурсах HTMLAcademy. Можно начать с бесплатных тренажёров по основам HTML и CSS или с курса Профессиональная вёрстка сайтов. А с промокодом SKUCHNO цена станет ещё приятнее.

В конце концов, один раз живём.

Подробнее..

Доступность ИТ-сервисов как ключевой бизнес показатель, и причем тут арбуз

28.04.2021 02:24:00 | Автор: admin

Использование метрик в управлении - это прогрессивная и современная практика, тем более в настолько оцифрованной среде как ИТ-бизнес. А что в последнее десятилетие не ИТ-бизнес? От торговли цветами до автомобилестроения, везде ИТ - ключевой фактор успеха. Метрики позволяют принимать грамотные управленческие и инженерные решения, правильно распределять бюджет, повышать прозрачность, добиваться справедливости и объективности.

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

Идеальная метрика

Впервые я с этим столкнулся в самом начале своей карьеры. Тогда я работал сетевым инженером в региональном операторе связи, и в мои обязанности входила обработка метрик из системы мониторинга для подготовки KPI-отчета по техническому блоку. За основу брались данные о том, пингуется или нет узел связи (без привязки количества абонентов, которые от него зависят). Но в жизни качество предоставляемых провайдером услуг измеряется далеко не прохождением ICMP-пакетов от сервера мониторинга до коммутатора в подъезде, тем более, когда эти коммутаторы находятся в своем стерильном VLAN-е. Этого, наверное, не знали, но смогли прочувствовать на себе абоненты, особенно, нового в то время сервиса: IPTV через multicast. Зависающие картинки на телевизорах абонентов никак не коррелировали с прекрасной зеленой картинкой, подаваемой на стол руководства, и премиальным фондом. Результатом стала проваленная маркетинговая кампания по продвижению IPTV и немного пошатнувшаяся репутация. А дальше по цепочке: пересмотр KPI для инженеров с включением в него кучи новых метрик (в том числе и с бизнес уклоном), весовых коэффициентов, которые было просто невозможно рассчитать, и на которые было сложно повлиять. И вишенка на торте: восприятие сотрудниками KPI в качестве репрессивного инструмента сокращения зарплаты, и полная неэффективность его регуляторной функции. Я думаю, что у вас будет много подобных примеров из практики, особенно если коснуться такой острой темы как KPI и SLA. Вообще тема KPI, особенно в IT, заслуживает отдельного остросюжетного романа.

Я вспомнил описанную выше историю, когда практически одновременно несколько корпоративных заказчиков обратились с проблемой непрозрачного расчета SLA и KPI своих ИТ-подразделений. Стоит пояснить, что сейчас я работаю над продуктом зонтичного мониторинга для оперативного обнаружения и устранения сбоев в ИТ нашим продуктом пользуется ряд очень крупных клиентов из разных сфер: от госуправления и финтеха до СМИ и авиакомпаний.

Памятуя о своем неудачном опыте на первом месте работы, я не очень хотел ввязываться в KPI и SLA. Вначале я предложил решить эту проблему через настройку соответствующих Service Desk, тем более так рекомендует нам ITSM (Service Desk - единая точка входа и агрегации всей информации об услугах), а мой продукт будет лишь продолжать регистрировать инциденты и помогать с их дедупликацией за счет определения массовых сбоев и понимания: относится ли новый алерт к проблеме, находящейся на контроле у инженеров, или нет. Но коллегам хотелось не отчетности и репрессивного контроля, как я изначально ошибочно предположил, - им хотелось инструмента управления, который бы помогал и бизнесу, и инженерам находить некий общий язык и добавлял бы прозрачности в их отношения.

В итоге мы сошлись во мнении, что одним из выходов является создание единой синтетической (интегральной) метрики, понятной всем сторонам. По крайней мере, введение такой метрики позволит снизить цифровой шум и, что немаловажно, задаст нашей ИТ-службе некий ориентир для принятия правильных для бизнеса решений. А еще, совсем идеально, если эта метрика позволяла бы непредвзято оценивать, на какой области нашего ИТ-окружения нам следует сосредоточить внимание (здравствуй, бюджетное планирование и портфель проектов). Таким образом, эта идеальная синтетическая метрика должна удовлетворять следующим условиям:

  1. Бизнес-ориентация. Метрика должна отражать работу нашего ИТ-окружения не с позиции работоспособности какого-либо сервера, а с позиции того, насколько это важно нашим клиентам;

  2. Понятность. Метрику можно однозначно интерпретировать как техническим специалистам, так и бизнесу.

  3. Декомпозируемость. По результатам можно провести анализ, разложить нашу единую синтетическую метрику на компоненты/факторы и выделить наиболее критический. В идеальном случае на выходе получить root cause анализ.

В итоге было предложено два варианта реализации: 1) метрика доступности сервиса/объекта (Service Availability); 2) карта здоровья (Health Map). Карта здоровья в итоге оказалась более сложной как в реализации, так и в аналитическом сопровождении, и была определена как перспективная целевая схема, и на время ее доработки был выбран более простой и привычный подход с оценкой доступности сервиса, о котором и пойдет дальше речь.

Доступность сервиса - это про бизнес, но и про ИТ

Итак, что же такое доступность сервиса? Я сформулировал для себя следующее определение: Доступность сервиса (англ. Service Availability)- это такое состояние нашего ИТ-окружения, когда наши клиенты могут и хотят получить услугу и остаться в целом удовлетворенными. Стоит также подчеркнуть, что здесь может быть только два состояния: либо условия выполняются, либо нет. Все полутона только смазывают картинку. Никакой деградации, никакой сниженной производительности - все это технические показатели, необходимые исключительно инженерам для оценки динамики состояния системы.

Приведу пример: потенциальный клиент хочет подать онлайн-заявку на оформление кредита в банке, но система работает со сбоями. Из-за высокого времени ожидания ответа сервера форма постоянно сбрасывается или на ней возникают ошибки, но минут за 30 заявку можно подать. Это приводит к тому, что конверсия в воронке продаж резко падает. С позиции классического инженерного мониторинга это серьезная деградация, но услуга доступна, а вот с позиции бизнеса это неприемлемое состояние системы, когда он теряет потенциальных клиентов. В данном примере доступность сервиса должна считаться равной 0. Приведу обратный пример: у вас, в силу каких-то непредвиденных обстоятельств, полностью выключается целый ЦОД и ваши системы переходят на резервный, при этом клиенты в штатном режиме, правда, чуть дольше, чем обычно, но регистрируют заявки на кредит, и конверсия не падает. А тут мы говорим, что сервис доступен полностью и мы, как инженеры, молодцы - обеспечили горячее резервирование. Хотя при этом половина наших серверов и каналов связи находятся в коме и не доступны. Таким образом, определение доступности сервиса целиком находится на стороне бизнеса, а мы должны лишь зафиксировать в каком соответствующем состоянии должно находится наше ИТ-окружение. Можно поддаться искушению сделать все просто и повесить, например, метрику конверсии как KPI для ИТ-департамента, забывая при этом, что ИТ не про конверсию, его нормальная работа - необходимое, но недостаточное условие для продвижения клиентов по воронке продаж. Поэтому использование бизнес-метрики в лоб приведет к непониманию и отторжению инженерного состава. К сожалению, этому искушению простоты очень часто поддаются руководители и в результате получают прямо противоположный эффект.

Особенности реализации

Необходимо сразу пояснить, что в нашей системе зонтичного мониторинга мы зачастую имеем дело не с метриками, а с уже конкретными событиями, алертами, возникшими в различных системах мониторинга. Эти алерты мы распределяем по конфигурационным единицам (сервисы, сервера, виртуальные машины, кластеры и т.д., далее - КЕ) в ресурсно-сервисной модели. Также, в зависимости от пришедших событий, мы изменяем статус синтетических триггеров (синтетические - потому что могут рассчитываться на основании алертов из разных систем мониторинга, далее СТ). По сути синтетический триггер - это аналог аварийной ситуации / бизнес-проблемы, у которой есть начало и конец.

В нашей системе мы позволяем рассчитывать доступность, как отдельной КЕ, так и совокупную доступность группы КЕ. Метрика доступности для группы КЕ - это и есть искомая верхнеуровневая метрика доступности конечного сервиса, потому что сервис зачастую оказывается целым комплексом информационных систем и, в целом, представляет цепочку более мелких сервисов (ЦОД отвечает за сервис предоставления виртуальных машин, Облако за сервис системных компонентов, Информационная систем за прикладные сервисы и так далее). А доступность отдельной КЕ - это оценка работоспособности того или иного объекта с позиции оказания конечного сервиса. Взаимоувязка позволяет в дальнейшем проводить факторный анализ и определять вклад каждого объекта в общий результат, таким образом, находить узкое горлышко.

При построении отчета необходимо прежде всего определить список аварийных ситуаций или их совокупности, которые свидетельствуют о нарушении работы сервиса. Определить также такие дополнительные параметры (при необходимости), как:

  • Время работы сервиса. Например, нам важно, чтобы услуга была доступна только в дневные часы и только по праздникам;

  • Есть ли у нас RTO (recovery time objective) - максимально допустимое время, в течение которого наш объект может находиться в аварийном состоянии;

  • Учитываем или нет согласованные сервисные окна.

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

Собственно методика

Итак, вначале рассчитаем доступность для одной КЕ. К этому этапу мы уже настроили все фильтры и определились с параметрами нашего расчета.

Для расчета доступности за период SA (Service Availability) необходимо построить функцию проблемного состояния КЕ от времени fProblem(t), которая в каждый момент времени принимает одно из четырех значений:

  • Значение (0) говорит о том, что в конкретный момент времени на КЕ не зафиксированы проблемы, отвечающие фильтру;

  • Значение (1) - в конкретный момент времени на КЕ зафиксирована проблема (-ы), подпадающая под условия;

  • Значение (N), что КЕ находится в необслуживаемом состоянии;

  • Значение (S), что КЕ находится в согласованном сервисном режиме.

В результате мы получим следующие показатели:

  • timeNonWorking - нерабочее время КЕ на исследуемом периоде. Значение функции равно "N";

  • timeWorkingProblem - время нахождения КЕ в не удовлетворяющим SLA состоянии на исследуемом промежутке времени. Значение функции равно "1";

  • timeWorkingService - время согласованного простоя, когда, в рабочее время, КЕ находилась в сервисном режиме. Значение функции равно "S";

  • timeWorkingOK - время, в которое наша КЕ удовлетворяла SLA. Функция fProblem(t) находилась в состоянии "0".

Расчет доступности за период для одиночной КЕ SA (Service Availability) осуществляется по формуле:

SA =timeWorkingOK / (timeWorkingOK+timeWorkingProblem) * 100%

Рис.1 Пример возможного распределения интервалов времени при расчете SA (Service Availability) для одной КЕРис.1 Пример возможного распределения интервалов времени при расчете SA (Service Availability) для одной КЕРис. 2 Пример влияния RTO на расчет функции fProblem(t)Рис. 2 Пример влияния RTO на расчет функции fProblem(t)

Для группового расчета доступности за период SAG (Service Availability Group) необходимо построить функцию проблемного состояния КЕ от времени fProblem(t) для каждой КЕ, входящей в группу. Далее наложить получившиеся функции fProblem(t) по каждой КЕ друг на друга, исходя из определенных правил (см. Табл. 1)

ТАБЛИЦА 1.

f1

f2

fResult

f1

f2

fResult

f1

f2

fResult

0

0

0

1

1

1

N

N

N

0

1

1

1

S

1

N

S

S

0

N

0

1

N

1

S

S

S

0

S

0

В результате получаем функцию fGroupProblem(t). Суммируем длительность участков данной функции следующим образом:

  • timeGroupService - время, когда fGroupProblem(t)= S;

  • timeGroupOK - время, когда fGroupProblem(t) = 0;

  • timeGroupProblem - время, когда fGroupProblem(t) = 1;

Таким образом, искомая метрика:

SAG = timeGroupOK / (timeGroupOK+timeGroupProblem) * 100%

 Пример возможного распределения интервалов времени при расчете доступности для группы КЕ Пример возможного распределения интервалов времени при расчете доступности для группы КЕ

Факторный анализ

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

Факторный анализ позволяет определить: какой фактор-проблема повлиял за отчетный период на расчет доступности и сравнить степень такого влияния с остальным факторами-проблемами.

Предположения методики:

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

  • В случае, если одновременно произошли две и более проблемы, то на такой период будем считать длительность каждой с коэффициентом 1/N, где N - количество одновременно произошедших проблем.

Методика расчета:

  1. Необходимо взять функцию fProblem(t), построенную при расчете SA.

  2. Для каждого участка, где итоговая функция fProblem(t) = 1, составить список проблем данной КЕ, на основании которых данному участку было присвоено значение. При составлении списка необходимо учитывать и проблемы, которые начинались или заканчивались за пределами участка функции.

  3. Проставить проблеме метрику влияния. Она равняется длительности проблемы на участке умноженную на вес. В случае, если на участке в области свой длительности проблема была единственная, то ей устанавливается вес, равный 1, в случае множественных проблем вес равен 1/N, где N - количество одновременно произошедших проблем.

  4. При расчете следует учесть следующие моменты:

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

    2. Одна и та же проблема может присутствовать на разных участках fProblem(t) = 1. Например, проблема началась в пятницу, закончилась во вторник, а в выходные КЕ не обслуживается согласно SLA.

  5. В итоге должен быть сформирован список проблем, которые участвовали в расчете функции fProblem(t). При этом у каждой проблемы должна быть посчитана метрика влияния на SA.

  6. Необходимо обязательно верифицировать расчет. Сумма метрик влияния всех проблем должна равняться timeWorkingProblem.

  7. Пользователю необходимо выводить относительное значение влияния в %. Для этого метрику влияния необходимо разделить на timeWorkingProblem и умножить на 100%.

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

В результате получаем вот такую картину (см. рис 4.)

Рис. 4 Анализ и оценка проблем в расчете доступностиРис. 4 Анализ и оценка проблем в расчете доступности

Промежуточные итоги

Метрика доступности сервиса обладает всеми тремя необходимыми свойствами идеальной метрики: понятность, декомпозируемость и бизнес-ориентация. Благодаря данной метрике можно однозначно оценить работоспособность ИТ-окружения с позиции вашего бизнеса, а инженерному составу держать в фокусе самое важное - уровень сервиса, который он предоставляет. Но есть и ряд серьезных недостатков: все-таки предложенная методика расчета метрик доступности носит ретроспективный характер, и не позволяет строить прогнозов; нет оценки рисков, что не позволяет принимать оперативные решения при ликвидации аварий.

Несмотря на ряд ограничений, предложенный метод был позитивно воспринят нашими пользователям, причем как со стороны менеджмента, так и со стороны инженерного состава. При разработке, для нас позитивное восприятие сразу двумя сторонами было самым важным показателем и индикатором - мы находимся на правильном пути. На текущий момент идет активное внедрение в практику работы ИТ-подразделений сразу у нескольких клиентов. Один из заказчиков, из сферы финтеха, предложил на полученные временные значения доступности сервисов накладывать финансовые потери и, таким образом, постараться в денежном выражении посчитать - насколько будут оправданы те или иные вложения в улучшение ИТ-инфраструктуры.

В любом случае, это не последняя наша попытка найти Святой Грааль - идеальную метрику и метод ее расчета, чтобы помочь нашим клиентам не превратить свое ИТ-окружение в тот самый арбуз. Следующая наша ставка на Карту здоровья. Надеюсь в дальнейшем продолжить делиться с вами полученными результатами.

В заключение несколько скриншотов расчета доступности в продукте MONQ.
Подробнее..

Почему российские сайты не будут соответствовать ГОСТу по доступности

26.10.2020 16:12:51 | Автор: admin


Закончив перевод Руководства по обеспечению доступности веб-контента (WCAG) 2.1 на русский язык, захотелось поговорить о языкознании, правоприменении, и поднять вынесенный в заголовок вопрос: почему российские сайты могут соответствовать WCAG, разработанным на его основе стандартам по доступности Евросоюза, США и даже Китая, но не национальному стандарту ГОСТу?

1 апреля этого года (дата выбрана весьма символичная) вступил в силу ГОСТ Р 52872-2019 Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности, заменивший ГОСТ Р 52872-2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению.

Ссылка на текст действующего ГОСТа ведет на неофициальную копию в PDF, поскольку официальная ссылка с сайта Росстандарта на текст ГОСТа по доступности ведет на не доступную версию в формате JPG, что явно возбраняется этим же ГОСТом. Л логика, но я сейчас о другом, а именно: об утверждении при разработке настоящего стандарта за основу был взят актуальный на этот момент документ Web Content Accessibility Guidelines (WCAG) 2.1, содержащемся в разделе Введение недоступного ГОСТа по доступности.

Начнем с того, что вообще такое стандарт. Грубо говоря, это 2х2=4, в километре 1000 метров, а питьевое молоко продукт нормальной физиологической секреции молочных желез сельскохозяйственных животных <> без каких-либо добавлений к этому продукту, все остальное молокосодержащий продукт.

WCAG это не стандарт, а рекомендация (именно такой официальный статус носит этот документ): хорошо, если в вашем километре будет не менее 900 и не более 1100 метров, еще лучше, если 950-1050, а в идеале ровно 1000, но идеал не всегда достижим. Во WCAG это называется уровень соответствия, их три: А (удовлетворительно), АА (хорошо) и ААА (отлично). Внимание, вопрос: соответствие какому из этих трех уровней рекомендации является соответствием стандарту ГОСТу? Об этом никто из авторов не подумал.

Теперь почитаем WCAG, прямо с первого абзаца: следование Руководству сделает контент более доступным для большего числа людей с различными ограничениями. В то же время название ГОСТа: Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Хотя во WCAG прямо говорится: Веб-доступность зависит не только от доступности контента, но и поддержки функций доступности со стороны веб-браузеров и других агентов пользователя. Средства создания контента также играют важную роль в обеспечении веб-доступности. См. обзорные материалы по вопросам совместного функционирования этих компонентов веб-разработки и взаимодействия и даются отсылки к профильным нормативам по обеспечению доступности интерфейсов UAAG и ATAG.

Но авторы ГОСТ упорствуют в расширении его применения: в настоящем стандарте требования и рекомендации распространяются не только на доступность веб-контента, но и на доступность любой информации, представленной в электронно-цифровой форме, для взаимодействия с которой используются те же самые или схожие технологии. Еще раз напомню оригинальное название WCAG: Руководство по обеспечению доступности веб-контента.

Теперь самое веселое перевод WCAG, который стал ГОСТом, то есть государственным стандартом, на секундочку. Например, п.3.1.2 ГОСТа дает такое определение термина активный указатель: устройство ввода, которое может быть направлено на конкретную точку (точки) на экране, такое как мышь, стилус или палец пользователя.

Оригинал этого определения на английском языке: pointer input input device that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact.

Отталкиваясь лишь от одного из значений английского слова device устройство, прибор переводчик отнес к ним и человеческий палец, тогда как в оригинале имелось в виду другое значение этого слова способ, метод. Таким образом, в исходном тексте (и по контексту WCAG это совершенно очевидно) имелся в виду метод, способ ввода информации, а не устройство ввода. При этом остается неясным, почему в переводе указатель стал активным и чем обусловлена эта отсебятина.

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

Другим примером ошибочного перевода служит перевод термина alternative for time-based media, названного в п.3.1.4 ГОСТ альтернативным представлением медиаконтента, ограниченного по времени, и сделанный следующим образом: правильно составленный текстовый комментарий, содержащийся в контенте, синхронизированный с ограниченной по времени видео- или аудиоинформацией и предоставляющий возможность ее интерактивного использования.
Примечание: Программный сценарий (скрипт), используемый для создания синхронизированного медиаконтента, может соответствовать этому определению, если он был скорректирован для точного представления синхронизируемого медиаконтенга после его публикации
.

WCAG дает следующее определение этому термину на английском языке: document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction
Note: A screenplay used to create the synchronized media content would meet this definition only if it was corrected to accurately represent the final synchronized media after editing
.

В данном случае неверно переведен целый ряд терминов переврано абсолютно все:
  • time-based media это не медиаконтент, ограниченный по времени, а динамичный медиа-контент, представляемый пользователю не одномоментно, а последовательно, например, аудиовизуальный файл (фильм);
  • correctly sequenced text descriptions это не правильно составленный текстовый комментарий <...> синхронизированный с ограниченной по времени видео- или аудиоинформацией, а текстовое описание в правильной последовательности динамичной визуальной и звуковой информации. Другими словами, это способ предоставить пользователю с ограничениями по зрению или слуху текстовую версию информации, содержащейся в видео- или звуковом формате. При этом во WCAG не указывается, что текстовая альтернатива должна быть синхронизирована с оригинальным медиафайлом, это отсебятина авторов ГОСТа, уточняется лишь, что она должна предоставлять информацию в том же порядке;
  • providing a means for achieving the outcomes of any time-based interaction это не предоставляющий возможность ее интерактивного использования, а предоставляющий средства достижения [того же] результата взаимодействия с динамичным контентом. Например, текстовая альтернатива интерактивному меню (созданному, скажем, на Flash) должна обеспечить ту же возможность пользоваться навигацией по сайту, что и само интерактивное меню;
  • screenplay это не программный сценарий (скрипт), а обычный сценарий, используемый при постановках в театре, кино, на телевидении и т.п. Во WCAG говорится, что текстовой сценарий, например, фильма может использоваться как текстовая альтернатива динамичному медиа-контенту аудиовизуальному файлу с фильмом, но лишь в том случае, если сценарий точно соответствует итоговому произведению, а не является черновиком, в который при съемках или монтаже были внесены изменения.

Таким образом, определение термина alternative for time-based media на русском языке могло бы звучать следующим образом:
альтернатива динамичному медиа-контенту (alternative for time-based media) документ, включающий текстовое описание в правильной последовательности динамичной визуальной и звуковой информации, и предоставляющий средства достижения результата взаимодействия с динамичным контентом.
Прим: сценарий, использованный для создания синхронизированного медиа-контента, будет соответствовать этому определению, если он будет отредактирован для точного представления полученного в результате медиа-контента.


Это лишь два примера с первой же страницы ГОСТа, а подобного рода грубые ошибки, отсебятина и неточности перевода встречаются буквально в каждом его абзаце.

Тут мне могут возразить, что колхоз ГОСТ дело добровольное, применять его или нет решает владелец сайта. Но давайте послушаем мнение органов прокуратуры и судов.

Сыктывкарский городской суд Республики Коми <> рассмотрев в открытом судебном заседании гражданское дело по исковому заявлению Сыктывкарского транспортного прокурора в интересах неопределенного круга лиц к АО Комиавиатранс о приведении интернет-ресурса в соответствие с требованиями законодательства о социальной защите инвалидов, установил: <> вывод об отсутствие дискриминации по признаку инвалидности при использовании интернет-ресурса может быть сделан лишь при соответствии сайтов ГОСТ Р 52872-2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению <> решил: признать незаконным бездействие и обязать АО Комиавиатранс привести сайт в соответствие с требованиями, установленными ГОСТом Р 52872-2012 Интернет ресурсы. Требования доступности для инвалидов по зрению.

Думаете, это единичный случай? Нет, были и другие решения, по всей стране: Волгоградская область, Тверская область, Москва, далее везде. Пока мне попадались только дела, связанные с предыдущей редакцией ГОСТа, но сути это не меняет: надзор и суд считают ГОСТ в области доступности сайтов обязательным к применению.

С учетом этого владельцы сайтов оказываются перед вилами: просто забить на доступность обеспечить соответствие своих сайтов единому международному нормативу WCAG, либо безграмотному и многократно перевранному ГОСТу. В первом случае торжествует здравый смысл и обеспечивается реальная доступность сайта для инвалидов, во втором торжествует маразм и формализм, зато отсутствует повод для претензий со стороны органов прокуратуры и судебной системы.

Какой вариант соответствия выберут владельцы сайтов? Я надеюсь тот, который общепринят, для которого существуют многочисленные средства валидации, который поддерживается всеми современными средствами веб-разработки, агентами пользователя и ассистивными технологиями, а не тот, который несколько безграмотных, но амбициозных авторов при попустительстве Росстандарта решили сделать ГОСТом. Но, как уже было сказано выше, есть нюанс
Подробнее..

Перевод 5 самых неприятных фич на сайтах для слепого человека

17.09.2020 14:13:09 | Автор: admin
Вот пять самых раздражающих своей недоступностью веб-элементов, с которыми я сталкиваюсь как слепая пользователь скринридера каждый день.

Для слепых и слабовидящих людей, таких как я, доступность это не просто слово, это реальный выбор: или мы можем работать с сайтом, или не можем.

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


Скринридеры позволяют слепым и слабовидящим людям самостоятельно пользоваться компьютерами, телефонами и планшетами. В большинстве скринридеров работает движок Text To Speech (TTS), который преобразует текст с экрана в речь.

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

Вот наиболее распространённые проблемы, с которыми я сталкиваюсь ежедневно.

Неподписанные ссылки и кнопки


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

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

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

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

Изображения без описания


Вероятно, это самая распространённая проблема, с которой я сталкиваюсь при просмотре веб-страниц. Описания изображений очень важны для доступности. Они известны как alt text (альтернативный текст).

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

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

Ознакомьтесь с нашими советами по написанию alt text.

Плохое использование заголовков


Для быстрой и удобной навигации многие пользователи скринридеров перемещаются по странице с помощью различных элементов, таких как заголовки. Это отличный способ быстро находить нужную информацию. Особенно если заголовки следуют логической структуре H1, H2 и H3, которая помогает расставить приоритеты.

Логическая структура начинается с заголовка 1, затем следует заголовок 2. Заголовок третьего уровня размещается внутри заголовка 2 и так далее

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

Заголовки также помогают визуально разбить контент и улучшить читабельность. Кроме заголовков, пользователи скринридеров могут перемещаться на странице по ссылками, спискам и ориентирам WAI-ARIA.

Недоступные веб-формы


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

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

Формы обратной связи это эффективный способ для клиентов связаться с вашей компанией. И для пользователей скринридеров нет ничего более неприятного, чем неправильно помеченные эти формы.

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

Автоматическое воспроизведение аудио и видео


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

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

Решение проблемы? Убедитесь, на вашем сайте нет автоматического воспроизведения видео или аудио. Если вы действительно хотите опубликовать видео, убедитесь, что звук выключен и пользователь может остановить воспроизведение или скрыть медиаплеер.

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

Перевод CSS работа с текстом на изображениях

15.04.2021 14:13:15 | Автор: admin

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


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

Вступление

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

Слева без оверлея, справа с оверлеем.Слева без оверлея, справа с оверлеем.

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

Обзор возможных решений

Давайте посмотрим на возможные решения.

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

Решения

Наложение градиента

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

При реализации наложения градиента у нас есть два варианта:

  • Использовать отдельный элемент для градиента (псевдоэлемент или пустой <div>)

  • Применить градиент как фоновое изображение.

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

Элемент содержимого позиционируется абсолютно, его фоновым изображением служит градиент. Это означает, что размер градиента равен высоте элемента.

.card__content {  position: absolute;  /* other styles (left, top, right, and padding) */  background: linear-gradient(to top, rgba(0, 0, 0, 0.85), transparent);}

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

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

Причина в том, что градиент должен покрывать больше пространства по вертикали, поэтому должен быть выше. Если градиент равен размеру контента, он будет работать не во всех случаях. Чтобы решить эту проблему, мы можем использовать min-height, как показано ниже:

min-height к элементу .card__content.

Flexbox для перемещения содержимого вниз.

.card__content {  position: absolute;  /* other styles (left, top, right, and padding) */  display: flex;  flex-direction: column;  justify-content: flex-end;  background: linear-gradient(to top, rgba(0, 0, 0, 0.85), transparent);}

Другое решение большой padding-top, с ним не нужны min-height и flexbox.

.card__content {  position: absolute;  padding-top: 60px;  background: linear-gradient(to top, rgba(0, 0, 0, 0.85), transparent);}

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

Выглядит хорошо. Можем ли мы сделать лучше? Определённо да!

Смягчение градиента

Присмотревшись, вы заметите, где заканчивается градиент, то есть у него резкая граница.

Чтобы сделать лучше, мы можем применить смягчение градиента. Таким образом градиент будет выглядеть естественнее, и вы не заметите резких краёв в его конце.

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

К счастью, г-н Андреас Ларсен создал удобные плагины PostCSS и Sketch, которые помогают преобразовывать резкий градиент в более мягкий.

Вот градиент CSS для примера выше:

.card__content {  background-image: linear-gradient(    0deg,    hsla(0, 0%, 35.29%, 0) 0%,    hsla(0, 0%, 34.53%, 0.034375) 16.36%,    hsla(0, 0%, 32.42%, 0.125) 33.34%,    hsla(0, 0%, 29.18%, 0.253125) 50.1%,    hsla(0, 0%, 24.96%, 0.4) 65.75%,    hsla(0, 0%, 19.85%, 0.546875) 79.43%,    hsla(0, 0%, 13.95%, 0.675) 90.28%,    hsla(0, 0%, 7.32%, 0.765625) 97.43%,    hsla(0, 0%, 0%, 0.8) 100%  );}

Сравните карточки со смягчением градиента и без него.

Горизонтальные градиенты

Работа с текстом поверх изображения не может касаться только вертикального градиента, можно работать и с горизонтальным.

Вот CSS градиента для раздела выше. Чтобы добиться смягчения градиента, я использовал упомянутый ранее инструмент.

background: linear-gradient(  to right,  hsl(0, 0%, 0%) 0%,  hsla(0, 0%, 0%, 0.964) 7.4%,  hsla(0, 0%, 0%, 0.918) 15.3%,  hsla(0, 0%, 0%, 0.862) 23.4%,  hsla(0, 0%, 0%, 0.799) 31.6%,  hsla(0, 0%, 0%, 0.73) 39.9%,  hsla(0, 0%, 0%, 0.655) 48.2%,  hsla(0, 0%, 0%, 0.577) 56.2%,  hsla(0, 0%, 0%, 0.497) 64%,  hsla(0, 0%, 0%, 0.417) 71.3%,  hsla(0, 0%, 0%, 0.337) 78.1%,  hsla(0, 0%, 0%, 0.259) 84.2%,  hsla(0, 0%, 0%, 0.186) 89.6%,  hsla(0, 0%, 0%, 0.117) 94.1%,  hsla(0, 0%, 0%, 0.054) 97.6%,  hsla(0, 0%, 0%, 0) 100%);

Смешивание сплошного цвета и градиента

Я узнал об этом приёме на сайте Netflix. На домашней странице для незарегистрированного пользователя есть заголовок с большим фоновым изображением.

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

<div class="hero">  <img src="cover.jpg" alt="" />  <div class="hero__content">    <h2>Unlimited movies, TV shows, and more.</h2>    <p>Watch anywhere. Cancel anytime.</p>  </div></div>
.hero:after {  content: "";  position: absolute;  left: 0;  top: 0;  width: 100%;  height: 100%;  background-color: rgba(0, 0, 0, 0.4);  background-image: linear-gradient(    to top,    rgba(0, 0, 0, 0.8),    rgba(0, 0, 0, 0) 60%,    rgba(0, 0, 0, 0.8) 100%  );}

Вот наглядное объяснение того, как работает этот паттерн.

Наложение градиента и тень текста

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

.whatever-text {  text-shadow: 0 2px 3px rgba(0, 0, 0, 0.3);}

Наложение градиента, тень текста и непрозрачность

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

.player__icon {  opacity: 0.9;}.player__time {  color: #fff;  text-shadow: 0 0 5px #fff;}

Что в этом нового? Значки и проигрыватель имеют непрозрачность в 90 %. Это помогает им смешаться с фоном под ними. Создаётся ощущение, что элементы управления вмешаны в изображение.

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

Текст и элементы интерфейса хорошо читаются, даже когда изображение полностью беоеТекст и элементы интерфейса хорошо читаются, даже когда изображение полностью беое

Youtube делает то же самое со своими видео.

Вот что мне понравилось в подходе Youtube:

  • Тёмная рамка для каждого значка, чтобы он лучше выделялся.

  • Чёрная тень вместо белой для времени видео.

Радиальный градиент

Интересное решение, о котором я узнал от Netflix, радиальный градиент. Вот как он работает:

  1. Установите основной цвет заднего фона.

  2. Поместите изображение в верхний правый угол с шириной 75 %.

  3. Наложение соответствует размеру и положению изображения.

.hero {  background-color: #000;  min-height: 300px;}.hero__image {  position: absolute;  right: 0;  top: 0;  width: 75%;  height: 100%;  object-fit: cover;}.hero:after {  content: "";  position: absolute;  right: 0;  top: 0;  width: 75%;  height: 100%;  background: radial-gradient(    ellipse 100% 100% at right center,    transparent 80%,    #000  );}

Тем не менее команда Netflix в качестве оверлея использовала изображение .png. Конкретной причины этого я не знаю. Может быть, дело в проблеме с кросс-браузерностью или что-то в этом роде: я не тестировал решение с радиальным градиентом.

Выбор удобного пользователю цвета наложения

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

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

Тестирование

Решение нельзя считать хорошим, пока оно не протестировано, верно? Один из способов, который я использую для проверки наложения градиента, добавление белого фона ниже градиента. Если текст после этого читаемый, то градиент будет работать с любым изображением, а если нет, вам нужно настроить и улучшить его.

В приведённом выше примере я выбрал сплошной цвет под заголовком, а коэффициент контрастности составляет 4,74, такой коэффициент считается хорошим.

Работа с Firefox DevTools

Спасибо Гийсу Вейфейкену: он рассказал мне, что Firefox может тестировать цветовой контраст на градиентах. Это отличная функция.

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Перевод Доступность на iOS началась с 36 секунд

27.05.2021 16:21:56 | Автор: admin

8 июня 2009 года Фил Шиллер выступил на WWDC. Всего 36 секунд он неловко говорил о VoiceOver, Zoom, White on Black (с iOS 6 называется Invert Colors) и Mono Audio. Это были первые реальные специальные функции на платформе iPhone OS, как её тогда называли. Однако, они не произвели большого впечатления 36 секунд закончились, а потом не было никакой демонстрации или аплодисментов, и Шиллер просто перешел к описанию приложения Nike+.

Но в сообществе людей с проблемами зрения всё было иначе. Казалось, что время остановилось где-то после 1:51:54. Произошло нечто совершенно удивительное, и только несколько человек, казалось, понимали, что это значит.

Примечание. Статья переведена и адаптирована в качестве поддержки книги Миши Рубанова Про доступность iOS. Надеемся, что статья поможет вам глубже погрузиться в мир доступности и начать разрабатывать доступные приложения. В этом и поможет книга. Первые четыре главы уже доступны на сайте. Остальные будут выходить в канале Dodo Mobile. Подписывайтесь.

Что произошло 8 июня 2009 года

8 июня 2009 года Фил Шиллер два часа выступал на WWDC. В 1:51:54, после того, как он продемонстрировал голосовое управление и новое приложение Compass, на экране появился логотип Apple accessibility фигура в виде пряника с вытянутыми руками и ногами, которая используется по сей день.

Мы также очень заботимся о доступности.

Сказал Шиллер, и слайд переключился на экран настроек iPhone с перечислением функций доступности: VoiceOver, Zoom, White on Black (с iOS 6 называется Invert Colors) и Mono Audio.

36 неловких секунд и всё кончилось: никакой демонстрации или аплодисментов. Доступность не произвела большого впечатления, и от первых реальных специальных функциях на платформе iPhone OS, Фил перешёл к описанию приложения Nike+.

Но в сообществе людей с проблемами зрения всё было совсем по-другому. Время, казалось, остановилось где-то после 1:51:54 на видео. Произошло нечто совершенно удивительное: одни были вне себя от радости, другие сомневались, третьи пребывали в шоке.

У всех возникли вопросы: смогут ли теперь пользоваться iPhone люди, которым он был недоступен? Спустя 10 лет мы знаем ответ теперь у Apple лучшая мобильная доступность. Но всё это происходило не сразу, и не каждый шаг на этом пути был верным. Я бы хотел рассказать об этом пути.

В дополнении к моему аудио-документальному фильму 36 секунд, которые изменили все: как iPhone научился говорить, я собрал список основных этапов доступности iOS за последние 10 лет. Я сосредоточился на аппаратном обеспечении и ОС Apple. Обновления приложений Apple и сторонние приложения, которые открыли двери для новых способов использования iOS, тоже важны, но с ними список будет слишком длинным. Поэтому, за некоторыми исключениями, я обратился к особенностям доступности iOS. Многие основные функции имеют специальные приложения и преимущества, даже если они не подходят напрямую.

2007-2009: до появления iPhone

В 2007 году на Mac всего пару лет было доступно ПО для чтения экрана для людей с проблемами зрения Mac Screen Reader. Это теперь он называется VoiceOver, а в 2005 его представили как Tiger версии 10.4. До Tiger ни одна версия Mac OS X не предоставляла инструменты доступности.

Поэтому немного пользователей Mac с проблемами зрения были настроены услышать что-то кардинальное на MacWorld Expo в 2007 году. До Mac OS X Apple действительно предлагала несколько настроек доступности, и программу для чтения с экрана от сторонних разработчиков.

Источник: https://www.macintoshrepository.org/2483-outspoken-8Источник: https://www.macintoshrepository.org/2483-outspoken-8

Некоторые энтузиасты технологий с проблемами зрения перешли на Mac после прихода VoiceOver с Tiger. Именно они больше всего интересовались, будет ли доступен iPhone.

Потому что в 2007 году среди покупателей iPhone не было людей с проблемами зрения iPhone был им недоступен. Многие люди, как незрячие, так и зрячие, полагали, что этого не будет никогда.

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

Примечание: о проблеме холодного стекла у нас есть перевод статьи Будущее интерактивного дизайна в руках.

Весной 2008 года Apple добавила VoiceOver в iPod Nano. В то же время iTunes на Mac стал доступен для VoiceOver. Старое приложение Carbon раньше не работало с устройством чтения экрана.

Это означало, что незрячий человек теперь мог подключить Nano к iTunes, включить VoiceOver на устройстве, скопировать на него песни и использовать VoiceOver для поиска и воспроизведения.

На самом деле VoiceOver на Nano был серией аудиофайлов, созданных с помощью преобразования текста в речь, которые устройство генерировало, когда вы включали эту функцию в iTunes. Но это было гораздо лучше, чем вообще ничего.

Теперь, когда iTunes стал доступен через Mac, Apple заложила основу для доступности iPhone, сделав возможным для человека с проблемами зрения синхронизировать iPhone со своим компьютером.

Следующая остановка настоящий, доступный iPhone.

2009: iPhone OS 3, 3GS и iPod Touch

Анонс iPhone, которого все ожидали на WWDC 2009, обещал быть грандиозным. Все ждали существенного обновления с длинным списком новых функций, учитывая, что App Store существовал уже год, а за плечами Apple два года разработки. iPhone 3GS был солидным релизом, а iPhone OS 3.0 принесла такие важные и запоздалые достижения, как copy/paste.

Июнь: iPhone OS 3 и 3GS

Поспешное, позднее открытие VoiceOver, Zoom, White on Black и Mono Audio принесло только неопределенность отсутствие демо-версии не внушало доверия. Кроме того, существующие устройства даже не были совместимы с iPhone OS 3.

Чтобы получить доступ, придется подождать и купить iPhone 3GS. Пользователи, которые были довольны или, по крайней мере, смирились со своими телефонами, внезапно обнаружили, что подписались на AT&T и перешли на новый, доступный iPhone.

Как работает VoiceOver

Из четырех новых специальных функций в iPhone OS 3 самой важной была функция VoiceOver. Когда он включен, прикосновение к экрану iPhone заставляло устройство озвучивать то, что было под вашим пальцем: название приложения, пункт меню или кнопки.

Жесты для управления телефоном были изменены по умолчанию. Вместо того, чтобы нажать один раз, чтобы открыть приложение, вы должны нажать дважды, а смахивания теперь нужно выполнять двумя пальцами. Ввод текста на виртуальной клавиатуре осуществлялся сначала выбором (нажатием) клавиши, а затем двойным тапом.

VoiceOver также включал в себя интерфейсное устройство под названием ротор, которое работает немного как контекстное меню. Это один из самых гениальных и недооцененных элементов озвучки. Со временем его важность и функциональность только возросли. Чтобы его использовать, вы кладете два пальца на экран и поворачиваете как ручку громкости у магнитофона, а iOS произносит контекстные опции в ответ.

Источник: https://support.apple.com/ru-ru/HT204783Источник: https://support.apple.com/ru-ru/HT204783

Если, например, вы находитесь в Заметках, эти параметры позволяют читать по строкам, словам или символам, позволяя редактировать текст.

Остальные функции специальных возможностей

  • Масштабирование увеличивает экран iPhone. Pinch-to-Zoom был доступен в оригинальной ОС iPhone, но работал только в некоторых поддерживаемых приложениях, таких как Safari. Общесистемный зум увеличивал экран по всему интерфейсу.

  • Белый на черном (позже переименовали в Инверсию цвета) был своего рода ранним тёмным режимом, выворачивающим экранное изображение наизнанку тёмный фон со светлым текстом. Пользователям с низким зрением, чувствительные к свету, это помогает лучше видеть. Изменение настолько важно, что люди готовы терпеть, что картинки выворачиваются и превращаются в негативные изображения.

  • Моно аудио позволяло пользователю с ограниченным слухом заменить стерео выход на моно так громче и сфокусированнее, весь звук можно передать в то ухо, которое лучше слышит.

Осень: iPod Touch третьего поколения

Следующая возможность получить доступное устройство от Apple появилась с выпуском iPod Touch третьего поколения старые модели не поддерживали iPhone OS 3.

Самым большим недостатком iPod, конечно, было отсутствие навигационных функций, предоставляемых GPS-оборудованным iPhone. Навигация представляла огромный интерес для незрячих пользователей.

Тем не менее, iPod Touch был явно лучшим мобильным устройством с поддержкой Интернета, доступным для людей с ограниченными возможностями, при ограниченном бюджете.

2010: iPad, iBooks, iPod Touch

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

Весна: iPad первого поколения и iBooks

Но ещё одна особенность первого iPad также была интересна людям с ограниченными возможностями чтения iPad был первым устройством Apple, с приложением iBooks и iBooks Store. Можно не только добавить любую книгу Apple на iPad, но и использовать VoiceOver, чтобы прочитать её вслух. Это означало, что если книга не была доступна в шрифте Брайля, на ленте или в другом доступном формате, владелец iPad всё равно мог её изучить.

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

Осень: iOS 4

Ввод текста одним касанием (Touch typing). Сначала он был представлен как второй режим набора текста на iPad. Сенсорный ввод на виртуальной клавиатуре работает быстрее для пользователей VoiceOver, чем стандартный. Не нужно выбирать, а затем дважды нажимать клавишу на клавиатуре, чтобы ввести её. Теперь это проще: опустите палец на клавиатуру, наведите на нужную кнопку и отпустите палец для ввода буквы под ним. Разделенное нажатие делает сенсорный ввод гораздо эффективнее с помощью VoiceOver. Перейти в такой режим набора можно через ротор.

В iOS 4 добавили веб-ориентированный ротор с определенными опциями для навигации по элементам в Safari. Эта функция в конечном итоге будет свернута в ротор общего назначения, но iOS 4 это то место, где впервые появились веб-опции.

Использование ротора в Safari.Использование ротора в Safari.

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

Дисплей Брайля. Источник: http://com-v.ru/tiflomarket/braille-edge-40/90_m_bild1_brailleedge/Дисплей Брайля. Источник: http://com-v.ru/tiflomarket/braille-edge-40/90_m_bild1_brailleedge/

Количество таких дисплеев, поддерживаемых iOS, увеличивается с каждой версией, и Apple ведет текущий список в Интернете.

С помощью клавиатуры Брайля можно печатать шрифтом Брайля, а необычной. Можно также перевести разговорный интерфейс VoiceOver на шрифт Брайля и передать его через дисплей Брайля: точки выступают из экрана, проведя по нему пальцем можно прочитать предложение. Это позволяет человеку, у которого проблемы и со зрением и со слухом, использовать устройство iOS с VoiceOver. Поддержка дисплеев Брайля продолжает развиваться и по сей день.

Доступность получила важные обновления в iOS 4, некоторые из которых придали легитимность iOS в глазах скептиков, которые предпочитали Windows.

2011: iPhone 4s, Siri и iOS 5

iPhone 4S был первым телефоном с Siri. Это не функция доступности, как таковая, но человек с физической или зрительной инвалидностью может управлять iOS голосом, что быстрее и проще.

Осень: iOS 5

iOS 5 освободила всех пользователей от необходимости настраивать устройство с компьютера, а пользователи VoiceOver получили возможность выполнять свою собственную настройку с помощью программы чтения с экрана. Начать настройку можно было через iTunes, поскольку Mac OS X также включала программу чтения с экрана.

Тройной щелчок. Незрячим людям стало проще благодаря корректировке поведения кнопки Домой. Раньше тройной щелчок вызывал выбор между масштабированием и голосом за кадром. К сожалению, пользователь VoiceOver с проблемами зрения не мог определить нужную опцию. В iOS 5 теперь можно было сделать тройной щелчок во время процесса установки, чтобы вызвать VoiceOver он включался по умолчанию.

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

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

Выбор речи и автотекст. В iOS также добавили эти новые функции речи. При включенном Speak Selection можно выбрать текст в любом месте iOS появившееся меню теперь включает кнопку Speak Selection. Speak Auto-Text делает именно это, когда применяется автокоррекция или автокапитализация. Обе эти функции речи используют тот же выбор голосов, что и VoiceOver можно выбрать голос, который вы хотите использовать, независимо от VoiceOver, и скорость.

VoiceOver Item Chooser также дебютировал в iOS 5. При посещении веб-страницы с множеством ссылок и элементов контента вызовите средство выбора элементов, чтобы вызвать алфавитный список элементов на странице. Если знаете, что вам нужно, вводите текст, чтобы сузить поиск. Затем дважды коснитесь элемента, который хотите выбрать.

Средство выбора элементов экономит время при навигации по знакомому сайту. В качестве альтернативы выбору элементов для пользователей Bluetooth-клавиатуры также был добавлен ряд веб-специальных сочетаний клавиш VoiceOver, например, набрав H (от heading) на подключенной клавиатуре можно переходить по заголовкам

Обнаружение лиц. Дебютировало в iOS 5 в приложении камеры. При включенном VoiceOver наведите устройство на объект или объекты, и VoiceOver покажет, сколько лиц видит камера и где они находятся в кадре.

Ротор. Прежние функции веб-ротора были свернуты обратно в основной ротор. Добавили больше вариантов ротора, а также больше инструментов для управления его поведением. Можно изменить порядок элементов ротора, а также добавить или удалить элементы, чтобы упростить и настроить то, что там появилось.

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

Особенности слуха

Вибрация. iPhone, конечно, всегда поддерживал пользовательские мелодии звонка, но iOS 5 принесла шаблоны вибрации. Если у вас есть проблема со слухом или вы просто хотите пофантазировать с вибрационными паттернами для отдельных абонентов, выберите один из них или наберите свой собственный.

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

Новый режим слухового аппарата. Позволил устройствам iOS лучше работать со слуховыми аппаратами Bluetooth. Это было началом расширенной поддержки слуховых аппаратов, которая расцветет в более крупную инициативу Made for iPhone для слуховых аппаратов. Начиная с iPhone 5, они сертифицированы как совместимые со слуховыми аппаратами (Hearing Aid Compatible, HAC) Федеральной комиссией по связи США.

2012: iOS 6

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

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

Осень: iOS 6

Home-Click Speed. Позволяла пользователю регулировать чувствительность кнопки Home, что облегчало человеку с моторной задержкой эффективное нажатие на неё. Guided Access даже получил демо-версию WWDC Keynote.

Контекстные действия в iOS 6. У некоторых элементов появились дополнительные действия. Чтобы переключиться на них проведите пальцем вверх или вниз, двойное нажатие выполняет действие. Например, так можно пометить письмо как прочитанное или удалить. Это немного похоже на использование ротора VoiceOver, но без необходимости делать жест открытия ротора.

Карты. Получили серьезное обновление в iOS 6. Pause to Follow позволяет найти и выбрать улицу, а затем провести пальцем когда вы слышите Pause to Follow.

Применение Pause to Follow на карте.Применение Pause to Follow на карте.

Действие даёт представление в каком направлении проходит дорога, и насколько она прямая или извилистая. Звуковая обратная связь направляет, когда вы идете по улице, и визуально подсвечивается для людей с низким зрением. Ротор VoiceOver также включал в себя пункт Точки интереса позволяющий пользователю пролистывать близлежащие важные и интересные места, чтобы найти конкретный объект или просто просмотреть свое окружение.

Guided Access. Новинка в iOS 6. Позволило ограничить доступ к элементам iOS, например, отключить кнопки громкости или запретить пользователям доступ к определенным приложениям. Управляемый доступ позволяет учителям сосредоточить внимание учащихся, часто детей со спектром аутизма. Вызовите управляемый доступ и свободно передайте ученику iPad, который может запускать только то образовательное приложение или обучающую игру, которую вы хотите использовать. Также можно замаскировать кнопки или другие элементы интерфейса в выбранном приложении.

AssistiveTouch. AssistiveTouch делает ключевые элементы управления устройствами доступнее.

AssistiveTouchAssistiveTouch

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

2013: iOS 7

Apple лихо переработала внешний вид интерфейса iOS и практически всех своих собственных приложений. Сквеоморфизм исключили, а тонкие шрифты, прозрачные слои и анимация добавили.

Шаг назад с iOS 7

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

Благодаря отрицательной реакции на iOS 7 Apple исправила то, что сломала: откатила первоначальный дизайн ОС и добавила настройки доступности, которые могли бы компенсировать проблематичность определенных элементов дизайна. Например, они включали в себя формы кнопок, уменьшающие движения и метки включения/выключения. Кроме того, iOS 7 представила увеличенную контрастность, полужирный текст и настройку размера шрифта. Они помогли компенсировать проблемы 7.0.

Все выровнялось в iOS 7.1. Это был единственный релиз iOS, созданный специально для слабовидящих пользователей вроде меня.

Более крупный текст используется внутри сообщений.Более крупный текст используется внутри сообщений.

Доступность на виду. Несмотря на недостатки, iOS 7 была большим шагом в сторону доступности. Это видно, если заглянуть внутрь приложения Настройки. Доступность переместили с самого низа Общей категории почти наверх. Это важно и на эмоциональном уровне для пользователей, и на практическом уровне для тех, кто не тратил много времени на использование инструментов доступа, но планировал исследовать теперь, когда iOS 7 добавила так много.

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

Обновления. iOS 7 представила множество основных обновлений интерфейса, включая Центр управления и усиленный переключатель приложений. Они были сразу же доступны VoiceOver и AssistiveTouch, а также новому интерфейсу управления коммутатором.

Динамичный Текст. Функция Увеличенный текст была доступна в iOS 6, хотя и не сильно повлияла на iOS. Можно выбрать один из шести увеличенных размеров текста и увидеть их в нескольких приложениях, таких как Сообщения или Почта.

Более крупный текст в iOS 7 и поздних версиях это пользовательский интерфейс для Динамичного Текста. Если разработчик поддерживает Динамичный тип в приложении, пользователь может использовать ползунок Размера текста, чтобы сделать его больше или меньше. Даже Apple не поддерживала Динамический тип во всех своих приложениях iOS 7, но постепенно исправила. Многие другие разработчики приняли эту функцию, но не все.

Слуховые аппараты iPhone. Apple никогда не создавала собственные слуховые аппараты, но работала с производителями, чтобы увеличить количество доступных продуктов MFi программу Made for iPhone. Технологические усовершенствования в характеристиках Bluetooth Low Energy (BLE) и согласованные усилия Apple распространили MFi на слуховые аппараты, которые компания начала сертифицировать как совместимые с устройствами iOS.

Субтитры. Фильмы и телепередачи, купленные в iTunes или приобретенные из других источников, можно просматривать с подробными субтитрами или обычными. В iOS 7 появился интерфейс для настройки стиля и размера текста, появляющегося на видео с субтитрами.

Рукописный ввод VoiceOver. Поддержка рукописного ввода VoiceOver позволяет пользователю VoiceOver вводить текст, рисуя печатные текстовые символы пальцем на экране. Есть жесты для обозначения пробела и для обычных знаков препинания. Можно использовать рукописный ввод для поиска приложений на главном экране. Войдите в режим рукописного ввода с ротором, нарисуйте первую букву приложения и iOS найдёт все подходящие. Рукописный текст также можно использовать для навигации по веб-страницам.

Switch Control. AssistiveTouch был частью iOS начиная версии 6. Switch Control расширил идею интерфейса, который поддерживает пользователей с моторными задержками.

Сканирование главного экрана с помощью переключателя управления.Сканирование главного экрана с помощью переключателя управления.

С его помощью мы используем:

  • внешние переключающие устройства, которые представляют собой кнопки с двумя состояниями;

  • сам экран iOS в качестве переключателя или даже камеры: глядя влево или вправо, мы активируем переключатель на основе камеры.

Чтобы работать с переключателями, мы назначаем каждому из них определённую функцию, например нажатие или щелчок влево, открытие Центра управления или вызов Siri. В режиме Управления переключателем iOS сканирует элемент за элементом на экране до тех пор, пока не будет нажат переключатель для активации или иного воздействия на этот элемент.

Многие пользователи Switch Control оснащают свои iOS-устройства несколькими устройствами. А iPad, установленный на инвалидном кресле вместе с переключателями, может создать очень эффективную iOS-установку для человека с тяжелыми двигательными нарушениями.

Быстрый доступ к специальным возможностям. Раньше эта функция называлась Triple-Click Home. Позволяет включать и выключать специальные возможности с помощью тройного щелчка. Теперь на тройное нажатие можно добавить несколько специальных функций. При срабатывании iOS покажет меню из тех, которые вы включили.

2014: iPhone 6 и 6 Plus

Первые большие айфоны включили новую функцию под названием Display Zoom.

Это не функция доступности, но она увеличивает вид экрана, уменьшая разрешение. На экране появляется меньше значков приложений, а на некоторых экранах iOS-текст больше. Масштабирование дисплея можно сочетать с функцией масштабирования специальных возможностей или по отдельности.

Осень: iOS 8

Несколько новых функций в iOS 8 были важны для доступности.

Клавиатура QuickType. Предсказывала текст и отображала панель с предложениями по набору текста над виртуальной клавиатурой.

Новый режим набора текста прямым касанием позволял пользователю VoiceOver положить обе руки на виртуальную клавиатуру и просто начать печатать. QuickType, автокоррекция и собственное ноу-хау VoiceOver вместе помогают исправлять ошибки набора с высокой точностью. Естественно, это экономит много времени и сил, и значительно улучшает набор текста с помощью прямого прикосновения, особенно для пользователей iPad.

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

Использование контроллера масштабирования.Использование контроллера масштабирования.

Алекс. В iOS 8 из Mac OS X пришёл голос Алекс. У Алекса есть естественное звучание дыхания во время разговора, что намного удобнее чтения длинных текстов, чем более старые альтернативы из iOS 5.

Оттенки серого. В iOS 8 появился Режим оттенков серого для некоторых людей отсутствие ярких цветов на экране легче для восприятия.

Обновления Guided Access. Обновления включают таймеры, поддержку активации Touch ID и улучшенный масштаб: новый контроллер масштабирования позволял пользователю выбирать область экрана для масштабирования, регулировать скорость масштабирования и использовать цветовые фильтры для адаптации к дальтонизму.

Ввод с экрана Брайля. Как и функция рукописного ввода, экранный ввод Брайля облегчает ввод текста на экране.

Вместо того, чтобы рисовать символы пальцем, мы используем метафору ячеек Брайля для ввода ячеек Брайля на экране. Это полезная функция для тех, у кого нет удобного дисплея Брайля при работе с iPhone.

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

Экран Speak используется внутри Safari.Экран Speak используется внутри Safari.

2015: Apple Watch и iOS 9

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

3D Touch. Функция появилась на новых iPhone в iOS 9. Несмотря на альтернативные голосовые жесты и необходимость сильно нажимать, чтобы вызвать 3D Touch, пользователи VoiceOver с поддерживаемыми телефонами получили доступ к жестам 3D Touch первого уровня, а также Peek и Pop.

Многозадачность iPad. Появились новые жесты, которые позволяли пользователю VoiceOver работать с Split View или Slide Over. Опять же, пользователи специальных инструментов могли пользоваться новыми инструментами прямо из коробки.

С точки зрения доступности iOS 9 не выдающаяся версия. Но в ней появились новые настройки для людей с физическими недостатками, а также некоторые обновления VoiceOver. Вот исчерпывающий список обновлений, связанных с VoiceOver.

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

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

Switch Recipes для Switch Control. При использовании управления переключателем каждый переключатель выполняет одну функцию. Функция Switch Recipes эффективно позволяет пользователю создавать комбинации действий.

Изменения Ротора выбора текста VoiceOver. Изменения в роторе VoiceOver облегчили выбор текста по символу, слову, строке или странице.

2016: iOS 10

Изменения в iOS 10 в основном косметические. Но не все.

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

Новый редактор произношения. Позволяет произносить или вводить имя так, как его должен произносить VoiceOver, и сохранять правильное произношение. А с VoiceOver audio routing можно передавать звук на устройство по вашему выбору, например на Bluetooth-динамик. Теперь Switch Control позволяет пользователям управлять устройствами, подключенными к устройству iOS, включая Apple TV.

Описание изображения VoiceOver. iOS 10 позволяла выбрать изображение на фотографиях или в потоке сообщений и заставить VoiceOver описать его характеристики. Конечно, VoiceOver это не алгоритм на основе машинного обучения, поэтому получались описания, например, одно лицо, размытое, темное или чёткое, хорошо освещенное.

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

Когда лупа стала функцией iOS, она была доступна непосредственно из Центра управления или с помощью ярлыка специальных возможностей. Мы могли применять цветовые фильтры, как это часто бывает в электронных портативных лупах, ориентированных на рынок слабовидящих.

Цветовые фильтры. iOS предлагала переключение оттенков серого с iOS 8, но теперь появились цветовые фильтры, предназначенные для настройки вида экрана в зависимости от потребностей пользователей с тремя распространенными формами дальтонизма.

Программное обеспечение TTY. Пользователи iPhone всегда могли подключать свои телефоны к TDD (телекоммуникационное устройство для глухих) если у них был соответствующий аппаратный адаптер. Начиная с iOS 10, можно звонить или отвечать на звонок TTY без допоборудования, а также сохранять стенограммы звонков.

2017: iOS 11

iPhone X первое iOS-устройство без кнопок Home. Это повлияло на доступность: отсутствие кнопки Home изменило жесты по умолчанию, используемые для таких вещей, как open Control Center или App Switcher.

Face ID. Но не только из-за этого стало хуже Face ID создал проблемы для некоторых незрячих пользователей.

iOS 11 была первой версией iOS, которая поддерживает устройства Face ID. Некоторые люди с ограниченными возможностями, особенно незрячие и с протезами глаз, не могут уделять необходимое внимание датчику Face ID. Поэтому iOS добавила переключатель, который позволяет разблокировать телефон без зрительного контакта. Из-за этого Face ID вызывает споры в сообществе людей с проблемами зрения из-за предполагаемого риска безопасности. Также некоторым слепым пользователям трудно заставить Face ID работать.

Однако функция всё равно полезна. Переключатель Require Attention, который включен по умолчанию (функция безопасности) предотвращает разблокировку телефона, если он просто проходит перед лицом своего владельца. Выключение этого переключателя позволяет большему количеству незрячих людей разблокировать телефон с помощью Face ID. Но пользователь потенциально рискует получить телефон разблокированным без их согласия. При настройке устройства, оснащенного Face ID, с помощью VoiceOver пользователю предлагается оставить его включенным или выключить.

Новые возможности. iOS 11 также принесла несколько новых и обновленных версий специальные возможности, например, поддержку VoiceOver для перетаскивания и специальные жесты VoiceOver для владельцев iPhone X. VoiceOver также добавил новый метод перемещения приложений, который был частью iOS 10. Теперь можно использовать ротор для выбора и перетаскивания нескольких приложений в любое место на любом домашнем экране.

Смарт-инверсия цвета. Invert Colors появились ещё в iOS 3, и отображали всё как обратное нормальному внешнему виду. Но Smart Invert Colors отображает изображения как положительные, а не отрицательные, до тех пор, пока рассматриваемое приложение поддерживает его.

Вы все еще можете выбрать между Invert Colors и Smart Invert Colors и добавить их в ярлык специальных возможностей.

Но меню или фон некоторых приложений неправильно отображаются в цветах, контрастирующих с текстом или значками поверх них в режиме Smart Invert Colors. Это даже иногда происходит в приложениях Apple.

В основном это проблема разработчиков, которые не задумывались как будет вести себя их интерфейс и изображения при включенном Smart Invert Colors. Сочетание этих двух проблем причина того, что ни одна из опций инвертирования не работает как эффективный тёмный режим для iOS. Из того, что я видел, тёмный режим предлагает разработчикам возможность использовать затемнение и слои для настройки внешнего вида интерфейса. Это может быть полезно и для пользователей Smart Invert Colors, а также для общего понимания того, что люди, не имеющие слабого зрения, пытаются использовать iOS в тёмном режиме.

Type to Siri. Если вы не можете говорить или это неудобно, Type to Siri даёт возможность выдавать команды Siri с клавиатуры. Можно печатать с виртуальной, с Bluetooth-клавиатуры или в шрифте Брайля с дисплея Брайля.

2018: iOS 12

Все выпуски iOS содержат ошибки. Пользователи специальных возможностей часто находят те, которые относятся к функциям, что они используют каждый день и ждут, пока Apple их исправит, например, когда шрифт Брайля и VoiceOver глючили в iOS 11. Но, как и iOS в целом, iOS 12, казалось, исправила много проблем доступности и добавила некоторые новые функции.

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

Живое Прослушивание. Уже некоторое время можно использовать микрофон iPhone как усилитель окружающего звука, посылая звук на слуховой аппарат. В iOS 12 функция Live Listen была расширена до AirPods. Теперь можно слышать собеседника даже если вокруг шумно.

2019: iOS 13

Доступности уделили много внимания на WWDC 2019. Вот несколько важных особенностей.

Голосовое управление. Последняя и совершенно новая функция специальных возможностей, анонсированная для iOS 13, а также Mac OS Catalina, имеет очень старое название. До появления Siri в iOS была функция голосового управления (и до сих пор существует). Но можно было только инициировать телефонный звонок или воспроизвести песню с помощью голосовой команды.

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

Тёмный режим. Мы не знаем всех различий между грядущей основной функцией тёмного режима и Smart Invert Colors. Apple заявила, что разработчики смогут использовать многоуровневый подход к своим интерфейсам, так что не все экраны или их части должны будут иметь одинаковый тёмный оттенок. Выглядит как улучшение по сравнению со Smart Invert Colors. Если разработчики будут тщательно применять слои, тёмный режим может стать подходящей альтернативой умным инвертированным цветам для некоторых людей с плохим зрением, которые его используют.

Итог

Если вы измеряете доступность iOS по количеству доступных сегодня функций, 2009 год кажется примитивным временем. В тот год на программном слайде WWDC Фила Шиллера появилось всего четыре пункта. Но один из них VoiceOver точно революционизировал реальную доступность на iPhone почти сразу.

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


Полезные материалы:

Статьи по VoiceOver:

Voice Control и VoiceOver: как адаптировать приложение для незрячих или неподвижных.

VoiceOver на iOS: каждый контрол ведёт себя по-разному.

VoiceOver на iOS: решение типовых проблем.

Другие полезные:

Зачем и как мы пишем постмортемы по критичным багам.

Будущее интерактивного дизайна в руках.

Как выйти на китайский рынок с mini-app для WeChat, чтобы не прогореть.

На пути к 10x инженеру: шорткаты, сниппеты, шаблоны.

Подписывайтесь на Dodo Engineering chat в Телеграм будем обсуждать статью, и на канал там новости и разное интересное.

Подробнее..

5accessibilityинструментов вChromeDevTools

29.11.2020 14:18:58 | Автор: admin

Введение

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

Небольшой дисклеймер, я знаю, что многие из вас активно пользуютсяDevTools, тем не менее, я напомню, что для открытияDevToolsудобно использовать сочетание клавишCmd+Shift+ C /Ctrl+Shift+ C.

Accessibilityinspector.

Помимо DOM браузер строитAccessibilityTree(AOM,AccessibilityObjectModel) или Дерево специальных возможностей (чуть подробнее тут). СоответственноAccessibilityinspectorпозволяет просматривать информацию в этом дереве, аналогично тому, как вы просматриваете структуру DOMдевера, во вкладкеElements.

По большей части AOM содержит информацию из ARIA иroleатрибутов, именно с помощью них программы экранного доступа пытаются определить предназначение DOM элемента.

Найти этот и инструмент можно во вкладкеElements, в дополнительной вкладкеAccessibility.

Accessibilityinspector в DevToolsAccessibilityinspector в DevTools

Эмулятор плохого зрения.

С помощьюDevToolsвы можете понять, как видят ваш сайт пользователи с различными нарушениями зрения.

Для того чтобы включить эмуляцию проблем со зрением откройтеDevTools, кликните на три точки на верхней панели. В выпадающем списке выберете менюMoretools, дальшеRendering. В низу откроется дополнительная панель, прокрутите ее до самого конца, там будетпукт Emulatevisiondeficiencies.

Результат работы эмулятора плохого зренияРезультат работы эмулятора плохого зрения

На момент написания статьиDevToolsэмулирует следующие нарушения:

  • Нечеткое зрение

  • Протанопияищи цветовая слепота (помните такие тесты в ГИБДД где среди кружочков необходимо увидеть цифру?)

  • Дейтеранопия - частичная цветовая слепота, в основном к зеленому цвету.

  • Тританопия- частичная цветовая слепота обычно в синежёлтых, фиолетовокрасных цветов.

  • Ахроматопсия илидальтонизм - полная цветовая слепота

Я думаю, очевидно, что данный список не в полной мере покрываетпроблеммысо зрением, возникающие у отдельных людей, тем не менее размещая текст на каком-то цветном фоне, стоит проверить его читабельность..

Lighthouseумеет находить очевидные проблемы на вашем сайте, в том числе и проблемы с доступностью. Поскольку в данной статье мы рассматриваем только доступность, то отключим все остальное и протестируемХабрна наличие проблем сAccessibility.

Настройка и результат работы Lighthouse на сайте habr.comНастройка и результат работы Lighthouse на сайте habr.com

Lighthouseпроверяет такие вещи как:

  • ARIA - атрибуты

  • ROLE - атрибуты

  • Контраст

  • Langатрибуты в HTML

  • Tabindexна формах

  • Наличие описания в атрибутахalt

  • И многое другое

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

Контрастность

Когда речь заходит о доступности контраст очень важен. Это можно понять, если применить эмуляцию не четкого зрения.

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

Что узнатькоэфициентконтрастности какого-либо элемента необходимо открытьDevTools, затем выберете любой текстовый элемент, и найдите CSS свойствоcolor

Инструмент измерения контрастности в DevToolsИнструмент измерения контрастности в DevTools

Если посмотреть на скриншот, то можно выделить три основных показателя:

  • текущее значение контраста

  • Минимально допустимое значение контраста (АА)

  • Достаточно значение контраста (ААА)

Inspectelementtooltip

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

InspectelementtooltipInspectelementtooltip

ВInspectelementtooltipвыводится сводная информация о выделенном элементе, в том числе общая информация по доступности.

Заключение

Готовя статью, я наткнулся на цитату, которая отлично передает мое отношение к вопросу доступности сайтов

Доступность не обязана сразу быть идеальной, она просто должна быть немного лучше, чем вчера.Леони Уотсон на FronteersConf

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

Подробнее..

Зачем Chrome Dev Tools дизайнеру

13.09.2020 00:04:43 | Автор: admin

На Хабре есть несколько статей про полезные фишки Chrome Dev Tools, но давайте добьём этот список в разрезе пользы для дизайнеров, которые хотят потестировать готовую вёрстку своих макетов.

Просмотр адаптива

Самая полезная и известная функция, но не упомянуть не могу. Проверить, как фронтендер заверстал ваши макеты под мобилку, можно просто переведя браузер в режим мобилки. Есть предзаданные размеры популярных мобильных устройств и можно задать свои собственные.

Если в готовом списке нет нужных вам устройств, то может они просто не включены. Включить их можно нажав на Edit и выбрать дополнительные устройства.

Просмотр характера анимации

Наверняка у вас бывали случаи, когда анимация реализована, но в ней что-то не то. А что конкретно сказать не можете, т. к. успеть разглядеть характер анимации невозможно. Либо вам просто интересно, как реализована анимация на других сайтах. В Dev tools есть возможность посмотреть на анимацию в конкретных цифрах и сравнить с тем что было у вас в макете. На примере ниже, слева показана Карта Гугл и анимация фотографии, выбранной локации. Открыв вкладку Animations можно увидеть какие конкретно есть анимации на странице и, выбрав нужную, увидеть характер анимации, или просто замедлить её нажав на кнопку процента (на примере 25%). Мы видим, что анимация фото состоит из двух видов анимации прозрачность (opacity) и проявление цвета (filter). С этими анимациями можно поиграться продлив или замедлив их (почти как в Principle). Более полно про эту вкладку расписано тут.

Просмотр веса и размера графики

Бывает, что страница довольно сильно подтормаживает хотя графики на ней может быть не много. Быстро проверить, что же так много весит можно зайдя во вкладку Sources, выбрать папку в которой лежат все картинки и просмотреть сколько весит каждая из них. Я таким образом часто удивлялся размерам фоток, которые стояли на фоне, например.

Проверка скорости загрузки при плохом интернете

В России есть беда слишком хороший и дешёвый интернет. Из-за этого сложно проверить, как будет грузиться ваш классный дизайн в глухих деревнях, где пока ещё 3G. В Dev Tools вы легко можете сэмулировать урезанную скорость инета выбрав её на вкладке Network или вообще проверить, как страница отрабатывает отсутствие интернета и выводится ли там иллюстрация, которую вы так долго рисовали.

Проверка контрастности текста

Я рекомендую проверять контраст текста ещё при дизайне. Например, в Фигме есть плагин Contrast. Но бывает, что либо забыл это сделать, либо на вёрстке цвета смотрятся немного не так как на дизайне и тем более на плохом мониторе. В Dev tools вы можете не только узнать конкретный цвет, но и получить ответ соответствует ли его контраст рекомендациям доступности для людей с плохим зрением (WCAG). Эти рекомендации имеют три уровня доступности: ААА отлично; АА нормально; А плохо. Dev tools рисует две линии, показывая порог доступности. Ниже этих линий самый оптимальный контраст.

Но эта оценка может быть применена только к текстовым элементам. Т. е. тем, которые обёрнуты в любой текстовый тэг (H, p, span, a и пр.). Все остальные элементы будут отображать информацию о недоступности оценки контраста. Но верстальщику писать текст не в каком-либо текстовом тэге это уже за гранью добра и зла (хотя всё равно встречается).

Проверка доступности интерфейса

В оценку доступности интерфейса для слабовидящих входит много факторов, начиная от дизайн и заканчивая кодом. Если дизайн вы можете оценить и самостоятельно, то код оценить сложнее и в этом поможет Dev tools. На вкладке Lighthouse нажмите на кнопку Generate report и увидите общую оценку доступности. На этой вкладке вы можете указать версию для оценки мобильную версию или ПК-версию, а так же указать другие параметры типа SEO, быстродействия страницы и пр.

Кликнув по оценке вы увидите список рекомендаций, что улучшить и как. Можете отправить эти рекомендации вашему фронтендеру если доступность интерфейса важна для проекта.

Виртуальный переезд

Если сайт как-то меняет дизайн или контент в зависимости от местоположения юзера, то проверить это бывает сложно. Можно, конечно найти VPN-сервис, в котором можно выбрать конкретную страну, но во-первых надо искать; во-вторых чаще всего это определённый набор стран, а не любой на ваш выбор; и в-третьих это именно другие страны, а не города. В Dev tools можно выбрать любую страну из заданных или создать любую страну или город указав их широту и долготу. Также, можно эмулировать "Местоположение не определено" и посмотреть выводит ли сайт то что вы нарисовали для такого случая. Ниже пример, как это работает на Яндекс Картах. Москва там уже была, а Питер я добавил сам указав широту и долготу: 59.898092; 30.307113.

Но чтобы эта функция работала надо разрешить сайту отслеживать ваше местоположение. Как ни странно, эта функция немного поломала работу Гугл Карт. Именно поэтому в примере я показываю Яндекс Карты. В Гугле при включении этой функции у меня просто пропала кнопка "Моё местоположение" на карте.

Если у вас по-умолчанию нет панели с выбором локации, то открыв Dev tools, нажмите Command+Shift+P, откроется поисковая строка, введите в неё Sensors.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru