Link tags: readers

57

sparkline

Back to the Future with RSS

Nicky Case on RSS:

Imagine an open version of Twitter or Facebook News Feed, with no psy-op ads, owned by no oligopoly, manipulated by no algorithm, and all under your full control.

Imagine a version of the newsletter where you don’t have to worry about them selling your email to scammers, labyrinth-like unsubscribe pages, or stuffing your inbox with ever more crap.

Skipping skip links ⚒ Nerd

Vasilis offers some research that counters this proposal.

It makes much more sense to start each page with the content people expect on that page. Right? And if you really need navigation (which is terribly overrated if you ask me) you can add it in the footer. Which is the correct place for metadata anyway.

That’s what I’ve done on The Session.

Why I Still Use RSS | atthislink

Having only the content I want to see only be shown when I want to see it with the freedom to jump between readers as I please, all with no ads? For me, no other service comes close to the flexibility, robustness, and overall ease-of-use that RSS offers.

HTML test cases

This is handy—an up-to-date list of tests run on form fields with different combinations of screen readers and browsers.

The Importance of HTML – Jerry Jones

You’re not going to get a Webby Award or thousands of views on Codepen for how amazingly crafted your HTML is. You’ll need to be OK going unrecognized for your work. But know that every time I use a screen reader or keyboard on a site and it works correctly, I have a little spark of joy.

An opinionated guide to accessibility testing /// Iain Bean

  1. First impressions
  2. The Tab key
  3. Automated testing tools
  4. Screen reader testing
  5. Next steps

Not so short note on aria-label usage – Big Table Edition – HTML Accessibility

This is a very handy table of elements from Steve of where aria-label can be applied.

Like, for example, not on a div element.

Accessibility Support

A very handy community project that documents support for ARIA and native HTML accessibility features in screen readers and browsers.

How-to: Create accessible forms - The A11Y Project

Another five pieces of sweet, sweet low-hanging fruit:

  • Always label your inputs.
  • Highlight input element on focus.
  • Break long forms into smaller sections.
  • Provide error messages.
  • Avoid horizontal layout forms unless necessary.

5 most annoying website features I face as a blind person every single day by Holly Tuke

Five pieces of low-hanging fruit:

  • Unlabelled links and buttons
  • No image descriptions
  • Poor use of headings
  • Inaccessible web forms
  • Auto-playing audio and video

About Feeds | Getting Started guide to web feeds/RSS

Matt made this website to explain RSS to people who are as-ye unfamilar with it.

Introduction to Screen Readers Using Voiceover | Gymnasium

This is a great short introduction to using VoiceOver with Safari by the one and only Ethan Marcotte.

What’s in a name? | Sarah Higley

This is a terrific explanation of the concept of accessible names in HTML, written with verve and style!

Contrary to what you may think, naming an element involves neither a birth certificate nor the HTML name attribute. The name attribute is never directly exposed to the user, and is used only when submitting forms. Birth certificates have thus far been ignored by spec authors as a potential method for naming controls, but perhaps when web UI becomes sentient and self-propagating, we’ll need to revisit that.

CSS Can Influence Screenreaders | Ben Myers

This surprises me. But forewarned is forearmed.

Laura Kalbag – How to read RSS in 2020

RSS: now more than ever!

You get to choose what you subscribe to in your feed reader, and the order in which the posts show up. You might prefer to read the oldest posts first, or the newest. You might group your feeds by topic or another priority. You are not subjected to the “algorithmic feed” of Facebook, Twitter, Instagram, YouTube, where they choose the order for you.

HTML: The Inaccessible Parts - daverupert.com

Well, this is a grim collection from Dave:

There are some cases where even using plain ol’ HTML causes accessibility problems. I get frustrated and want to quit web development whenever I read about these types of issues. Because if browsers can’t get this right, what hope is there for the rest of us.

It’s worth clicking through each link he lists—the situation is often much more nuanced than simply “Don’t use X.”

Standards for Writing Accessibly – A List Apart

  • Write Chronologically, Not Spatially
  • Write Left to Right, Top to Bottom
  • Don’t Use Colors and Icons Alone
  • Describe the Action, Not the Behavior

What I’ve learned about accessibility in SPAs

Nolan writes up what he learned making accessibiity improvements to a single page app. The two big takeways involve letting the browser do the work for you:

Here’s the best piece of accessibility advice for newbies: if something is a button, make it a <button>. If something is an input, make it an <input>. Don’t try to reinvent everything from scratch using <div>s and <span>s.

And then there are all the issues that crop up when you take over the task of handling navigations:

  • You need to manage focus yourself.
  • You need to manage scroll position yourself.

For classic server-rendered pages, most browser engines give you this functionality for free. You don’t have to code anything. But in an SPA, since you’re overriding the normal navigation behavior, you have to handle the focus yourself.

Amphora. — Ethan Marcotte

There’s no sugar-coating it—AMP components are dreadfully inaccessible:

We’ve reached a point where AMP may “solve” the web’s performance issues by supercharging the web’s accessibility problem, excluding even more people from accessing the content they deserve.