Эпизод 4 подкаста Smashing с Хейдоном Пикерингом: что такое инклюзивные компоненты?

Сегодня я говорю с Хейдоном Пикерингом о его новой книге « Инклюзивные компоненты ». Хейдон известен своими работами и статьями о доступности — так что же на самом деле означает «инклюзивный дизайн» и где компоненты вступают в игру? Хейдон объясняет все это и многое другое в этом эпизоде. Вы можете слушать ниже или подписаться везде, где вы получаете свои подкасты.

Показать примечания

• Книга Инклюзивные компоненты от Smashing Magazine
• Проект Хейдона Every Layout с Энди Беллом
• Сайт Хейдона Heydonworks
• Хейдон в Твиттере

Стенограмма

Дрю Маклеллан: внештатный консультант по веб-доступности, дизайнер интерфейсов и писатель. Его работа посвящена дизайну доступного пользовательского интерфейса, а также написанию и редактированию для Smashing Magazine. Он является автором известной книги о разработке доступных веб-приложений «Приложения для всех» и только что выпустил новую книгу «Инклюзивные компоненты», в которой снова рассказывается о том, как создавать доступные веб-интерфейсы в Smashing Magazine. Так что он явно эксперт в области доступного дизайна, но знаете ли вы, что он был первым человеком мужского пола, прыгнувшим по мосту Харбор-Бридж в Сиднее на скоростной лодке? Мои Smashing друзья, пожалуйста, поприветствуйте Хейдона Пикеринга. Привет, Хейдон. Как твои дела?

Хейдон Пикеринг: Я разбиваю. Я на бренде.

Дрю: Сегодня я хотел поговорить с вами о теме вашей новой книги «Инклюзивные компоненты».

Хейдон: Да.

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

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

Хейдон: На ​​самом деле, он сделал некоторые компоненты, очень маленькие компоненты, которые использовались для регулирования тока, поступающего в электромагниты в ЦЕРНе. И он очень верил в меня в детстве, потому что он заставил меня припаять для них некоторые биты. Я думаю, что эта партия уже устарела, так что не беспокойтесь больше о моей плохой пайке, моей плохой подростковой пайке, связанной с CERN. Но да, я думаю, что это аналог… О, там слишком много аналогов.

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

Хейдон: Итак, идея заключалась в том, чтобы привнести доступность в дизайн-системы, но в то же время мыслить системно, когда дело доходит до попытки решить проблему доступности. Подумайте о решении одной проблемы в одном месте с точки зрения доступности и убедитесь, что шаблон просто распространяется по шаблону [неразборчиво 00:03:16] в дизайн-системе в целом.

Дрю: С практической точки зрения, как на самом деле выглядит работа, основанная на компонентах? Каким может быть пример компонента?

Хейдон: Итак, существуют разные способы понимания и кодирования компонентов. Я обычно сразу перехожу к мельчайшим деталям, минуя концептуальные вещи, и думаю о том, как я мог бы организовать код. На самом деле я стал уделять много внимания пользовательским элементам, или если не пользовательским элементам, то обычным элементам, но с каким-то поведением JavaScript, прикрепленным к ним в виде изолированного, компонентного способа. Мне очень нравится идея взаимозаменяемых компонентов. Под этим я подразумеваю, что их можно использовать в разных фреймворках, системах, подходах и технических стеках. И пользовательские элементы в этом хороши, потому что они нативные. Вы можете определить их в одном месте, а затем их можно использовать, скажем, в реагирующем приложении, или их можно использовать в приложении просмотра, или их можно использовать в приложении angular, или любой другой более крупной технологии управления состоянием, которую вы используете. с использованием.

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

Дрю: Я имею в виду, что на практике мы говорим о том, что компонент может быть чем-то вроде поля формы?

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

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

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

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

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

Хейдон: Так что это просто попытка подумать обо всех этих вещах в одном месте. И на самом деле, книга просто моя, это мой мыслительный процесс, когда я подхожу к каждому из них. Так что я сделал это как блог для начала. И каждый паттерн или каждый компонент — это запись в блоге, а в тексте я просто говорю: «Итак, давайте теперь решим эту потенциальную проблему. Как нам это сделать? Хорошо, мы проверили это. Думаю, у нас там все в порядке». И я ни в коем случае не пытаюсь сказать, что они идеальны и что я все предусмотрел, потому что это невозможно.

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

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

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

