Довольно иронично читать о том, что ГДД не нужно от человека, которому его написание помогло на начальном этапе разработки осознать чрезмерную сложность проекта и урезать до более реализуемого размера =)) Это и была одна из причин, почему с него стоит начинать.
Но да, для новых механик лучше начинать с прототипа (только не прототипа игры, а прототипа именно механики, с минимально необходимым сопутствующим функционалом), а убедившись в играбельности - идти писать ГДД =)
Очень странный опрос - почему нет варианта "Стало лучше"? Какие-то самоисключающие варианты ответов - они должны или отвечать на вопрос "лучше или хуже", или показывать отношение к самой идее, не то и другое разом.
Да, такая себе ситуация. Но это позволяет им хоть как-то взаимодействовать с Интернетом.
Что интересно, если разработчики реально заморочились с сайтом, это даже может быть удобно.
P.S. В инструментах разработчика относительно недавно даже появилась вкладка, которая помогает работать с доступностью. Там показывается дерево страницы (секции, заголовки, элементы навигации и т.д.). Интересная, хоть и довольно сложная для повседневной поддержки при разработке тема.
Это, конечно, было интересное исследование, но вы упустили, на мой взгляд, самый приятный вариант:
1. Делаем попап, внутрь (на одном уровне) кладём кнопку и обёртку контента. В кнопку кладем пустой span, он будет ловить клики вне попапа (ну и/или не только клики).
2. Попапу задаём z-index: 999 (можно больше), кнопке закрыть — z-index: 1, контенту — z-index: 2. Таким образом, всё содержимое кнопки всегда будет ниже содержимого контента
Для тега span(который внутри кнопки) задаём z-index: -1, за счёт этого он не будет мешать остальному содержимому кнопки (тексту, например). Хотя если оно не важно, можно оставить как есть.
4. Саму кнопку размещаем где хотим.
5. Для span'а задаём фиксированное позиционирование (за счёт чего он забивает на то, что его родитель (кнопка) маленькая, и спокойно примет заданные размеры, а их мы зададим во весь экран).
5. С помощью псевдоэлементов ::before и ::after делаем две полоски, поворачиваем, закругляем углы — делаем вообще всё, что придёт в голову. Размещаем их справа, делаем из них крестик.
6. При наведении на кнопку ставим любое действие с псевдоэлементами, чтобы было красиво. Можно их вращать, скалировать, перекрашивать, добавлять обводки — в общем, делать вообще всё, что в голову взбредет.
Профит.
Скринридеры читают «Закрыть» внутри кнопки, псевдоэлементы делают красиво, span прикрепляет область вокруг попапа к кнопке.
Пример, сделанный за 15 минут на коленке =)
P.S. Чтобы текст закрашивался с той же скоростью, что и крестик, откройте codepen в отдельной вкладке. Не знаю, почему, но во вставленном варианте плохо работает анимация.
1. Required прекрасно работает в случае с радиокнопками.
Для корректной работы достаточно, чтобы хотя бы у одной из радиокнопок (с одинаковым атрибутом name) был установлен required, и НЕ ЗАДАНО НИ ОДНОГО checked. В этом случае браузер, как и с остальными элементами, потребует выбрать.
2. Required, почему-то, и правда некорректно работает с чекбоксами.
Причём об этой проблеме авторам спецификации давно уже сообщили, но они заявили, что менять ничего не будут.
Что ж, это всего лишь означает, что потребуется немного больше JavaScript.
Как писал выше, смысл статьи в том, что куда проще использовать предложенный мной вариант, чем способ, который активно используется сейчас, т.е. обычные списки:
<ul>
<li>Option 0</li>
<li>Option 1</li>
</ul>
О том, что мой способ идеален, я не говорил, он просто намного лучше, чем не использовать нативные элементы вообще.
Тут важно отметить, что я пытался решить проблему стилизации, когда для этого используется простой список (ul, li).
Данный вариант куда лучше, поскольку всё вышеописанное реализовать проще, чем ещё и базовый функционал (активацию при клике, переключение как в радиокнопках (отключение предыдущего активного пункта при активации текущего), отправка на сервер, обязательность и т.д.)
Довольно иронично читать о том, что ГДД не нужно от человека, которому его написание помогло на начальном этапе разработки осознать чрезмерную сложность проекта и урезать до более реализуемого размера =)) Это и была одна из причин, почему с него стоит начинать.
Но да, для новых механик лучше начинать с прототипа (только не прототипа игры, а прототипа именно механики, с минимально необходимым сопутствующим функционалом), а убедившись в играбельности - идти писать ГДД =)
Очень странный опрос - почему нет варианта "Стало лучше"? Какие-то самоисключающие варианты ответов - они должны или отвечать на вопрос "лучше или хуже", или показывать отношение к самой идее, не то и другое разом.
А при необходимости просто меняется его содержимое.
Что интересно, если разработчики реально заморочились с сайтом, это даже может быть удобно.
P.S. В инструментах разработчика относительно недавно даже появилась вкладка, которая помогает работать с доступностью. Там показывается дерево страницы (секции, заголовки, элементы навигации и т.д.). Интересная, хоть и довольно сложная для повседневной поддержки при разработке тема.
Речь идет о том, что у тега есть нативный функционал (функционал по умолчанию).
Есть люди (теоретически, практически никого не видел, но где-то такие есть), которые для навигации по сайту используют клавишу Tab.
Эта клавиша умеет переключаться по некоторым элементам. И если «Закрыть» будет кнопкой, то её можно будет щелкнуть, наведясь на неё с помощью Tab.
Средства для чтения с экрана «озвучат»
Это нужно для слепых, например (им специальные программы озвучивают, что происходит на экране).
Если бы они это сказали лет десять назад, тогда да — а сейчас такие системы уже есть, толку от их отказа-то?
P.S. Чисто из интереса — 2.4% акционеров Amazon, которые проголосовали за прекращение исследований — это 1 человек, или много? =))))
Это что, всё, что ли? =)
Покажите хоть немного контента-то!
UPD: А, увидел ответ в предыдущем комменте (давно вкладку открыл, и пока коммент не написал, комментарии выше не обновлялись).
(но всё равно хочется больше инфы =) )
1. Делаем попап, внутрь (на одном уровне) кладём кнопку и обёртку контента. В кнопку кладем пустой span, он будет ловить клики вне попапа (ну и/или не только клики).
2. Попапу задаём z-index: 999 (можно больше), кнопке закрыть — z-index: 1, контенту — z-index: 2. Таким образом, всё содержимое кнопки всегда будет ниже содержимого контента
Для тега span (который внутри кнопки) задаём z-index: -1, за счёт этого он не будет мешать остальному содержимому кнопки (тексту, например). Хотя если оно не важно, можно оставить как есть.
4. Саму кнопку размещаем где хотим.
5. Для span'а задаём фиксированное позиционирование (за счёт чего он забивает на то, что его родитель (кнопка) маленькая, и спокойно примет заданные размеры, а их мы зададим во весь экран).
5. С помощью псевдоэлементов ::before и ::after делаем две полоски, поворачиваем, закругляем углы — делаем вообще всё, что придёт в голову. Размещаем их справа, делаем из них крестик.
6. При наведении на кнопку ставим любое действие с псевдоэлементами, чтобы было красиво. Можно их вращать, скалировать, перекрашивать, добавлять обводки — в общем, делать вообще всё, что в голову взбредет.
Профит.
Скринридеры читают «Закрыть» внутри кнопки, псевдоэлементы делают красиво, span прикрепляет область вокруг попапа к кнопке.
Пример, сделанный за 15 минут на коленке =)
P.S. Чтобы текст закрашивался с той же скоростью, что и крестик, откройте codepen в отдельной вкладке. Не знаю, почему, но во вставленном варианте плохо работает анимация.
Для корректной работы достаточно, чтобы хотя бы у одной из радиокнопок (с одинаковым атрибутом name) был установлен required, и НЕ ЗАДАНО НИ ОДНОГО checked. В этом случае браузер, как и с остальными элементами, потребует выбрать.
2. Required, почему-то, и правда некорректно работает с чекбоксами.
Причём об этой проблеме авторам спецификации давно уже сообщили, но они заявили, что менять ничего не будут.
Что ж, это всего лишь означает, что потребуется немного больше JavaScript.
Как писал выше, смысл статьи в том, что куда проще использовать предложенный мной вариант, чем способ, который активно используется сейчас, т.е. обычные списки:
О том, что мой способ идеален, я не говорил, он просто намного лучше, чем не использовать нативные элементы вообще.
<ul>
<li class=«active»>Option < /li>
<li>Option </li>
</ul>
Связка input+label требует куда меньше доп. кода, чем ul-li, и именно об этом статья.
У меня не было задачи сделать универсальную реализацию — только показать принцип.
Универсальная реализация будет огромна, при том, что многим этот функционал просто не понадобится.
Все перечисленные Вами моменты — важны, но требуются совсем не всегда. Если они нужны, разумеется JavaScript код станет больше.
Данный вариант куда лучше, поскольку всё вышеописанное реализовать проще, чем ещё и базовый функционал (активацию при клике, переключение как в радиокнопках (отключение предыдущего активного пункта при активации текущего), отправка на сервер, обязательность и т.д.)
Действительно не подумал об этом моменте, постараюсь придумать что-то, чтобы решить и эту задачу.