I like Twitter. When I joined just over 15 years ago (!) I genuinely did not expect the hype to last more than a year. But what did I know? It still does a good job of letting me follow very short content from a list of people I pick. I like Twitter as a remote worker. As someone with many interests. I love being able to interact directly with people whose work I look up to, people who say interesting things or post excellent dad jokes. People with specific areas of interest that I want to stay informed about. People whose books, music, journalism or conference talks I enjoyed.

Twitter is great for all those things, but it also has downsides. I'm sure those who read this are aware… it's a walled garden, the company has been too slow banning certain violence inciting politicans, there is lots of harrassment, there are still massive spam and bot issues, the obsession over metrics like follow counts, the verification system that seems biased (like, why is Jen Simmons not verified?), the self proclaimed experts, its anxiety inducing effects and so on. I have tried switching to alternatives that work on solutions for some of those things, but always returned for various reasons. I guess I do like it on Twitter.

Tweaking Twitter

Though I net enjoy my time on Twitter, I would have left years ago if I couldn't make these modifications:

• 'Current topics' hidden, when I use the web version (using Better Twitter). Where I live, this section is a gateway to mostly fascist voices, terrible takes and disinformation . It seems bad actors simply take over any popular hashtags, so this may be hard to fix, but for me it means I don't want to see it.
• Ads blocked: because they aren't I'll admit I don't believe there is such thing as relevant ads. Even people who do will likely agree that mismatches happen, in my case crypto ads served to me, a forever crypto sceptic. Please let me pay for the service. On desktop I use an ad blocker, on mobile a paid app that has no ads.
• Tweets auto-deleted: maybe I would like an archive of my thoughts, but not one that is public, on a centralised platform. It seems like too much risk to keep them around. I use Semipheral to do this somewhat selectively.
• People auto-muted: there isn't sufficient time in life to interact with trolls, bullies and cryptobots, tools like Blockparty are instrumental to automating some of the muting and blocking that makes Twitter more liveable.
• Time limited: I'm not always great at this one, but I try to avoid looking at Twitter most of the day, this platform is best enjoyed for a limited amount of time per day. I've sometimes done multi-week breaks too.

Tweaking my tweets

I also try to be better at tweeting.

As a rule, I try not to complain about products or services. If a train company didn't treat me well, that's not my followers' problem. In general, I try to limit complaining. I don't find it very easy, as I love complaining, but I am convinced it doesn't contribute that much.

I also try to ensure my timeline is accessible. That means I add alternative text with every image and don't retweet images without alternative text. I also avoid ASCII art memes and bold or italic unicode characters (like the ones Twitalics converts to, a tool that actually comes with an accessibility warning). Lastly, I capitalise usernames and hashtags so that screenreaders are more likely to pronounce them in a way that makes sense, for instance #CSSDay instead of #cssday. This doesn't always make a difference, but sometimes can,
like in this example where the capitals cause a pause between CSS and Day where I tested.

Another thing I recently tried to do more of is whenever I feel I have something to say, I plan for writing it on this blog and just linking out to it from Twitter. That way I can mitigate the walled garden issue a bit, by putting my content in my a garden that I control.

I'm sure there are lots of ways to use Twitter that I haven't made a habit (like, I hear some use lists extensively). How do you use Twitter?

---

Originally posted as How I use Twitter on Hidde's blog.

Reply via email

One way to make a UI on the web keyboard accessible is to ensure parity between input methods: that things that can be clicked, can also be activated with just a keyboard. In addition, you can also introduce keyboard shortcuts for common actions. If you do, ensure they require a modifier key, like ⌃ Ctrl or ⌘ Cmd.

Understanding 2.1.4

In WCAG, the standard used to check if websites are accessible, there is a specific Success Criterion for keyboard shortcuts, which got added in version 2.1. From the criterion text:

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true: (…)