Хейдон: Я имею в виду, что проект Every Layout, хотя он больше касается визуального дизайна и макета, всецело направлен на то, чтобы попытаться сделать эти маленькие примитивы CSS, эти маленькие примитивы макета таким образом, чтобы они могли как бы самоуправляться алгоритмически. Это для того, чтобы можно было вынуть их из узкого столбца и поставить потом в широкий столбец и тогда будет, код сам определит, сколько элементов в ряд должно быть или он должен перенастроить себя как-то по-другому. Потому что мы не можем позволить себе постоянно вмешиваться, и я думаю, что это должна быть система, которая является своего рода самопознающей и разумной.

Хейдон: Всегда есть вещи, о которых можно забыть. Так что, возможно, вы создаете интерфейс с вкладками, у вас есть ряд вкладок, вы выбираете между вкладками, и вкладка соответствует панели вкладок, которая что-то открывает. А потом придет кто-нибудь и скажет: «Ну, а что, если я хочу поместить интерфейс вкладок внутри интерфейса вкладок или какой-то другой компонент внутри интерфейса касания?»

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

Дрю: Можно ли использовать полностью алгоритмический или автоматизированный подход к проектированию с учетом доступности?

Хейдон: Я так не думаю. Нет. Итак, у нас есть автоматизированные инструменты, и я никоим образом не хочу принижать автоматические инструменты. Я думаю, что они очень полезны, но я использую их как систему раннего предупреждения, чтобы попытаться получить представление о проблемных областях. Итак, если бы я проводил аудит для организации, которая хотела бы получить совет о том, как сделать свою продукцию более доступной. Так что это хороший способ финансирования там, где есть проблемные области, но я имею в виду, что вы можете иметь интерфейс, который технически доступен на 100%, возможно, по какому-то инструменту, даже хорошему инструменту для его оценки, скажем, по WCAG. , рекомендации по доступности веб-контента или какие-либо другие спецификации приемлемости. И, несмотря на то, что это 100% проверка всех флажков, он все еще может быть совершенно непригоден для использования по разным причинам.

Хейдон: Например, возвращаясь к тому, что мы говорили ранее, это может быть слишком сложным. Вы можете просто завалить кого-то ссылками, и они просто не смогут пройти через это, и тогда это становится очень неявной вещью и трудной для определения, но это обязательно оттолкнет людей. Но вы также можете получить ложные срабатывания и тому подобное. На днях у меня было кое-что, я сказал на днях, это был другой месяц, я работал в организации, и, конечно, они хотели иметь школу-маяк со 100% доступностью, и там был iframe, который динамически добавлялся туда по аналитическому сценарию или что-то в этом роде. Вы знаете такие вещи, когда это какой-то немного грубый код, который просто вставляется на страницу для выполнения какой-то задачи.

Хейдон: Теперь я бы порекомендовал вообще не использовать аналитику, и я рекомендовал им хотя бы поддерживать протокол «не отслеживать», чтобы люди могли отказаться. К сожалению, этот протокол больше не работает, потому что он никогда не поддерживался должным образом. Но этот iframe говорил, что на нем нет заголовка. Итак, идея состоит в том, что если у вас есть iframe, у него должен быть атрибут title, потому что это лучший давний способ определить, для чего предназначен iframe для пользователя программы чтения с экрана. Но это был iframe, который также был настроен так, чтобы ничего не отображать, поэтому он даже не был воспринят программой чтения с экрана, потому что отображать ничего, точно так же, как он визуально скрывает вещи в программе чтения с экрана, он, по сути, удалит его из экрана. интерфейс, поэтому он не будет встречен или объявлен каким-либо образом.

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

Хейдон: Я имею в виду, я разговаривал с разработчиком, когда некоторое время назад консультировался по этому поводу, и они продолжали говорить: «Ну, пока у нас есть автоматизированное тестирование, у нас все в порядке, не так ли? Это просто, тогда мы можем просто двигаться вперед». И я сказал: «Вам все равно придется тестировать вручную. Не существует автоматизированного теста, который действительно мог бы сказать вам, невозможно ли так или иначе использовать интерфейс с помощью клавиатуры». Есть какие-то отдельные вещи, которые вы можете искать, но общий опыт по-прежнему должен оцениваться человеком. Да.

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

Хейдон: Да.

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

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

Хейдон: Итак, я бы написал сценарии для «Вот как это должно работать, когда вы взаимодействуете с этим компонентом с помощью клавиатуры» или «Вот как это должно работать, когда вы взаимодействуете с этим компонентом с помощью программы чтения с экрана, а не пошагово». Это. Итак, когда вы это сделаете, это должно произойти. Когда вы это сделаете, это должно произойти. Когда вы сделаете это, должно появиться это», или что-то в этом роде. Итак, и, как вы говорите, такие вещи, связанные с путешествием, автоматизированные инструменты не знают об этом. Они просто видят: «О, здесь нет альтернативного текста». И на самом деле, во многих случаях, возможно, у него не должно быть альтернативного текста. Кроме того, он не может судить о том, хорошо ли вы написали замещающий текст или нет. Поэтому я думаю, что изображение без всего альтернативного текста, вероятно, лучше, чем изображение с вводящим в заблуждение или просто плохим альтернативным текстом. И это снова приговор, не так ли?

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

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

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

