Here’s a fabulous post by Vitaly Friedman that looks at how to make accessible front-end components and what problems there are today when it comes to building them.
There’s so much great info packed into this one post that I’m going to keep it open in a tab for quite some time. But I have two thoughts here. First, just skimming through the article is enough to make anyone realize that accessibility is a complex subject and it’s so very easy to get things wrong; colors, images, text, HTML, mouse pointer vs. touch, small screens vs. large screens, charts and data viz, form components, layout and semantic ordering. The list goes on and on. It’s clear to me now (and I am late to the party) that accessibility is a full-time job.
Second, Vitaly makes note of some of the excellent work that the Government Digital Service (GDS) is doing in the UK by releasing open-source components such as accessible-autocomplete. And I have to say, I think the work that GDS is doing is so very inspiring to me as a web designer and developer.
Here’s a story: a few years ago I had to book an appointment to get a driver’s license. I hopped on the website and, immediately, I recognized that it was using the GDS design system. That gave me a great sigh of relief, but then I found myself sailing through this form at lightning speed. By the end, I realized that this is what every website should feel like; I used the site, did what I needed to do as quickly as possible, and then left.
It was one of the most shocking experiences for me as a web designer because there was no cruft, no junk, and no messing around with the experience in any way. It was fast, didn’t break down, crash the browser, or confuse me at all. The form inputs were big and clickable and the correct keyboard was selected when I viewed it on my phone. All of this accessibility work that they’ve poured into making things just work is a joyous thing.
This reminds me of something that Jeremy Keith wrote about the other day when he used another government website to get vaccinated:
[…] it’s a sequence of short forms, clearly labelled. Semantic accessible HTML, some CSS, and nothing more. If your browser doesn’t support JavaScript (or you’ve disabled it for privacy reasons), that won’t make any difference to your experience. This is the design system in action and it’s an absolute pleasure to experience.
[…] Maybe I’ll never need to visit that URL again. In the case of the NHS, I hope I won’t need to visit again. I just need to get in, accomplish my task, and get out again. This is where the World Wide Web shines.
Direct Link to Article — Permalink
The post Where the World Wide Web Shines appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
I would hope all our web designer/developer spidey senses trigger when the solution to an accessibility problem isn’t “fix the issue” but rather “add extra stuff to the page.” This Overlay Fact Sheet website explains that. An “Overlay” is one of those “add extra stuff to the page” things, ostensibly for improving accessibility. Except, even though marketing may suggest they are a silver bullet to accessibility, they are… not.
The site does a much better job laying that out than I can, so go check it out. As I write, it’s signed by 352 people, mostly people who are accessibility professionals.
Direct Link to Article — Permalink
The post Overlay Fact Sheet appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
Apple is adding two new voices to Siri’s English offerings, and eliminating the default ‘female voice’ selection in the latest beta version of iOS. This means that every person setting up Siri will choose a voice for themselves and it will no longer default to the voice assistant being female, a topic that has come up quite a bit with regards to bias in voice interfaces over the past few years.
The beta version should be live now and available to program participants.
I believe that this is the first of these assistants to make the choice completely agnostic with no default selection made. This is a positive step forward as it allows people to choose the voice that they prefer without the defaults bias coming into play. The two new voices also bring some much needed variety to the voices of Siri, offering more diversity in speech sound and pattern to a user picking a voice that speaks to them.
in some countries and languages Siri already defaults to a male voice. But this change makes the choice the users’ for the first time.
“We’re excited to introduce two new Siri voices for English speakers and the option for Siri users to select the voice they want when they set up their device,” a statement from Apple reads. “This is a continuation of Apple’s long-standing commitment to diversity and inclusion, and products and services that are designed to better reflect the diversity of the world we live in.”
The two new voices use source talent recordings that are then run through Apple’s Neural text to speech engine, making the voices flow more organically through phrases that are actually being generated on the fly.
I’ve heard the new voices and they sound pretty fantastic, with natural inflection and smooth transitions. They’ll be a welcome addition of choice to iOS users. I’ll embed some samples here after the beta drops.
This latest beta also upgrades the Siri voices in Ireland, Russia and Italy to Neural TTS, bringing the total voices using the new tech to 38. Siri now handles 25 billion requests on over 500M voices and supports 21 languages in 36 countries.
The new voices are available to English speaking users around the world and Siri users can select a personal preference of voice in 16 languages.
It seems very likely that these two new voices are just the first expansion in Siri’s voice selections. More diversity in voice, tone and regional dialect can only be a positive development for how inclusive smart devices feel. Over the past few years we have finally begun to see some movement from Amazon, Google and Apple to aggressively correct situations where the assistants have revealed bias in their responses to queries that use negative or abusive language. Improvements there, as well as in queries on social justice topics and overall accessibility improvements are incredibly key as we continue to see an explosion of voice-first or voice-native interfaces. These kinds of choices matter, especially at a scale of hundreds of millions of people.
Update: It seems that the market is volatile indeed. After pricing its shares at the lower end of the range, Deliveroo, trading as “ROO” on the London Stock Exchange, opened at 331 pence (£3.31), down some 15% on its private placement pricing, and it has been continuing to decline throughout the day. It finally closed at 287.45 pence — down 43.55% on its opening price of 331 pence after trading in a range between 271 pence and 344.95 pence has fallen short of the debut price, too. Some are claiming that the poor debut is due in part to public pressure over its labor practices, which we detail below. We’ll continue to update this story with pricing. Original post below.
Tech stocks continue to deliver on the public markets, figuratively and literally: Deliveroo, the UK food-delivery giant backed by Amazon that has seen a surge of business during the Covid-19 pandemic, has announced pricing of £3.90 ($5.36) for its shares when goes public on the London Stock Exchange later today, valuing it with a market cap of £7.59 billion ($10.4 billion), and raising £1.50 billion ($2.1 billion).
The figure is at the lower end of the reduced range Deliveroo set earlier in the week of £3.90-£4.10. At the time, Deliveroo said the “volatile global market conditions for IPOs” led it to narrow the range from its original £3.90-£4.60. “Deliveroo is choosing to price responsibly within the initial range and at an entry point that maximises long-term value for our new institutional and retail investors,” the company said.
However, separately, Deliveroo has been facing persistent controversy over how it pays its drivers, a story that doesn’t look like it will go away too soon. Deliveroo sources have repeatedly claimed that negative stories arising out of these labor issues have not been impacting the company in the lead-up to the IPO, although some have been detailing the large institutional investors that have refused to participate in the offering. Activity today on the market could be one indication of what the real impact has been.
The listing today is a milestone not just for the company but for the London stock market in general. At a time when a number of scaled up privately-held tech companies have, and are exercising, a lot of options — acquisitions to bigger rivals, listing in the U.S. market, pursuing a SPAC — it’s notable that Deliveroo has opted for the LSE. It’s the biggest IPO on the exchange in terms of market cap in nine years (when commodity giant Glencore listed in 2011), and the biggest in terms of money raised since last September (when e-commerce company The Hut Group listed).
“I am very proud that Deliveroo is going public in London – our home,” said Will Shu, Deliveroo’s CEO and co-founder. “As we reach this milestone I want to thank everyone who has helped to build Deliveroo into the company it is today — in particular our restaurants and grocers, riders and customers. In this next phase of our journey as a public company we will continue to invest in the innovations that help restaurants and grocers to grow their businesses, to bring customers more choice than ever before, and to provide riders with more work. Our aim is to build the definitive online food company and we’re very excited about the future ahead.” As with the U.S. exchanges, tech companies are fueling a lot of the action on the LSE at the moment, with four out of the last five IPOs valued at over £1.5 billion in the last five years coming from tech companies.
Regardless of how Deliveroo fares today, the labor controversy facing the company in its main market is one that will continue to play out. A report from the Bureau of Investigative Journalism in the UK found that one in three Deliveroo couriers made less than £8.72, which is the UK national minimum wage for those over 25. In some cases, the disparity of earnings was especially stark: a cyclist in Yorkshire worked 180 hours and was paid the equivalent of £2 per hour, it found. Deliveroo has typically said that its couriers are paid more than £10 an hour on average.
One reason that the story might continue to persist is because it’s about more than just Deliveroo. Earlier this month, Uber reclassified 70,000 drivers in the UK as workers to give them benefits as the result of losing a court case, although Uber Eats — a rival to Deliveroo — was not included in the deal. However, it may not be legal but public pressure that will shift what happens with food delivery drivers. Just Eat, another competitor in the space, last year kicked off an agency worker model that gives drivers the option to work instead under an hourly wage rather than per ride. That becomes, in turn, one possible outcome for how to resolve the situation.
Whether or not investors have an opinion on this matter, it may not be that the so-called “investors revolt” is directly related to a sense of justice for low-paid delivery people, as it is the threat of legal action, losing court cases, and generally finding more costs on the bottom line than originally anticipated in the company’s unit economics.
Those unit economics are indeed a focus for investors, who may be bullish on the basic idea even as disputes over how to run it as an equitable business continue. Going into the IPO, Deliveroo is not profitable, but its loss had been narrowing on a huge surge of sales during the Covid-19 pandemic, not least because many restaurants have been forced to shut down their dine-in businesses and so consumers are turning to services like this to get their fixes of pre-prepared sushi, pizza, jerk chicken and burritos.
Tom Powdrill, head of stewardship at Pensions & Investment Research Consultants, an independent body providing services to pension fund investors, has been one of the more outspoken on how labor practices might play out for investors. In a blog post published today, he points out that issues such as the company’s dual-class structure, which gives less influence to asset managers, has played a part, but so has this ongoing labor issue:
“Reasons for ducking the Deliveroo IPO are varied,” he writes. “Partly it’s a simple question of how successful the business is likely to be. It’s also being shunned due to its treatment of riders who are generally employed on a gig-basis leaving them unentitled to basic benefits. This has two aspects to it. On the one hand some investors may find the employment model too much on its own terms. But it’s also a risk. If Deliveroo is successfully legally challenged on employment status the economics change too, as we saw recently with Uber.”
Post updated with trading price.
We’re going to create an impressive transition effect between images that’s, dare I say, very simple to implement and apply to any site. We’ll be using the kampos library because it’s very good at doing exactly what we need. We’ll also explore a few possible ways to tweak the result so that you can make it unique for your needs and adjust it to the experience and impression you’re creating.
Take one look at the Awwwards Transitions collection and you’ll get a sense of how popular it is to do immersive effects, like turning one media item into another. Many of those examples use WebGL for the job. Another thing they have in common is the use of texture mapping for either a displacement or dissolve effect (or both).
To make these effects, you need the two media sources you want to transition from and to, plus one more that is the map, or a grid of values for each pixel, that determines when and how much the media flips from one image to the next. That map can be a ready-made image, or a <canvas> that’s drawn upon, say, noise. Using a dissolve transition effect by applying a noise as a map is definitely one of those things that can boost that immersive web experience. That’s what we’re after.
Before we can get to the heavy machinery, we need a simple DOM scene. Two images (or videos, if you prefer), and the minimum amount of JavaScript to make sure they’re loaded and ready for manipulation.
<main>
<section>
<figure>
<canvas id="target">
<img id="source-from" src="path/to/first.jpg" alt="My first image" />
<img id="source-to" data-src="path/to/second.jpg" alt="My second image" />
</canvas>
<figure>
</section>
</main>This will give us some minimal DOM to work with and display our scene. The stage is ready; now let’s invite in our main actors, the two images:
// Notify when our images are ready
function loadImage (src) {
return new Promise(resolve => {
const img = new Image();
img.onload = function () {
resolve(this);
};
img.src = src;
});
}
// Get the image URLs
const imageFromSrc = document.querySelector('#source-from').src;
const imageToSrc = document.querySelector('#source-to').dataset.src;
// Load images and keep their promises so we know when to start
const promisedImages = [
loadImage(imageFromSrc),
loadImage(imageToSrc)
];The scene is set, the images are fetched — let’s make some magic! We’ll start by creating the effects we need. First, we create the dissolve map by creating some noise. We’ll use a Classic Perlin noise inside a turbulence effect which kind of stacks noise in different scales, one on top of the other, and renders it onto a <canvas> in grayscale:
const turbulence = kampos.effects.turbulence({ noise: kampos.noise.perlinNoise });This effect kind of works like the SVG feTurbulence filter effect. There are some good examples of this in “Creating Patterns With SVG Filters” from Bence Szabó.
Second, we set the initial parameters of the turbulence effect. These can be tweaked later for getting the specific desired visuals we might need per case:
// Depending of course on the size of the target canvas
const WIDTH = 854;
const HEIGHT = 480;
const CELL_FACTOR = 2;
const AMPLITUDE = CELL_FACTOR / WIDTH;
turbulence.frequency = {x: AMPLITUDE, y: AMPLITUDE};
turbulence.octaves = 1;
turbulence.isFractal = true;This code gives us a nice liquid-like, or blobby, noise texture. The resulting transition looks like the first image is sinking into the second image. The CELL_FACTOR value can be increased to create a more dense texture with smaller blobs, while the octaves=1 is what’s keeping the noise blobby. Notice we also normalize the amplitude to at least the larger side of the media, so that texture is stretched nicely across our image.
Next we render the dissolve map. In order to be able to see what we got, we’ll use the canvas that’s already in the DOM, just for now:
const mapTarget = document.querySelector('#target'); // instead of document.createElement('canvas');
mapTarget.width = WIDTH;
mapTarget.height = HEIGHT;
const dissolveMap = new kampos.Kampos({
target: mapTarget,
effects: [turbulence],
noSource: true
});
dissolveMap.draw();
We are going to pause here and examine how changing the parameters above affects the visual results. Now, let’s tweak some of the noise configurations to get something that’s more smoke-like, rather than liquid-like, say:
const CELL_FACTOR = 4; // instead of 2And also this:
turbulence.octaves = 8; // instead of 1Now we have a more a dense pattern with eight levels (instead of one) superimposed, giving much more detail:
Fantastic! Now back to the original values, and onto our main feature…
It’s time to create the transition effect:
const dissolve = kampos.transitions.dissolve();
dissolve.map = mapTarget;
dissolve.high = 0.03; // for liquid-like effectNotice the above value for high? This is important for getting that liquid-like results. The transition uses a step function to determine whether to show the first or second media. During that step, the transition is done smoothly so that we get soft edges rather than jagged ones. However, we keep the low edge of the step at 0.0 (the default). You can imagine a transition from 0.0 to 0.03 is very abrupt, resulting in a rapid change from one media to the next. Think of it as clipping.
On the other hand, if the range was 0.0 to 0.5, we’d get a wider range of “transparency,” or a mix of the two images — like we would get with partial opacity — and we’ll get a smoke-like or “cloudy” effect. We’ll try that one in just a moment.
Before we continue, we must remember to replace the canvas we got from the document with a new one we create off the DOM, like so:
const mapTarget = document.createElement('canvas');We’re almost there! Let’s create our compositor instance:
const target = document.querySelector(‘#target’);
const hippo = new kampos.Kampos({target, effects: [dissolve]});And finally, get the images and play the transition:
Promise.all(promisedImages).then(([fromImage, toImage]) => {
hippo.setSource({media: fromImage, width, height});
dissolve.to = toImage;
hippo.play(time => {
// a sin() to play in a loop
dissolve.progress = Math.abs(Math.sin(time * 4e-4)); // multiply time by a factor to slow it down a bit
});
});Sweet!
OK, we got that blobby goodness. We can try playing a bit with the parameters to get a whole different result. For example, maybe something more smoke-like:
const CELL_FACTOR = 4;
turbulence.octaves = 8;And for a smoother transition, we’ll raise the high edge of the transition’s step function:
dissolve.high = 0.3;Now we have this:
And, for our last plot twist, let’s also animate the noise itself! First, we need to make sure kampos will update the dissolve map texture on every frame, which is something it doesn’t do by default:
dissolve.textures[1].update = true;Then, on each frame, we want to advance the turbulence time property, and redraw it. We’ll also slow down the transition so we can see the noise changing while the transition takes place:
hippo.play(time => {
turbulence.time = time * 2;
dissolveMap.draw();
// Notice that the time factor is smaller here
dissolve.progress = Math.abs(Math.sin(time * 2e-4));
});And we get this:
That’s it!
This is just one example of what we can do with kampos for media transitions. It’s up to you now to mix the ingredients to get the most mileage out of it. Here are some ideas to get you going:
Whatever you do, be sure to give us a shout about it in the comments.
The post Nailing That Cool Dissolve Transition appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
This literal tech talk (YouTube video embedded in there) by Zach Leatherman is a good time. The talk is sprinkled with fun trickery, so I’m just taking notes on some on it here:
contenteditable on the <body> makes the whole page editable! Did you know document.designMode = "on" does the same thing in JavaScript? (More on making DevTools a design tool.)CMD + click into the editor where you want another one to be, or make it part of a snippet.system-ui. Firefox doesn’t seem to support that, so I guess we need the whole stack. I wonder how close we are to just needing that one value. Iain Bean has more on this in his “System fonts don’t have to be ugly” post.box-decoration-break is a nice little touch for “inline headers.” The use of @supports here makes great sense as it’s not just that one property in use, but several. So, in a non-support situation, you’d want to apply none of it.<progress> in some <li> elements to compare rendering strategies is a neat way to get some perfect UI without even a line of CSS.I think Zach’s overall point is strong: we should question any Single-Page-App-By-Default website building strategy.
As a spoonful of baby bear porridge here, I’d say I’m a fan of both static site generators and JavaScript frameworks. JavaScript frameworks offer some things that are flat-out good ideas for building digital products: components and state. Sometimes that means that client-side rendering is actually helpful for the interactivity and overall feel of the site, but it’s unfortunate when client-side rendering comes along for the ride by default instead of as a considered choice.
Direct Link to Article — Permalink
The post This Web Site is a Tech Talk appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
Amazon will soon be a big part of the space economy in the form of its Kuiper satellite internet constellation, but here on Earth its ambitions are more commonplace: get an accelerator going. They’ve partnered with space-focused VC outfit Seraphim Capital to create a four-week program with (among other things) a $100,000 AWS credit for a carrot.
Applications are open now for the AWS Space Accelerator, with the only requirement that you’re aiming for the space sector and plan to use AWS at some point. Ten applicants will be accepted; you have until April 21 to apply.
The program sounds fairly straightforward: a “technical, business, and mentorship” deal where you’ll likely learn how to use AWS properly, get some good tips from the AWS Partner Network and other space-focused experts on tech, regulations and security, then rub shoulders with some VCs to talk about that round you’re putting together. (No doubt Seraphim’s team gets first dibs, but there doesn’t appear to be any strict equity agreement.)
“Selected startups may receive up to $100,000 in AWS Activate credit,” the announcement says, which does hedge somewhat, but probably legal made them put that in.
There are a good amount of space-focused programs out there, but not nearly enough to cover demand — there are a lot of space startups! And they often face a special challenge of being highly technical, have customers in the public sector and need rather a lot of cash to get going compared with your average enterprise SaaS.
We’ll understand more about the program once the first cohort is announced, likely not for at least a month or two.
Amazon has acquired a startup in India that is helping offline stores go online, the e-commerce group’s latest attempt to make inroads in the world’s second most populous nation where brick and mortar continue to drive more than 95% of sales.
The American e-commerce group said on Tuesday evening that it has acquired Perpule, a four-year-old startup. A regulatory filing showed Amazon Technologies paid $14.7 million to acquire the Indian startup in an all-cash deal. The company is expected to spend an additional $5 million or so to compensate Perpule’s employees.
Perpule, which had raised $6.36 million (per insight platform Tracxn), offers a mobile payments device (point of sale machine) to offline retailers to help them accept digital payments and also establish presence on various mini app stores including those run by Paytm, PhonePe, and Google Pay in India.
“Perpule has built an innovative cloud-based POS offering that enables offline stores in India to better manage their inventory, checkout process, and overall customer experience,” an Amazon spokesperson said in a statement.
“We are excited to have the Perpule team join us to focus on providing growth opportunities for businesses of all sizes in India while raising the bar of the shopping experience for Indian customers.”
Founded in late 2016, the Indian startup’s first product was focused on helping customers avoid queues at super chains such as Shoppers Stop, Spar Hypermarket, Big Bazaar, and More. But the product, said Abhinav Pathak in a recent interview, wasn’t scaling, which is when Perpule pivoted.
The Bangalore-based startup — which counts Prime Venture Partners, Kalaari Capital, and Raghunandan G (founder of neobank Zolve) among its investors — has further expanded in recent years, launching products like StoreSE, which enables a business to support group ordering.
Last year, it also expanded geographically; bringing its offerings to Southeast Asian markets including Indonesia, Malaysia, Thailand, Singapore, and Vietnam.
Amazon has aggressively engaged with physical stores in India in recent years, using their vast presence in the nation to expand its delivery network and warehouses and even just relying on their inventory to drive sales.
The company’s push into physical retail comes as Flipkart, and Reliance Jio Platforms (backed by Facebook and Google), which last year raised over $20 billion, also race to capture this market. The acquisition of Perpule comes less than a week after Google backed DotPe, a startup that offers several similar products.
These neighborhood stores offer all kinds of items, are family-run and pay low wages and little to no rent. Because they are ubiquitous — there are more than 30 million neighborhood stores in India, according to industry estimates — no retail giant can offer a faster delivery. And on top of that, their economics are often better than most of their digital counterparts.
Most inputs have something in common — they are happiest with a companion label! And the happiness doesn’t stop there. Forms with proper inputs and labels are much easier for people to use and that makes people happy too.
In this post, I want to focus on situations where the lack of a semantic label and input combination makes it much harder for all sorts of people to complete forms. Since millions of people’s livelihoods rely on forms, let’s get into the best tips I know for creating a fulfilling and harmonious relationship between an input and a label.
Content warning: In this post are themes of love and relationships.
The love story starts here! Let’s cover the basics for creating happy labels and inputs.
There are two ways to pair a label and an input. One is by wrapping the input in a label (implicit), and the other is by adding a for attribute to the label and an id to the input (explicit).
Think of an implicit label as hugging an input, and an explicit label as standing next to an input and holding its hand.
<label>
Name:
<input type="text" name="name" />
</label>An explicit label’s for attribute value must match its input’s id value. For example, if for has a value of name, then id should also have a value of name.
<label for="name">Name: </label>
<input type="text" id="name" name="name" />Unfortunately, an implicit label is not handled correctly by all assistive technologies, even if for and id attributes are used. Therefore, it is always the best idea to use an explicit label instead of an implicit label.
<!-- IMPLICIT LABEL (not recommended for use) - the label wraps the input. -->
<label>
Name:
<input type="text" name="name" />
</label>
<!-- EXPLICIT LABEL (recommended for use) - the label is connected to an input via "for" and "id" -->
<label for="explicit-label-name">Name: </label>
<input type="text" id="explicit-label-name" name="name" />Each separate input element should only be paired with one label. And a label should only be paired with one input. Yes, inputs and labels are monogamous. ♥️
Note: There’s one sort of exception to this rule: when we’re working with a group of inputs, say several radio buttons or checkboxes. In these cases, a <legend> element is used to group certain input elements, such as radio buttons, and serves as the accessible label for the entire group.
An input with a type="submit" or type="button" does not need a label — the value attribute acts as the accessible label text instead. An input with type="hidden" is also fine without a label. But all other inputs, including <textarea> and <select> elements, are happiest with a label companion.
The content that goes inside of a label should:
One useful thing you can do with the content in a label is add formatting hints. For example, the label for <input type="date" id="date"> will be <label for="date"> as we’d expect. But then we can provide a hint for the user that the date needs to be entered in a specific format, say DD-DD-YYYY, in the form of a <span> between the label and input that specifies that requirement. The hint not only specifies the date format, but has an id value that corresponds to an aria-describedby attribute on the input.
<!-- Describes what the input is for - should be plain text only -->
<label for="date">Start date</label>
<!-- Describes additional information, usually about formatting -->
<span id="date-format">(DD-MM-YYYY):</span>
<input type="date" id="date" aria-describedby="date-format" min="2021-03-01" max="2031-01-01" />This way, we get the benefit of a clear label that describes what the input is for, and a bonus hint to the user that the input needs to be entered in a specific format.
The following tips go beyond the basics to explain how to make sure a label and input are as happy as can be.
There is a WCAG success criterion that states the visual order of a page should follow the order in which elements appear in the DOM. That’s because:
A user with low vision who uses a screen magnifier in combination with a screen reader may be confused when the reading order appears to skip around on the screen. A keyboard user may have trouble predicting where focus will go next when the source order does not match the visual order.
Think about it. If we have some standard HTML where the label comes before the input:
<label for="orange">Orange</label>
<input type="checkbox" id="orange" name="orange">That places the label before the input in the DOM. But now let’s say our label and form are inside a flexible container and we use CSS order to reverse things where the input visually comes before the label:
label { order: 2; }
input { order: 1; }A screen reader user, who is navigating between elements, might expect the input to gain focus before the label because the input comes first visually. But what really happens is the label comes into focus instead. See here for the difference between navigating with a screen reader and a keyboard.
So, we should be mindful of that. It is conventional to place the label on the right-hand side of the input for checkboxes and radio buttons. This can be done by placing the label after the input in the HTML, ensuring the DOM and visual order match.
<form>
<!-- Checkbox with label on the right -->
<span>
<input type="checkbox" id="orange" name="orange">
<label for="orange">Orange</label>
</span>
<!-- Radio button with label on the right -->
<span>
<input type="radio" id="banana" name="banana">
<label for="banana">Banana</label>
</span>
<!-- Text input with label on the left -->
<span>
<label for="apple">How do you like them apples?</label>
<input type="text" id="apple" name="apple">
</span>
</form>Whether an input is written from scratch or generated with a library, it is a good idea to check your work using a screen reader. This is to make sure that:
for and id attributes.
Over the last few years, I have used JavaScript libraries, like downshift, to build complex form elements such as autocomplete or comboboxes on top of native HTML ones, like inputs or selects. Most libraries make these complex elements accessible by adding ARIA attributes with JavaScript.
However, the benefits of native HTML elements enhanced using JavaScript are totally lost if JavaScript is broken or disabled, making them inaccessible. So check for this and provide a server-rendered, no-JavaScript alternative as a safe fallback.
Check out these basic form tests to determine how an input and its companion label or legend should be written and announced by different screen readers.
Connecting a label and an input is important, but just as important is keeping the label visible. Clicking or tapping a visible label focuses its input partner. This is a native HTML behavior that benefits a huge number of people.
Imagine a label wanting to proudly show its association with an input:
That said, there are going to be times when a design calls for a hidden label. So, if a label must be hidden, it is crucial to do it in an accessible way. A common mistake is to use display: none or visibility: hidden to hide a label. These CSS display properties completely hide an element — not only visually but also from screen readers.
Consider using the following code to visually hide labels:
/* For non-natively-focusable elements. For natively focusable elements */
/* Use .visually-hidden:not(:focus):not(:active) */
.visually-hidden {
border-width: 0 !important;
clip: rect(1px, 1px, 1px, 1px) !important;
height: 1px !important;
overflow: hidden !important;
padding: 0 !important;
position: absolute !important;
white-space: nowrap !important;
width: 1px !important;
}Kitty Giraudel explains in depth how to hide content responsibly.
To preserve and maintain a healthy relationship between inputs and labels, there are some things not to do when pairing them. Let’s get into what those are and how to prevent them.
There are certain types of inputs that are unsupported In some older desktop browsers. For example, an input that is type="date" isn’t supported in Internet Explorer (IE) 11, or even in Safari 141 (released September 2020). An input like this falls back to type="text". If a date input does not have a clear label, and it automatically falls back to a text input in older browsers, people may get confused.
Here is why a placeholder attribute on an input should not be used in place of a label:
placeholder is in danger of being cut-off on smaller devices, or when a page is translated in the browser. In contrast, the text content of a label can easily wrap onto a new line.placeholder text on their large retina screen, in a well-lit room, in a distraction-free environment, doesn’t mean everyone else can. A placeholder can make even those with good vision scrunch their eyes up and eventually give up on a form.
placeholder becomes invisible — both visually and to screen readers. If someone has to back-track to review information they’ve entered in a form, they’d have to delete what was entered just to see the placeholder again.placeholder attribute is not supported in IE 9 and below, and disappears when an input is focused in IE 11. Another thing to note: the placeholder color is unable to be customized with CSS in IE 11.Placeholders are like the friend that shows up when everything is perfect, but disappears when you need them most. Pair up an input with a nice, high-contrast label instead. Labels are not flaky and are loyal to inputs 100% of the time.
The Nielsen Norman Group has an in-depth article that explains why placeholders in form fields are harmful.
When no label is present, some screen readers will look for adjacent text and announce that instead. This is a hit-and-miss approach because it’s possible that a screen reader won’t find any text to announce.
The below code sample comes from a real website. The label has been substituted with a <span> element that is not semantically connected to the input.
<div>
<span>Card number</span>
<div>
<input type="text" value="" id="cardNumber" name="cardNumber" maxlength="40">
</div>
</div>The above code should be re-written to ensure accessibility by replacing the span with a label with for="cardNumber" on it. This is by far the most simple and robust solution that benefits the most people.
While a label could be substituted with a span that has an id with a value matching the input’s aria-labelledby attribute, people won’t be able to click the span to focus the input in the same way a label allows. It is always best to harness the power of native HTML elements instead of re-inventing them. The love story between native input and label elements doesn’t need to be re-written! It’s great as-is.
Only plain text should be included inside a label. Avoid inserting things such as headings, or interactive elements such as links. Not all screen readers will announce a label correctly if it contains something other than plain text. Also, if someone wants to focus an input by clicking its label, but that label contains a link, they may click the link by mistake.
<form>
<div>
<!-- Don't do this -->
<input type="checkbox" id="t-and-c" name="name" />
<label for="t-and-c">I accept the <a href="https://link.com">terms and conditions</a></label>
</div>
<div>
<!-- Try this -->
<input type="checkbox" id="t-and-c2" name="name" />
<label for="t-and-c2">I accept the terms and conditions.</label>
<span>Read <a href="https://link.com">terms and conditions</a></span>
</div>
</form>I always find that real-life examples help me to properly understand something. I searched the web and found examples of labels and inputs from a popular component library and website. Below, I explain where the elements fall short and how they can be improved to ensure a better pairing.
MaterialUI is a React component library based on Google’s design system. It includes a text input component with a floating label pattern that has become a popular go-to for many designers and developers:
Clicking on the input feels smooth and looks great. But that’s the problem. Its qualities are mostly skin-deep.
At the time of writing this post, some issues I found with this component include:
id and aria-describedby. This means that not all screen readers will be able to associate the helper message with the input.Adam Silver also explains why float labels are problematic and gets into a detailed critique of Material’s text input design.
The Huffpost website has articles containing a newsletter subscription form:
At the time of writing this blog post, the email input that Huffpost uses could benefit from a number of improvements:
aria-label attribute on the input.placeholder and input values are a tiny 11px, which can be hard to read.A surprising number of people struggle to enter information into poorly-constructed inputs. That list includes people with cognitive, motor and physical disabilities, autism spectrum disorders, brain injuries, and poor vision. Other people who struggle include those in a hurry, on a poor connection, on a small device, on an old device, and unfamiliar with digital forms, among many others.
Additionally, there are numerous reasons why JavaScript might break or be switched off in a browser, meaning inputs become dysfunctional or completely inaccessible. There are also people who are fully capable of viewing a web page but who may choose to use a keyboard along with a screen reader.
The message I want to get across is that happy label and input pairs are crucial. It doesn’t matter if your form is beautiful if it is unusable. I can bet that almost everyone would rather fill out an ugly but easy-to-use form rather than a pretty one that causes problems.
I want to warmly thank the following people for helping me with this post: Eric Eggert, Adam Silver, Dion Dajka, and Kitty Giraudel. Their combined accessibility knowledge is a force to be reckoned with!
The post HTML Inputs and Labels: A Love Story appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
Dave and I launched a Patreon for ShopTalk Show. You get two completely priceless things for backing us:
I think the Discord might be my favorite thing we ever done. Sorry if I’m stoking the FOMO there, but just saying, it’s a good gang. My personal intention is to be helpful in there, but everyone else is so helpful themselves that I’ve actually learned more than I’ve shared.
Direct Link to Article — Permalink
The post ShopTalk Patreon appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
Vote counting begins today in the historic effort to unionize Amazon’s Bessemer, Alabama fulfillment center. The warehouse — which opened exactly a year ago to meet ramping up demand as COVID-19 bore down on the U.S. — has become ground zero for one of the most import labor efforts in modern American history.
Voting began by mail on February 8, after Amazon repeatedly attempted to delay the vote or force workers to submit ballots in-person, in spite of pandemic restrictions. Things have gotten predictably heated in the days and weeks leading up to yesterday’s official deadline. Though even by the standards of Amazon’s aggressive public relations strategy, thing went surprisingly far.
In particular, the e-commerce giant leveraged Twitter feeds as part of an aggressive anti-union strategy. The company simultaneously sought to bolster its image of existing working conditions while confronting progressive/leftist politicians like Vermont Senator Bernie Sanders, who played a key role in pushing the company toward the $15/hour warehouse minimum wage it now celebrates.
According to reports, the company’s scorched-earth approach against Sanders and fellow New England Senator Elizabeth Warren were spurred on from the top. Founder Jeff Bezos — who will abdicate his CEO position later this year — was said to have encouraged the offensive. Employees at the companies were said to have flagged the offending tweets internally for suspicious activity. Those tickets were reportedly closed.
After antagonist tweets and denying widespread and longstanding reports about Amazon workers peeing in bottles over fears of falling behind on quotas, the Amazon News Twitter reverted to a more positive approach. It has however, continued activity around the vote, including a bid to install video cameras for monitoring boxes carrying ballots — a bid the National Labor Relations Board (NLRB) has since rejected.
While the vote counting kicks off today, don’t expect immediate results. The process is a methodical and deliberate one. Among other things, there are processes in place for either side to object. It’s clear from Amazon’s recent behavior that the company is well aware that this is far more consequential than the 6,000 or so workers currently employed by the Bessemer location. If the company prevails, it will position the decision as validation of its working conditions. If workers vote to unionize, meanwhile, this could well start a chain reaction across the company.
BIRMINGHAM, AL – MARCH 05: A truck passes as Congressional delegates visit the Amazon Fulfillment Center after meeting with workers and organizers involved in the Amazon BHM1 facility unionization effort, represented by the Retail, Wholesale, and Department Store Union on March 5, 2021 in Birmingham, Alabama. Workers at Amazon facility currently make $15 an hour, however they feel that their requests for less strict work mandates are not being heard by management. (Photo by Megan Varner/Getty Images)
This week, workers at Amazon’s Germany facilities are going on strike for four days, following a similar move in Italy last week.
“It’s not just workers in Alabama, it’s workers everywhere who are saying to Jeff Bezos that enough is enough. No matter what language they speak, Amazon workers around the globe will not stand for the working conditions they’ve been forced to endure for too long,” Retail, Wholesale and Department Store Union (RWDSU) President Stuart Applebaum said in a statement.
The NLRB oversees the vote counting. If workers vote to unionize, Bessemer workers will join the RWDSU. The organization has also seen its share of pushback from Amazon. As the company told TechCrunch last week:
Stuart Appelbaum, Chief Disinformation Officer of RWDSU, in an attempt to save his long declining union, is taking alternative facts to a whole new level. But our employees are smart and know the truth—starting wages of $15 or more, health care from day one, and a safe and inclusive workplace. We encourage all of our employees to vote.
Ballots have been sent to the NLRB’s Birmingham offices. There are a number of grounds on which either side can contest the results. These include everything from signatures to whether the person who cast a vote is, in fact, an eligible employee of Amazon. Even after votes are counted, things are likely to drag on. Court battles seem a likely outcome, moving forward. From there, things could ultimately stretch on for weeks or months.
The battle is a high stakes one that has made unusual political allies from opposite sides of the aisle. There aren’t too many events that have united politicians ranging from Marco Rubio on one side and Sanders, Warren and Joe Biden on the other. That goes double for something as traditionally divisive as labor unions.
“This campaign has already been a victory in many ways,” Appelbaum said in a statement issued late last week. “Even though we don’t know how the vote will turn out, we believe we have opened the door to more organizing around the country.”
David Bushell in ”Changing CSS for Good“:
I’m dropping “
left“ and “right“ from my lexicon. The new CSS normal is all about Logical Properties and Values […] It can be as easy as replacing left/right with inline start/end. Top/bottom with block start/end. Normal inline flow, Flexbox, and Grid layouts reverse themselves automatically.
I figured it made sense as a “You want…” style post. Geoff has been documenting these properties nicely in the Almanac.
The post You want margin-inline-start appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
Hello! Satarupa Chatterjee from Cloudinary. There is a big change coming from Google in May 2021 having to do with their Core Web Vitals (CWVs). It’s worth paying attention here, as this is going to be a SEO factor.
I recently spoke with Tamas Piros about CWVs. The May 2021 update will factor in CWVs, along with other factors like mobile-friendliness and safe browsing, to generate a set of benchmarks for search rankings. Doubtless, the CWVs will directly affect traffic for websites and apps alike. Tamas is a developer-experience engineer at Cloudinary, a media-optimization expert, and a Google developer-expert in web technologies and web performance.
Here’s a written version of the video above, where the questions (Qs) are me, Satarupa, asking and Tamas answering (As).
A: As a dominant force in the search space, Google has researched in depth what constitutes a superb user experience, arriving at three important factors, which the company calls, collectively, the Core Web Vitals.
Before explaining them, I’d like to recommend an informative article, published last May on the Chromium Blog, titled The Science Behind Web Vitals. At the bottom of the piece are links to papers on the research that led to the guidelines for accurately evaluating user experiences.
Now back to the three Core Web Vitals. The first one affects page-load speed, which Google calls Largest Contentful Paint (LCP) with a recommendation of 2.5 seconds or less for the largest element on a page to load.
The second metric is First Input Delay (FID), which is a delta between a user trying to interact with a page, and the browser effectively executing that action. Google recommends 100 milliseconds or less.
The third and last metric is Cumulative Layout Shift (CLS), which measures how stable a site is while it’s loading or while you’re interacting with it. In other words it is a measurement of individual layout shifts as well as unexpected layout shifts that happen during the lifespan of a page. The calculation involves impact and distance fractions which are multiplied together to give a final value. Google advocates this value to be 0.1 or less.
A: Behind the ranking of Google search results are many factors, such as whether you use HTTPS and how you structure your content. Let’s not forget that relevant and well-presented content is as important as excellent page performance. The difference that core web vitals will make cannot be overstated. Google returns multiple suggestions for every search, however remember that good relevance is going to take priority. In other words good page experience will not override having great relevant content For example, if you search for Cloudinary, Google will likely show the Cloudinary site at the top of the results page. Page experience will become relevant when there are multiple available results, for a more generic search such as ‘best sports car’. In this case Google establishes that ranking based on the page’s user experience, too, which is determined by the Core Web Vitals.
A: Businesses should focus primarily on meeting or staying below the threshold of the Core Web Vitals. However, they must also keep in mind that their page load times could be affected by other metrics, such as the length of time the first purchase takes and the first contentful paint.
For example, to find out what contributes to a bad First Input Delay—the FID, check the total blocking time and time to interact. Those are also vitals, just not part of the Core Web Vitals. You can also customize metrics with the many robust APIs from Google.. Such metrics could prove to be invaluable in helping you identify and resolve performance issues.
A: What’s important to remember with regards to LCP is that we are talking about the largest piece of content that gets loaded on a page, and that is visible in the viewport (that is, it’s visible above the fold). Due to popular UX design patterns it’s likely that the largest, visible element is a hero image.
Google watches for <img> elements as well as <image> elements inside an SVG element. Video elements are considered too but only if they contain a poster attribute. Also of importance to Google are block-level elements, such as text-related ones like <h1>, <h2>, etc., and <span>.
All that means that you must load the largest piece of content as fast as possible. If your LCP is a hero image, be sure to optimize it—but without degrading the visual effects. Check out Cloudinary’s myriad effective and intuitive options for optimization. If you can strike a good balance between the file size and the visual fidelity of your image, your LCP will shine.
A: According to Google, sites that meet the thresholds of the Core Web Vitals enjoy a 24-percent lower abandonment rate. The more you adhere to Google’s guidelines, the more engaging your site or app becomes and the faster your sales will grow. Needless to say, an appealing user experience attracts visitors and retains them, winning you an edge over the competition. Of course bear in mind the other search optimization guidelines set out by Google.
Again, be sure to optimize images, especially the most sizable one in the viewport, so that they load as fast as possible.
A: Late last year, Google held a conference and there were multiple talks touching upon this exact subject. All major changes will go into effect on a per-year basis, and Google has committed to announcing them well in advance.
Behind the scenes, Google is constantly collecting data from the field and checking them against user expectations. The first contentful paint, which I mentioned before, is under consideration as another Core Web Vital. Also, Google is thinking about reducing the yardstick for the First Input Delay metric—the FID, remember?—from 100 milliseconds to 75 or even 50.
Beyond that, Google has received a lot of feedback about some of the Core Web Vitals not working well for single-page apps. That’s because those apps are loaded only once. Even if they score an ideal Cumulative Layout Shift—that’s CLS—as you click around the page, things might move around and bring down the score. Down the road, Google might modify CLS to better accommodate single-page apps.
Also on Google’s radar screen are metrics for security, privacy, and accessibility. Google promises to fine-tune the current metrics and launch new ones more frequently than major releases, including the introduction of new Core Web Vital metrics.
So, change is the only constant here. I see a bright future for the vitals and have no doubt that we’re in good hands. Remember that Google vigilantly collects real user data as analytics to help figure out the appropriate standards. As long as you keep up with the developments and ensure that your site or app comply with the rules, you’ll get all greens throughout the scoreboard. That’s a great spot to be in.
Cloudinary offers myriad resources on media experience (MX), notably the MX Matters podcast, which encompasses experts’ take on the trends in today’s visual economy along with bulletins on new products and enhancements. Do check them out.
The post Deliver Enhanced Media Experiences With Google’s Core Web Vitals appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
There is a lot of hype on the :is() pseudo-selector lately, probably because now that Safari 14 has it, it’s supported across all the major browsers. You’ve got Miriam tweeting about it, Kevin Powell doing a video, Šime getting it into the Web Platform News, and Robin mentioning it. Bramus really puts a point on it with these “three important facts”:
1. The selector list of
:is()is forgiving
2. The specificity of:is()is that of its most specific argument
3.:is()does not work with pseudo-element selectors (for now)
Plus, of course, it’s main functionality which is making otherwise rather verbose, complex, and error-prone selectors easier to write. The specificity thing is extra-interesting. Miriam notes some trickery you could do with it, like juicing up specificity without actually selecting anything.
Say you wanted to use the .button class to select, but give it a ton of specificity
:is(.button, #increase#specificity) {
/* specificity is now (0, 1, 0, 0) instead of (0, 0, 1, 0)
}I’ve done silly stuff like this in the past:
.button.button.button {
/* forcing the selector to be (0, 0, 3, 0) instead of (0, 0, 1, 0) */
/* doesn't actually require element to have three button classes lol */
}The :is() trick seems a little more understandable to me.
But what if you want to go the other way with specificity and lower it instead? Well, that’s the whole point of the :where() pseudo-selector. Functionally, it’s exactly the same as :is(). You give it a comma-separated list of things to select as part of the selector chain, and it does, with the same forgiving nature. Except, the specificity of the entire :where() part is zero (0).
Kevin showed off an interesting gotcha with :is() in the video:
.card :is(.title, p) {
color: red;
}
.card p {
color: yellow;
}You might think yellow will win out here, but the presence of .title in that :is() selector on top makes the specificity of that selector (0, 0, 2, 0) winning out over the (0, 0, 1, 1) below.
This is where we could consider using :where() instead! If we were to use the :where() pseudo-selector instead:
.card :where(.title, p) {
color: red;
}
.card p {
color: yellow;
}Then yellow would win, because the top selector lowers to (0, 0, 1, 0) specificity, losing to the bottom selector’s (0, 0, 1, 1).
Which one should you use? Ya know what, I’m not really sure if there is super solid time-tested advice here. At least we have both options available, meaning if you get into a pickle, you’ve got tools to use. Time has taught me that keeping specificity low is generally a healthier place to be. That gives you room to override, where if you’re riding high with specificity you have fewer options. But the zero specificity of :where() is pretty extreme and I could see that leading to confusing moments, too. So my gut is telling me you might wanna start with :is(), unless you notice you need to mix in a higher-specificity selector; if you do, back off to :where().
The post :where() has a cool specificity trick, too. appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
With a high of F and a low of 15F. Currently, it's 14F and Clear outside. Current wind speeds: 13 from the Southwest Pollen: 0 S...
