Link tags: check

Accessibility for designer: where do I start? by Stéphanie Walter - UX Researcher & Designer.

Stéphanie has gathered a goldmine of goodies:

Articles, resources, checklists, tools, plugins and books to design accessible products

Solid Start

A four-point checklist for inclusive design:

Are you a person that makes digital things for other people? Awesome—because this page is all about making things for people. There are four ways you can improve your creation for everybody. All four are testable, fixable and they improve usability for everybody.

Custom Styling Form Inputs With Modern CSS Features | CSS-Tricks

It’s now easier than ever to style form controls without sacrificing semantics and accessibility:

The reason is that we can finally style the ::before and ::after pseudo-elements on the <input> tag itself. This means we can keep and style an <input> and won’t need any extra elements. Before, we had to rely on the likes of an extra <div> or <span>, to pull off a custom design.

The demo is really nice. And best of all, you can wrap all of these CSS enhancements in a feaure query:

Hopefully, you’re seeing how nice it is to create custom form styles these days. It requires less markup, thanks to pseudo-elements that are directly on form inputs. It requires less fancy style switching, thanks to custom properties. And it has pretty darn good browser support, thanks to @supports.

8 DOM features you didn’t know existed - LogRocket Blog

If you ignore the slightly insulting and condescending clickbaity title, this is a handy run-down of eight browser features with good support:

1. extra arguments in addEventListener(),
2. scrollTo(),
3. extra arguments in setTimeout() and setInterval(),
4. the defaultChecked property for checkboxes,
5. normalize() and wholeText for strings of text,
6. insertAdjacentElement() and insertAdjacentText(),
7. event.detail, and
8. scrollHeight and scrollWidth.

Is CSS Turing Complete? | Lara Schenck

This starts as a good bit of computer science nerdery, that kind of answers the question in the title:

Alone, CSS is not Turing complete. CSS plus HTML plus user input is Turing complete!

And so the takeaway here is bigger than just speculation about Turing completeness:

Given that CSS is a domain-specific language for styling user interface, this makes a lot of sense! CSS + HTML + Human = Turing complete.

At the end of that day, as CSS developers that is the language we really write. CSS is incomplete without HTML, and a styled interface is incomplete without a human to use it.

Security Checklist

Exactly what it sounds like: a checklist of measures you can take to protect yourself.

Most of these require a certain level of tech-savviness, which is a real shame. On the other hand, some of them are entirely about awareness.

CSS-only multiple choice quizzing - Matthew Somerville

In which Matthew disects a multiple choice quiz that uses CSS to do some clever logic, using the :checked pseudo-class and counter-increment.

Oh, and this is how he realised it wasn’t using JavaScript:

I have JavaScript disabled on my phone because a) it cuts out most of the ads, b) it cuts out lots of bandwidth and I have a limited data plan, and c) my battery lasts longer because it’s not processing tons of code to show me some text (cough, Medium).

The Font Loading Checklist—zachleat.com

This checklist came in very handy during a performance-related workshop I was running today (I may have said the sentence “Always ask yourself What Would Zach Do?”).

1. Start Important Font Downloads Earlier (Start a Web Font load)
2. Prioritize Readable Text (Behavior while a Web Font is loading)
3. Make Fonts Smaller (Reduce Web Font load time)
4. Reduce Movement during Page Load (Behavior after a Web Font has loaded)

The first two are really straightforward to implement (with rel="preload" and font-display). The second two take more work (with subsetting and the font loading API).

Front-End Performance Checklist

A handy pre-launch go/no-go checklist to run through before your countdown.

Nutrition Cards for Accessible Components A11Y Expectations

A handy bunch of checklists from Dave for creating accessible components. Each component gets a card that lists the expectations for interaction.

On Designing and Building Toggle Switches

Sara shows a few different approaches to building accessible toggle switches:

Always, always start thinking about the markup and accessibility when building components, regardless of how small or simple they seem.

Why Suffolk Libraries chose to build their own self-service app.

It’s so great to see the initial UX work that James and I prototyped in a design sprint come to fruition in the form of a progressive web app!

In the case of this web-app, if the tablets go offline, they will still store all the transactions that are made by customers. Once the tablet comes back online, it will sync it back up to the server. That is, essentially, what a Progressive Web App is — a kind of a website with a few more security and, most importantly, offline features.

Nobody Said CSS Is Easy

One thing I gained a stronger awareness of (simply from working with checkboxes) is that it’s important to progressively enhance UI components, so that a fancy custom one is able to fall back to the default browser styles and functionality. This way, a user can still access the UI if JavaScript or CSS fail.

Vox Product Accessibility Guidelines

Accessibility isn’t a checklist …but this checklist is a pretty damn good starting point. I really like that it’s organised by audience: designers, engineers, project managers, QA, and editorial. You can use this list as a starting point for creating your own—tick whichever items you want to include, and a handy copy/paste-able version will be generated for you.

Under-Engineered Custom Radio Buttons and Checkboxen | Adrian Roselli

Stylish and accessible checkboxes and radio buttons accompanied by an explanation of the CSS involved.

No images were harmed in the making of these form controls.

WTF, forms?

Here’s a CSS file that will give you a bit more control over styling some form elements. The thinking behind the CSS for each element is explained nice and clearly.

Front-End Performance Checklist 2017

You can print out this PDF and then have the satisfaction of ticking off each item on the list as you build your website.

We’ve updated the radios and checkboxes on GOV.UK | GDS design notes

I always loved the way that Gov.uk styled their radio buttns and checkboxes with nice big visible labels, but it turns out that users never used the label area. And because it’s still so frickin’ hard to style native form elements, custom controls with generated content is the only way to go if you want nice big hit areas.

Vox Product Accessibility Guidelines

I’m not a fan of the checklist approach to accessibility, but this checklist of checklists makes for a handy starting point and it’s segmented by job role. Tick all the ones that apply to you, and this page will generate a list for you to copy and paste.

Front-End Style-Guides: Definition, Requirements, Component Checklist

You know that front-end pattern libraries have hit the mainstream when the Nielsen Norman Group get in on the action.

As ever, I’m not sure their sweeping generalisations can be applied to every project, but their checklist approach makes for a good starting point.