Хейдон: Я думаю, что в большей степени, чем технология, восприятие и понимание этих вещей имеет тенденцию меняться со временем. Я имею в виду, недавно, в ходе недавнего опроса WebAIM, они определили, что сайты, использующие ARIA, более недоступны, чем сайты, которые его не используют. Так что эта технология, специально разработанная для того, чтобы помочь людям сделать веб-сайты более доступными, делала их хуже. Так что на самом деле это просто пробел в знаниях, а не технологический пробел или технологический недостаток. Люди просто берут технологию и используют ее неправильно, потому что, к сожалению, они на самом деле не понимают, как она должна работать. Надеюсь, кое-что из того, что я написал, сможет в этом помочь. Во всяком случае, в некоторых областях.

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

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

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

Дрю: Может ли компонент когда-либо быть полностью инклюзивным, или это спектр, в котором вы просто все больше работаете над инклюзивностью?

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

Хейдон: Итак, будут люди, которые, некоторые хорошие люди, с которыми я работал, например, в Paciello Group, скажут: «Ну, на самом деле, я хочу, чтобы меня знали как доступного UX-человека». Таким образом, речь идет не только об этом упражнении с галочками, это больше о том, чтобы действительно попытаться сделать опыт лучше и более ценным для большего числа людей и больше двигаться к своего рода более широким принципам и вещам, которые менее бинарны. Но, в конечном счете, это все, и WCAC и другие подобные критерии могут действительно определить только действительно жесткое и быстрое, «Это неправильно», я полагаю.

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

Хейдон: Я имею в виду, что в зависимости от того, что вы строите, будут разные критерии, которым необходимо соответствовать. Так, например, не каждый компонент будет иметь доступные изображения с альтернативным текстом, потому что он может вообще не использовать изображения. Это может быть просто текст на основе или что у вас есть. Некоторые могут быть не интерактивными. Таким образом, с точки зрения конкретных требований, это будет варьироваться между компонентами, но, надеюсь, то, что некоторые из моих работ и книга «Инклюзивные компоненты» помогут вам сделать, это впасть в или как бы принять дисциплину просто инклюзивного мышления.

Хейдон: Итак, когда вы подходите к этому вопросу, не просто думайте, ну, в основном, просто выходите из мышления «Если это работает для меня, это, вероятно, работает для всех остальных», потому что это просто не тот случай, когда то, как вы или я просматриваем вещи, я имею в виду, мы, вероятно, будем делать вещи совершенно по-разному, только мы вдвоем, верно?

Дрю: Верно.

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

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

Дрю: Итак, сама книга, как вы решили, как ее структурировать? Это кажется очень практичным, что мне нравится в книгах, но как вы это структурировали?

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

Хейдон: Итак, для меня было логичнее организовывать вещи с точки зрения самих компонентов. Итак, шаблоны инклюзивного проектирования делают это, и теперь инклюзивные компоненты — это просто продолжение, которое просто охватывает разные компоненты. Она отличается тем, что с точки зрения функций она немного отличается, потому что она также включает живые примеры кода и прочее, чего я не так много делал для предыдущих книг. Но да, это буквально просто: «Мы собираемся сделать этот компонент», будь то сенсорный интерфейс, или сворачиваемая секция, или переключатель тем, или флэш-карта уведомлений, или тостер, или как они там называются, а потом просто все. затем организуется вокруг этого компонента.

Хейдон: Итак, «Это то, что мы делаем, и это то, что мы должны учитывать, пока мы делаем это, чтобы быть более инклюзивным», потому что так работаю я и так работают другие люди. И как только я начал делать это таким образом, я действительно просто работал и писал заметки во время работы. Итак, вещь как бы написала сама себя, а затем все усилия были на самом деле просто в том, чтобы убедиться, что я делаю достойную работу, чтобы сделать эти вещи не недоступными, я думаю.

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

