Links

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.

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.