In other words: do not use keyboard shortcuts that are just a one letter character (or multiple of those). After the quoted part, exceptions are listed where such a keyboard shortcut would be ok, we'll get to those later.

Let's first try and get a little more explicit. Basically, you could do shortcuts that are a single key, like, ‘press N to open a new document’. Or your shortcuts could be in the form of ⌘ Cmd + something or ⌃ Ctrl + something, requiring a modifier key. This Success Criterion basically says ‘don't do the single key thing, always have a modifier‘ (again, with exceptions, see below).

This criterion removes frustration for speech input users, who control their screen with their voice. Their software listens for words or sentences, but also for shortcuts. The issue is that shortcuts that don't use modifier keys could get activated up when the user didn't mean to.

An example from the Understanding document:

For example, Kim's email software uses common keyboard shortcuts to navigate ("k"), archive ("y") and mute messages ("m"). Her coworker enters her office and says "Hey Kim" and her microphone picks that up. The Y of "hey" archives the current message. K in "Kim" moves down one conversation and M mutes a message or thread.

(From: Understanding 2.1.4, Intent; adapted to be shorter)

The criterion also improves the experience for people who are prone to accidentally hit keys, like users with fine motor skill related impairments.

So basically, the issue with these “unmodified” shortcuts, is that it is harder for software to establish if the user actually wanted to trigger the shortcut. The use of modifier keys is an established pattern that captures this user intent, you would not press those and another key accidentally.

What about /?

When I was testing a website recently, I found that / was used as a keyboard shortcut. I wasn't a 100% sure if this was a WCAG failure per se. The Success Criterion text says keyboard shortcuts should not consist of just letter, punctuation, number of symbol characters. Is / any of those four things? Letters and numbers I know, but what exactly does the full set of punctuation and symbol characters look like? Why doesn't WCAG include a list?

Well, there are two answers to that:

• it's complicated; there are lots of languages and writing systems and it would be easy to forget a punctuation or symbol character… or even a letter of number, CJK languages have tens of thousands of characters
• what is really meant here is any character that prints something on the screen

That last answer is what Marjon from the accessibility consultancy Firm Ground replied when I asked about my confusion on Twitter. She linked to the WCAG Technique document (yup, not normative), where “all number, letter, sign and punctuation keys” are summarised as “printing characters”. That checks out. I'll take this interpretation: / is a printing character and should not be used as a shortcut on its own.

Exceptions

I promised to get back to the exceptions that are in the Success Criterion text. It says you can use single characters without modifier keys as shortcuts:

• if it the shortcut can be turned off in settings
• if the UI lets users remap the shortcut… so it's / by default, but users can go to the settings of your app and remap it to be ⌃ Ctrl + /
• if the shortcut works only when the relevant component has focus, for instance when you're in a countries select menu and press the T to jump straight to Taiwan (that way, it doesn't interfere)

The remapping option can get tricky if your interface has a lot of shortcuts. The popular email web app that allegedly was used as inspiration for this Success Criterion has a very large number of unmodified shortcuts, so many that it runs into the case where there aren't enough characters to remap them all.

Summing up

Keyboard shortcuts are most accessible when they include modifier keys like ⌃ Ctrl or ⌘ Cmd, so that they don't frustrate voice input users and users with fine motor impairments. If your interface has shortcuts that are just one or more “printing characters”, any character that prints something on the screen, best combine them with modifiers.

---

Originally posted as Keyboard shortcuts need modifier keys on Hidde's blog.

Reply via email

We need bigger steps to combat the climate emergency, but small steps matter too. This week Dave shared he feels climate action falls on consumers too much, rather than large companies and governments. Michelle responded that as tech workers, “we have the power to push for for change”, that we can “extend reach of our actions far beyond ourselves”. Matthias added that we all do something, “even if it feels like we are the only person doing it, it will make a difference.” Great posts.

