Links

Keith Cirkel:

I recently made my 100th patch to browser engines, which I consider somewhat of a milestone.

(From: 100 patches to 5 browsers in 18 months - Keith Cirkel)

Yeah, wow, that is a milestone and very impressive read. Interesting to learn more about what it involves.

Jake Archibald presents some options for how <selectedoption> would work:

what if the selected is modified?
This is the bit I want your opinion on.

(From: How should work? - JakeArchibald.com)

Scott O'Hara shares his thoughts around the ideal way to code spoilers on the web:

I’m just going to tell you what I’d expect from a spoiler component if someone were to build one, or if one were to ever be standardized.

(From: Spoiler Alert: it needs to be accessible | scottohara.me)

Rahim Abdi of Apple describes an effort to make it possible to test more web platform features for accessibility features:

what if we could regularly test the accessibility behavior of any and all web platform features on the latest browsers in an automated fashion? How much time and effort could this save?

(From: Improving Web Accessibility with Web Platform Tests | WebKit)

Currently, the Baseline support information does not include whether the feature is supported accessibly:

If you need to understand whether browsers support accessibility features as your own base level set of requirements, for legal or other compliance reasons, then Web Platform Baseline does not represent a baseline.

(From: Baseline Does Not Really Cover Baseline Support — Adrian Roselli)

I support Adrian's call for this to change. We should't assume features to be supported, if there are known accessibility issues in specific browsers or assistive technologies. I previously noted I feel Interop should include accessibility (and there is a separate Interop project for accessibility now, nice). I hope Baseline can meaningfully implement updates to make accessibility support more clear. A disclaimer, as Adrian suggested seems a good first step.

What would that it mean to deem a feature supported accessibly? WCAG's accessibility supported definition is a good start, but the W3C or Accessibility Guidelines Working Group (that makes WCAG) don't say exactly which browsers or assistive technologies a feature needs to work. For users of assistive technologies, ‘it works’ depends both their choice of assistive technology and the browser they use it with. But even if there's no clear cut answer to ‘which browsers or AT’, even the information that there are known bugs and where would tremendously help web developers decide whether to use a feature or not.

Attributes and properties are fundamentally different things.

(From: HTML attributes vs DOM properties - JakeArchibald.com)

Apple is experimenting with a new HTML form control: a switch (see WHATWG/HTML issue #9546). It is designed as an attribute for <input type="checkbox">, you'd turn a checkbox into a switch by adding the switch attribute:

<input type=checkbox switch checked>

In terms of pseudos:, they're experimenting with ::thumb and ::track pseudo elements for styling the parts of the switch. Unlike the checkbox, it has no ::indeterminate pseudo class, because it has no indeterminate state.

The colour can be set with accent-color. For browsers that don't support this new switch attribute, the element simply falls back to a checkbox.

There is some accessibility support: a switch gets a switch role under the hood, and the element respects the “differentiate without color“ setting in iOS and “on/off labels” on iOS.

Their blog post on when to use it:

Generally, we recommend using a switch when the end user understands the user interface element as a setting that is either “on” or “off”. A checkbox is well suited for when the end user would understand the element as something to be selected.

(From: An HTML Switch Control | WebKit)

In Don’t Disable Form Controls, Adrian Roselli explains that, while it sometimes can be ok to disable buttons, it's never ok to disable submit buttons (or any form fields):

Telling authors not to disable submit buttons is too narrow. Authors should not disable any form fields.

Hui Jing had fun inspecting a site:

I just got a scam SMS and thought it’d be fun to inspect how the phishing website works

Hope you recover soon, my friend!

(From: Let's inspect a phishing site)

In Weird things engineers believe about Web development, Brian Birtles talks about different assumptions of developers of websites and and web browsers:

it’s easy to assume our experience of the Web is representative of Web development in general

Yup, checks out.