Tags: cc

409

sparkline

Maybe You Don’t Need a Date Picker | Adrian Roselli

In some situations, a date picker is overkill:

I have relied on plain text inputs as date fields with custom validation for the site, typically using the same logic on the client and the server. For known dates — birthdays, holidays, anniversaries, etc — it has tested well.

5 Keys to Accessible Web Typography | Better Web Type

Some excellent explanations for these five pieces of sensible typography advice:

  1. Set your base font size in relative units
  2. Check the colour of your type and only then its contrast
  3. Use highly legible fonts
  4. Shape your paragraphs well
  5. Correctly use the heading levels

Initial thoughts on standardizing form controls | Greg Whitworth

Greg has done a lot of research into developer frustrations with customising form controls.

My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.

How to Section Your HTML | CSS-Tricks

A deep dive with good advice on using—and labelling—sectioning content in HTML: nav, aside, section, and article.

Drop caps & design systems - Vox Product Blog

Sit down and listen to a story from uncle Ethan.

Baking accessibility into components: how frameworks help

A very thoughtful post by Hidde that draws a useful distinction between the “internals” of a component (the inner workings of a React component, Vue component, or web component) and the code that wires those components together (the business logic):

I really like working on the detailed stuff that affects users: useful keyboard navigation, sensible focus management, good semantics. But I appreciate not every developer does. I have started to think this may be a helpful separation: some people work on good internals and user experience, others on code that just uses those components and deals with data and caching and solid architecture. Both are valid things, both need love. Maybe we can use the divide for good?

An Introduction to ARIA States | a11y with Lindsey

A very useful explanation of the ARIA attributes relating to state:

  1. aria-expanded,
  2. hidden,
  3. aria-hidden, and
  4. aria-current.

Reducing motion with the picture element

Here’s a clever tiny lesson from Dave and Brad: you can use prefers-reduced-motion in the media attribute of the source element inside picture.

Accessible Icon Buttons — Sara Soueidan – Freelance-Front-End UI/UX Developer

Sara runs through the many ways of providing an accessible name to an icon button, backed up with Scott’s testing.

Accessible Color Generator – Learn UI Design

This looks like a really useful tool for generating accessibile colour combinations from a starting colour.

Lighthouse | Eric Bailey

What if accessibility were a ranking signal for Google search results?

Here’s a thought: what if Google put its thumb on the scale again, only this time for accessibility? What if it treated the Lighthouse accessibility score as a first-class ranking metric?

Welcome to Acccessible App | Accessible App

A very welcome project from Marcus Herrmann, documenting how to make common interaction patterns accessible in popular frameworks: Vue, React, and Angular.

A report from the AMP Advisory Committee Meeting – Terence Eden’s Blog

I completely agree with every single one of Terence’s recommendations here. The difference is that, in my case, they’re just hot takes, whereas he has actually joined the AMP Advisory Committee, joined their meetings, and listened to the concerns of actual publishers.

He finds:

  • AMP isn’t loved by publishers
  • AMP is not accessible
  • No user research
  • AMP spreads fake news
  • Signed Exchanges are not the answer

There’s also a very worrying anti-competitive move by Google Search in only showing AMP results to users of Google Chrome.

I’ve been emailing with Paul from the AMP team and I’ve told him that I honestly think that AMP’s goal should be to make itself redundant …the opposite of the direction it’s going in.

As I said in the meeting - if it were up to me, I’d go “Well, AMP was an interesting experiment. Now it is time to shut it down and take the lessons learned back through a proper standards process.”

I suspect that is unlikely to happen. Google shows no sign of dropping AMP. Mind you, I thought that about Google+ and Inbox, so who knows!

Good point!

Columbia & Elm; Fairfield & Gloucester. — Ethan Marcotte

Coffee talk with Ethan Marcotte. Today’s special: inclusivity.

I want to get there: to have nuanced discussions about text descriptions; I want to read poetry in alt text; to have our work’s success measured by how broadly it can be accessed; to create moving, beautiful experiences for people who may not use the web like I do.

Naming things to improve accessibility

Some good advice from Hidde, based on his recent talk Six ways to make your site more accessible.

Accessibility Events | CSS-Tricks

If you’re using Apple’s VoiceOver, both your phone and your computer will broadcast your assumed disability to the entire internet, unless and until you specifically tell it to stop.

Improving accessibility with accessibility acceptance criteria — Paul Hayes

Wouldn’t it be great if every component in your design system had accessibility acceptance criteria? Paul has some good advice for putting those together:

  • Start with accessibility needs
  • Don’t be too generic
  • Don’t define the solution
  • Iterate criteria

Defining Productivity — Jeremy Wagner

We have a tendency in our line of work to assume that what benefits us as developers translates to a benefit for those who use what we make. This is an unsafe assumption.

Building accessible websites and apps is a moral obligation | Go Make Things

  • Morality is not always relative.
  • You’re a web professional.
  • The web is accessible out-of-the-box. We break it.
  • It’s not on people with disabilities to tell you how you screwed up.
  • It should be easier. This is our job.

Accessibility for Vestibular Disorders: How My Temporary Disability Changed My Perspective · An A List Apart Article

This is a fascinating insight into what it’s like to use the web if you’ve got vertigo (which is way more common than you might think):

Really, there are no words to describe just how bad a simple parallax effect, scrolljacking, or even background-attachment: fixed would make me feel. I would rather jump on one of those 20-G centrifuges astronauts use than look at a website with parallax scrolling.

Every time I encountered it, I would put the bucket beside me to good use and be forced to lie in bed for hours as I felt the room spinning around me, and no meds could get me out of it. It was THAT bad.