Like Michelle and Matthias, I feel we can make a difference. I agree that we can use our privilege as tech workers, and that we can do individual things, even if small. I also agree with Dave—companies and governments need to facilitate these individual actions much better. Companies could provide more sustainable defaults, governments could have more tax incentives for sustainability. I say “more”, as both of these things continue to happen and the pace increases. Eating plant-based has been challenging for years, today it is trivial, even at fast-food chains known for their meat. The European Commission has negotiating climate action too slowly for decades, but recently launched a Green New Deal, spending trillions of euros on concrete targets (see also Delivering the European Green Deal).

Like most people, I'm a hypocrite when it comes to climate action. I haven't eaten meat for decades, but hey, I eat eggs and dairy sometimes, which can be as bad in terms of climate impact. I use trains for transport mostly, but hey, I still fly for work and family visits sometimes, multiple times a year. I try and buy stuff secondhand, but hey, my current shiny phone was bought new. I buy most produce directly from local farmers through Rechtstreex, but hey, I occassionally enjoy avocados and bananas that are flown in from very far away. I don't use plastic bags, but I gave my children diapers made of plastic.

What about governments? The Dutch government recently announced to invest billions in expanding the power network so that more solar panels can be connected, but they also still subsidise gas and oil. They have started charging companies for their CO2 emissions, but currently still charge lower VAT on meat than on plant-based alternatives.

Or companies? Shell will build Europe's biggest hydrogen plant, which is nice, but I don't even want to get started on how they've undermined climate agreements for decades and continue with fossil fuels on an enormous scale (Follow This buys Shell shares to then use shareholder privileges to demand greener policy).

Still, like Matthias said, we need to look at the good things that are happening, and encourage more good things. From governments, from companies and from ourselves. Small steps matter. In a country with millions of voters, one vote seems like nothing. But each vote ends up as a part of the election results. If we all stay home, nothing happens.

It may seem rational to find hypocrisy in my actions, or the government's actions, or those of companies. You'll probably find stuff quickly. But even if I'm inclined to, I don't want to be a cynic about climate action. I'd rather err or the side of being overly naive. Sometimes change is slow and complex, I want to keep the focus on making it work, not on looking for hypocrisy. So I'll continue to do my things. I'll also continue to expect companies and governments to act. In fact, they need to do more and do it faster, and this will impact what I buy and vote. It adds up if all of us buy and vote the right things, especially in countries where small parties can have impact.

---

Originally posted as Individual climate action: small steps matter on Hidde's blog.

Reply via email

Focus outlines are a great way to improve accessibility. They are traditionally set with the :focus pseudo class. That still works, but with :focus-visible we have a new way to only show focus styles when they make sense. How does that work?

The :focus-visible pseudo class has been in the works for over seven years and we recently got to a situation where it is now in stable versions of all modern browsers: Chrome/Edge (from 86), Safari (from 15.4) and Firefox (from 85).

What is focus-visible anyway?

The thing is, :focus-visible isn't a “indicate focus only to keyboard users” pseudo class, it is “indicate focus when the browser thinks it's right, based on some heuristics”.

“When it is right”, what does that even mean? Well, it has to do with when browsers decide to show their default outline. For example, most browsers show an outline when you press a button with a keyboard, but they don't when you click a button with a mouse. In other words, focus styles in browsers only show sometimes, in specific cases. The :focus-visible pseudo class is meant to match those cases.

This makes :focus-visible very different from :focus, which matches whatever the currently focused element is, regardless of whether it makes sense to highlight it or not. That's why you might see the styles you applied through :focus even if you click on something with a mouse, a behavior that could leave users confused and causes some developers to turn off highlights completely (but friends don't let friends do this, you would not do cursor: none either).

From CSS Selectors, Level 4, 9.4:

[:focus-visible allows] authors to change the appearance of the focus indicator without changing when a focus indicator appears.

So it lets you target the cases where browsers would normally apply focus styles, and, importantly, it excludes the cases where browsers don't paint their default outline, for instance when the user clicks on a thing with a mouse.