Хейдон: Да, именно в этом и заключалась идея, потому что речь шла не только о том, чтобы я делал свои компоненты, это был кейс, и вы затронули его там, и я рад, что вы это сделали, а именно определение общих черт. шаблоны, которые мы все используем. Я имею в виду, что везде есть интерфейсы вкладок, и все они реализованы по-разному, и все они реализованы по-разному, очень плохо. Я имею в виду, что я реализовал ужасные интерфейсы с вкладками и немного узнал о том, насколько они плохи для людей, а затем я попытался сделать их немного лучше, немного лучше и еще немного лучше. Я, наверное, сделал 15 или 16 различных версий интерфейсов вкладок в свое время, занимаясь такими вещами уже много лет.

Хейдон: И знаете, надеюсь, с каждым разом они становятся немного лучше. Но это просто обычное дело. Это была обычная вещь, которую я использовал довольно часто между разными веб-сайтами, я использую и все используют. Итак, часть идеи заключалась в том, чтобы сказать: «Ну, на самом деле, давайте сделаем дизайн-систему, своего рода доступную дизайн-систему для Интернета». Теперь люди будут расширяться и будут делать свои собственные версии этих вещей, но как бы изложить основные вещи и доступность — это основная вещь, которая должна быть в вещах. Это не должно быть дополнением, это не должно быть или/или, это не должно быть функцией. Это должно быть основной вещью. И если вы соберете эти основные вещи в паре, то да, надеюсь, люди посмотрят главы и скажут: «О, ладно, я их сделал. Я видел их. Давайте посмотрим, как сделать это как можно более инклюзивным», и тогда, надеюсь, они получат от этого какую-то пользу.

Дрю: Ну, что мне в нем нравится, так это то, что я знаю, что в прошлом у меня были некоторые функции интерфейса, которые мне нужно было реализовать, и я знаю, что это будет сложно с точки зрения доступности. , скажем, какое-то выпадающее меню, выпадающее меню, что-то в этом роде. Я думаю: «Хорошо, вот вам и драконы с точки зрения доступности. Мне нужно убедиться, что я делаю это правильно». Итак, я гуглю, как это сделать, я нахожу авторитетный источник, говорящий: «Используйте этот метод», я использую этот метод, применяю его и иду дальше, но на самом деле я ничему не научился. Я не узнал, почему решение было таким. И что мне действительно нравится в том, как вы подходите к этому в книге, так это то, что я могу делать две вещи одновременно. Я могу понять, как я должен это делать, и я могу понять, почему я должен делать это именно так, потому что все это очень тщательно объяснено. Так что, я думаю, что это действительно успешно с этой точки зрения.

Хейдон: О, отлично. Это то, к чему я стремился. Так что это хорошо. Но да, похоже, это мое дело. I mean, I've been working with the BBC for some months and we've kind of made a thing a bit like Inclusive Components but for the BBC, so we've done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it's not a pattern, really. The idea is that the individual departments at the BBC, because there's so many of them, because it's such a large organization, so there'll be BBC Sport, BBC Weather, BBC News, they're the ones who would be taking care of the kind of technical stack and making their pattern library. And what we've really provided is just, we've just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. Да.

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn't going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it's full of caveats. And the main caveat is, probably don't use a tab interface. Use maybe an accordion, it's a simpler interaction paradigm. It's easier to make responsive, it's easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven't written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don't know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I've done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I'll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I'm kind of doing other things at the moment. But I'm always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I've covered and there was just something that they were unsure about or which I, for whatever reason, I hadn't made as clear as they'd liked it. Yeah, then just contact me because I'm always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I'd recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we're all about learning. What is it that you've been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it's still available as a PWA, it's a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I'm now working on doing a much more advanced version of this. And it's a different kind of drum machine because it's polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You've got these, it's multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who's interested in kind of experimental music, that's something I wanted to play with. Obviously, I'm trying to make this drum machine as accessible as possible. And that's been interesting from the point of view now that I'm working with, I'm turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I've been doing cross browser testing for 12 years now, it's really nice to have a break and just to design stuff for one browser. And it's got some, so there's a flag in Chromium. It's a, what's it called, an experimental web platform feature for focus visible. So I've been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you're using a keyboard. So that's been nice, to be able to incorporate that.

Heydon: But the thing recently that I've been learning about, just I've, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they'll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It's kind of like a reverb or something. But sometimes if you're doing an arpeggio, like a baseline or something, you don't want them to open up. That's not how a bass guitar works, right? If you're on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it's not the web audio API having a problem or anything like that. It's just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it's going to sound nasty. And then, so I found that there's a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it's basically been web audio API stuff and messing around with sounds because I've always been into, as I say, into experimental music and messing about with that sort of stuff. And I'm trying to write a talk about this. And in the talk, I'm using Billy Jean by Michael Jackson because it's a very straight, fall to the floor rhythm and I'm going to kind of warp it in various different ways. So I've actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he's @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.