Tags: accessibility

301

sparkline

Weeknotes #5 — Paul Robert Lloyd

A nice counterpoint to the last time I linked to Paul’s weeknotes:

However, there’s another portion of the industry, primarily but not exclusively within the public sector, where traditional development approaches (progressive enhancement, server-side rendering) remain prevalent, or less likely to be dismissed, at least. Because accessibility isn’t optional when your audience is everyone, these organisations tend to attract those with a pragmatic outlook who like to work more diligently and deliberately.

Revisiting the abbr element

Ire takes a deep dive into implementing an accessible tool tip.

How do you figure? | CSS-Tricks

A good reminder from Chris—prompted by Scott O’Hara’s article—that the figcaption element and the alt attribute do different things. If you use an empty alt attribute on an img inside a figure, then your figcaption element is captioning nothing …and no, using the same text for both is not the solution.

Exclusive Design

Vasilis has published his magnificent thesis online. It’s quite lovely:

You can read this thesis in a logical order, which is the way that I wrote it. It starts with a few articles that explore the context of my research. It then continues with four chapters in which I describe the things I did. I end the thesis with four posts with findings, conclusions and recommendations.

  1. Everybody’s paradox
  2. The defaults suck
  3. Flipping things
  4. Fuckup’s mama
  5. More death to more bullshit
  6. Design like it’s 1999
  7. Invisible Animations
  8. Semantics schmemantics
  9. Stress cases
  10. Coders should learn how to design
  11. Add nonsense
  12. Conclusion

Make Your ARIA Labels Sing on Key — Knowbility

A good look at the (over)use of the aria-label attribute that confirms the first rule of ARIA.

It’s What You Make, Not How You Make It.

How did I miss this great post from 2016 by one of my favourite people‽ It’s even more more relevant today.

To me it doesn’t matter whether you write your HTML and CSS by hand or use JavaScript to generate it for you. What matters is the output, how it is structured, and how it is served to the client. When we allow our tools to take precedent over the quality of our output the entire web suffers. Sites are likely to be less accessible, less performant, and suffer from poor semantics.

The Ethics of Performance - TimKadlec.com

When you stop to consider all the implications of poor performance, it’s hard not to come to the conclusion that poor performance is an ethical issue.

The Elements of UI Engineering - Overreacted

These are good challenges to think about. Almost all of them are user-focused, and there’s a refreshing focus away from reaching for a library:

It’s tempting to read about these problems with a particular view library or a data fetching library in mind as a solution. But I encourage you to pretend that these libraries don’t exist, and read again from that perspective. How would you approach solving these issues?

The power of progressive enhancement

Andy’s slides:

We dive into why progressive enhancement is important and how we can leverage the power of Vanilla JavaScript, Web Components and modern CSS to deliver a hack-free, lightweight and progressive experience for our users.

as days pass by — Why isn’t it their job

The secret is: if you use semantic HTML, then they do the work, not you. Their browser does the work, not you. If your pages use semantic HTML, you’re not going to get bug reports saying that your web app doesn’t work in a screenreader, or your buttons don’t work without mouse clicks, or your site doesn’t show anything on a Yoyodyne SuperPhone 3 running FailBrowser, because it will and they will and it will. And using semantic HTML elements is no more effort; it’s just as easy to use main as it is to use div id="main". Easier, even.

ANDI - Accessibility Testing Tool - Install

Another bookmarklet for checking accessibility—kind of like tota11y—that allows to preview how screen readers will handle images, focusable elements, and more.

Using aria-live

A terrific explanation of the aria-live attribute from Ire. If you’re doing anything with Ajax, this is vital knowledge.

Drupal’s commitment to accessibility | Dries Buytaert

Shots fired!

I’ve come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.

Home  |  web.dev

I guess this domain name is why our local developmemnt environments stopped working.

Anyway, it’s a web interface onto Lighthouse (note that it has the same bugs as the version of Lighthouse in Chrome). Kind of like webhint.io.

Designing, laws, and attitudes. — Ethan Marcotte

Ethan ponders what the web might be like if the kind of legal sticks that exist for accessibility in some countries also existed for performance.

Bruce Lawson’s personal site  : Screenreader support for text-level semantics

Bruce reveals that the theory and the reality are somewhat different when it comes to the accessibility of inline elements like em and strong.

Website Accessibility Begins with Responsive Web Design

I recently asked a friend who happens to be blind if he’d share some sites that were built really well—sites that were beautifully accessible. You know what he said? “I don’t use the web. Everything is broken.”

Everything is broken. And it’s broken because we broke it.

But we can do better.

My favorite design tool. — Ethan Marcotte

“What if someone doesn’t browse the web like I do?”

The State of Fieldset Interoperability - Bocoup

The long-standing difficulties of styling fieldset and legend are finally getting addressed …although I’m a little shocked that the solution involves extending -webkit-appearance. I think that, at this point, we should be trying to get rid of vendor prefixes from the web once and for all, not adding to them. Still, needs must, I suppose.