Consequently, browsers apply :focus-visible styles to more non-mouse cases than just keyboard users. Which cases are they?
There are lots of devices that are keyboard-like, as Eric Bailey explains in Focusing on focus styles:

Wands, sticks, switches, sip and puff devices, voice recognition, and eye tracking technology can all create input in a digital system. These devices will identify a content area and activate it. This is similar to how you can hit the tab key on a keyboard and the next cell in a spreadsheet will be highlighted, indicating that it has been moved to and is ready to be edited.

Some of these technologies present themselves as keyboards (like braille displays), they could fall under the focus-visible umbrella, others (like voice control) are more mouse-like and may not trigger these heuristics. Some assistive technologies also come with their own highlighting, like VoiceOver on iOS and the macOS Switch Control UI.

Pointers vs non-pointers

An example (non-normative) in the specification for :focus-visible suggests that :focus-visible should apply to interactions “via keyboard or some other non-pointing device”. This made me wonder what the exact difference is between a pointing device and a non-pointing device. The Pointer Events specification has some answers (thanks Bramus!).

Basically, there are input methods that can do mouse clicks and input methods that aren't really a mouse but can simulate mouse clicks, like touchscreens and pen input. Pointer Events tries to abstract all of those input methods into a new concept called “pointer”.

The definition of a pointer in that specification:

A hardware agnostic representation of input devices that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact.

I haven't found a definition for non-pointer devices, like keyboards, but my best bet at a description would be: non-pointing devices are devices that let you step between the different interactive parts of a user interface. Others also call it “sequential navigation”.

Examples of non-pointer or sequential navigation:

• TAB/shift + TAB or arrow keys when you use a keyboard
• gestures when using VoiceOver on iOS, you flick between the different elements
• item mode in switch control (see Milan Patel's switch control demo, item mode demo at 3:59, note switch control has a pointer mode too, which Milan mentions he finds easier)

For the sake of completeless, there is also the concept of “spatial navigation”. This is similar to sequential navigation, but you don't just go back and forward—you can go up and down too, like when you select something to watch on a streaming service on your TV.

Input methods differ and overlap

Even with this distinction between pointing devices and non-pointing devices, none of this is very binary. There are users who always use a keyboard or users who never do, but most people will be somewhere in between. They could be switching between a mouse and a keyboard in one browser session, or use devices that allow for multiple input methods. Someone could connect a bluetooth keyboard to until-then touch-only tablet. Switch Control in iOS has both a point mode and an item mode.

And even if you could detect every type of device, people are not the same. You likely have users who use a mouse, but still benefit from seeing what currently has focus: users with low vision and users with cognitive disabilities.

In a comment discussing focus-visible, Jonathan Avila shares how he switches between modalities:

I often switch between input modalities such as by clicking and dragging off a button to set focus somewhere then use the keyboard to navigate from there. I may click on a radio button and then use arrows to select other radio buttons. I will switch between touch, mouse, keyboard, and many other settings such as large text, screen reader, or zoom depending on the situation.

The cool thing about :focus-visible is that it allows browsers to be smart about when to show focus styles. Browsers won't just hop into visible focus mode when you press any key, it takes things like using command/control + key combos into account, as Alice Boxhall explains in a recent Igalia Chats episode. The heuristics develop over time, too.

Ok, so what now?

This post turned out a little longer than I intended, but what I've tried to capture is what I started with: that and why :focus-visible is more than a way to show focus styles just to keyboard users.

If you want to hear more about :focus-visible from people who worked on this, the aforementioned recent Igalia Chats episode with Brian Kardell, Alice Boxhall and Rob Dodson covers some of the history and evolution.

---

Originally posted as With :focus-visible, you can have focus styles when it makes sense on Hidde's blog.

Reply via email

The proposed <selectlist> will have powerful styling options and full control over the different parts. In other words, there would be not one, but two levels of customisation. In this post, we'll look at what they are and when they are useful.

<selectlist>, you ask? It's a proposed new HTML element that is like <select>, but fully customisable. Why? Because so many people are building their own selects, from scratch or with libraries, and that should be easier to do. With accessible defaults where possible and by leaving the parts that browsers are good at to the browser (like knowing where to position it, to place it on the top layer or to automatically dismiss it when appropriate (‘light dismiss’)).

For context, <selectlist> is a proposal by the Open UI Community Group. This group was founded to study common components and controls that people build on the web (in design systems, see the component name matrix), and suggest Web Platform features to make it easier to build such controls. Think new HTML elements, CSS features or APIs, as well as things that surface across HTML, CSS and JS.

<selectlist> doesn't ‘exist’ just yet, it is an idea that is being prototyped in Chromium, with other browser engines currently not opposed, but also not implementing it (as far as I'm aware). While you would't use it in projects yet, you can experiment with it in Chrome or Edge Canary with Experimental Web Platform Features flag on, and file issues if something doesn't work as expected or desired. For brevity, this post will refer to it as if it exists, to avoid saying ‘would’ in every sentence.

The anatomy of a <selectlist>

The <selectlist> element, as currently prototyped, is a lot like the <select> element that we've had for years. We can use it in a form, users can select an option out of many and their choice becomes part of the data that we process.

But where a <select> comes with free built-in styles that we can't change, <selectlist> consists of some explicitly designed parts that can be changed (more on that a later). Often, the browser built-in styles of a <select> are just fine, sometimes they are not.

In Sanity's Portable Text editor, the user can choose text types. Each option is styled like something of that type is commonly styled, and there is some shadows, rounded corners and arrows that a regular <select> can't have.

The parts are:

• select, the root element, wrapping/containing all the parts
• button, the toggle/button the user activates to open the options
• listbox, the part that is toggled, it wraps the options
• optgroup, a part that we can optionally use to group related options together
• option, an actual choice, a value that a user can pick
• selected-value, the element that displays the currently selected value

(from: Anatomy of the selectmenu)

When using regular <select>s, it is possible to make the button part look however we want. In some browsers, we can also apply some specific styles to options, like background colours.

With <selectlist>, these parts are not just parts in the colloquial sense, they are <part>s in the Web Component sense, meaning that they exist as elements in the shadow tree of the component. Consequently, all of these parts can be changed.

There are two levels to that: the first is to write CSS, where we can use all the power CSS has to offer, the second is to completely replace the DOM structure to what we want or need.

Option 1: CSS

In the <selectlist> prototype, the options are part of the (light) DOM like they are in a <select> element, which means we can target them with CSS (and unlike with <select>, our styles will actually get applied).

You could even give each option its own style! See Codepen (view in Canary with Experimental Web Platform Features flag on)

This is the most basic example of styling a selectmenu: you apply CSS to the options, like you would to any other HTML element.

The other parts of the selectmenu are targeted differently: we'll use a ::part() selector referencing the respective part name.

Deprecation warning: this is currently under discussion; the final implementation will likely use elements and not ::part() to select parts of a selectlist

For example, to style the button:

selectmenu::part(button) {
  // add any button styles
}

(Codepen of example with styled options)

To style other parts, you use that part's name instead, for instance ::part(listbox). Just last week, a resolution was passed to also expose the arrow as a part, to allow for easy styling or icon-replacing (part name to be decided).

In case you, like me, had not used the ::part selector, it is part (no pun intended) of the CSS Shadow Parts module.

For background: Web Components can have a light and a shadow DOM. The light DOM is part of the DOM like anything else and can be styled, but the shadow DOM is internal to the element. This a bit like public and private functions. For styling purposes, the CSS Shadow Parts module states that the creator of a Web Component can choose to expose parts of their shadow DOM by names. Developers provide a list of parts (element names) to be exposed, and then the elements can be targeted through ::part(partname). With <selectlist>, we get a browser built in Web Component that has parts exposed (except for option, which is in the light DOM).

This is huge… I mean, being able to throw CSS at the different parts of a selectmenu unlocks a lot of possibilities. Many of us will likely just use it to round some corners, add some shadows, maybe a little color or typography. And that's fine, we never could unless we built or loaded a library for custom selects.

I'm excited about being able to add a few finishing touches to selects, alone. But CSS has numerous powerful features, so that's only the surface. With all of CSS at our fingertips, custom selectmenu styles are probably going to be used in more interesting ways than we can think of now.

Option 2: full control by replacing parts

If we need more than ‘just’ styles, it is also possible to replace entire parts with whatever we like. For instance, we could write our own button entirely, and tell the browser to use that instead.

Replacing a part is done with slots. Let's say we created a button with markup of our choice:

<button>select option</button>

We can then tell the browser that, actually, we want this to be what the button part is, adding slot="button" and behavior="button":

Deprecation warning: this will probably not work this way in the final implementation

<button 
  slot="button" 
  behavior="button"
>select option</button>

(Codepen of example with replaced button part)

Now, the button will be what's used for the part called ‘button’ (as it is slotted into the right place with slot) and get the browser's select button behavior and accessibility accomodations (set through behavior). We could do the same for the other parts.

We could also do this in JavaScript, with Element.attachShadow(), so that the markup we want to use can live in our JS, and we only need one HTML element at the point of usage rather than one plus a few more for slotting.

But wait… if we're replacing all the parts with our own things, isn't this just like rolling our own selects entirely? Well, yes, it is the advanced option, and usually CSS should suffice. But even if we replace some or many parts, the selectmenu would still get a bunch of things from the browser for free, like positioning, being on the top layer and light dismiss, features that would be hard to impossible to code in JavaScript.

Accessibility risk: avoid unexpected nests

There is an important accessibility risk to be aware of for folks planning to replace parts in their selectmenus. Browsers and assistive technologies have certain expectations about what HTML is and does. If we divert from those expectations, we risk causing real problems for end users, which could include controls becoming unusable.

One example is what would happen if we would nest an interactive element like a link or button inside an option. Maybe one of our options has a tooltip? All of this should be avoided, at least for the time being (as far as I understand, this may change when secondary actions become a thing, see also w3c/aria#1440). The reason is: assistive technologies expect just text inside of options, not controls, so this would break badly and it could mean users wouldn't find those buttons or links, or wouldn't be able to interact with them. For this reason, it is strongly recommended to avoid interactive elements inside of options, i.e. do not add links or buttons in options.

Summing up

In this post, we looked at two ways to customise the parts of a selectmenu element. We can use CSS, which should cover a large amount of use cases and offer flexibility and room for creativity. Or we can replace entire parts with whatever we would like, the more advanced option that has accessibility risks if not thoroughly checked against specs and implementations. For a lot of the use cases that I see in design systems I have worked on, I feel CSS alone will cover all the needs. And it will do so very elegantly, often in literally a few lines of code.

Again, this is all in the future, the element is just being tested out. But, it may well be that this same pattern of having both CSS and parts-replacement for control customisation will come to other Open UI work, too. Generally, I am a fan of this layered approach. As a developer, I like the principle of being able to make things as simple or complex as I want.

If you want to see more demos, the Microsoft Edge team has built a series of cool <selectlist> demos, when these were published it was still called <selectmenu> (as they note, pushing the limits and some with accessibility issues). You can see and play with these, using Edge or Chrome Canary with Experimental Web Platform Features turned on. These demos include a lot of part replacements, too. If you have feedback, want to follow this work more closely or chime in, head to Open UI issues on GitHub or join us on the Open UI Discord community.

---

Originally posted as Two levels of customising on Hidde's blog.

Reply via email