Tags: accessibility

349

sparkline

Wednesday, March 13th, 2019

The web we broke. — Ethan Marcotte

Like Eric, Ethan is feeling rightly glum about the state of accessibility on the web. But…

Right now, I’m trying to focus on this one question:

What’s one thing I wish I understood better about accessibility?

Accessibility Insights

A handy accessibility tool. The browser plug-in is only for Chrome right now (I use Firefox as my main browser) but it’s pretty nifty—the tool for visualising tabbing is really useful.

Fighting uphill | Eric Bailey

Eric is down about the current dismal state of accessibility on the web. Understandably so. It’s particularly worrying that the problem might be embedded into hiring practices:

Overwhelmingly, crushingly, we shove new developers towards learning JavaScript single page application frameworks (SPAs). While many of these frameworks pay lip service towards preserving accessibility, if you do your homework you find that the majority of them were built without assistive technology in mind.

But it’s not all doom and gloom. Eric also points to initiatives that could really help.

Still, this is a tough question to ask out loud:

What if we’re losing?

Monday, February 25th, 2019

Accessibility on The Session

I spent some time this weekend working on an accessibility issue over on The Session. Someone using VoiceOver on iOS was having a hard time with some multi-step forms.

These forms have been enhanced with some Ajax to add some motion design: instead of refreshing the whole page, the next form is grabbed from the server while the previous one swooshes off the screen.

You can see similar functionality—without the animation—wherever there’s pagination on the site.

The pagination is using Ajax to enhance regular prev/next links—here’s the code.

The multi-step forms are using Ajax to enhance regular form submissions—here’s the code for that.

Both of those are using a wrapper I wrote for XMLHttpRequest.

That wrapper also adds some ARIA attributes. The region of the page that will be updated gets an aria-live value of polite. Then, whenever new content is being injected, the same region gets an aria-busy value of true. Once the update is done, the aria-busy value gets changed back to false.

That all seems to work fine, but I was also giving the same region of the page an aria-atomic value of true. My thinking was that, because the whole region was going to be updated with new content from the server, it was safe to treat it as one self-contained unit. But it looks like this is what was causing the problem, especially when I was also adding and removing class values on the region in order to trigger animations. VoiceOver seemed to be getting a bit confused and overly verbose.

I’ve removed the aria-atomic attribute now. True to its name, I’m guessing it’s better suited to small areas of a document rather than big chunks. (If anyone has a good primer on when to use and when to avoid aria-atomic, I’m all ears).

I was glad I was able to find a fix—hopefully one that doesn’t negatively impact the experience in other screen readers. As is so often the case, the issue was with me trying to be too clever with ARIA, and the solution was to ease up on adding so many ARIA attributes.

It also led to a nice discussion with some of the screen-reader users on The Session.

For me, all of this really highlights the beauty of the web, when everyone is able to contribute to a community like The Session, regardless of what kind of software they may be using. In the tunes section, that’s really helped by the use of ABC notation, as I wrote five years ago:

One of those screen-reader users got in touch with me shortly after joining to ask me to explain what ABC was all about. I pointed them at some explanatory links. Once the format “clicked” with them, they got quite enthused. They pointed out that if the sheet music were only available as an image, it would mean very little to them. But by providing the ABC notation alongside the sheet music, they could read the music note-for-note.

That’s when it struck me that ABC notation is effectively alt text for sheet music!

Then, for those of use who can read sheet music, the text of the ABC notation is automatically turned into an SVG image using the brilliant abcjs. It’s like an enhancement that’s applied, I dunno, what’s the word …progressively.

Monday, February 11th, 2019

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.

Tuesday, February 5th, 2019

Revisiting the abbr element

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

Friday, February 1st, 2019

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.

Sunday, January 27th, 2019

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.

Friday, January 11th, 2019

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.

Wednesday, January 9th, 2019

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.

Tuesday, January 1st, 2019

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?

Saturday, December 29th, 2018

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.

Wednesday, December 19th, 2018

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.

Saturday, December 15th, 2018

Using aria-live

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

Thursday, December 6th, 2018

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.

Monday, November 26th, 2018

Prototypes and production

When we do front-end development at Clearleft, we’re usually delivering production code, often in the form of a component library. That means our priorities are performance, accessibility, robustness, and other markers of quality when it comes to web development.

But every so often, we use the materials of front-end development—HTML, CSS, and JavaScript—to produce something that isn’t intended for production. I’m talking about prototyping.

There are plenty of non-code prototyping tools out there, and our designers often reach for them to communicate subtleties like motion design. But when it comes to testing a prototype with real users, it’s hard to beat the flexibility of HTML, CSS, and JavaScript. Load it up in a browser and away you go.

We do a lot of design sprints, where time is of the essence. The prototype we produce on the penultimate day of the sprint definitely won’t be production quality, but it will be good enough to test.

What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes.

So these two kinds of work require very different attitudes. For production work, quality is key. For prototyping, making something quickly is what matters.

Whereas I would think long and hard about the performance impacts of third-party libraries and frameworks on a public project, I won’t give it a second thought when it comes to a prototype. Throw all the JavaScript frameworks and CSS libraries you want at it (although I would argue that in-browser technologies like CSS Grid have made CSS libraries like Bootstrap less necessary, even for prototyping).

Alternating between production projects and prototyping projects can be quite fun, if a little disorienting. It’s almost like I have to flip a switch in my brain to change tracks.

When a prototype is successful, works great, and tests well, there’s a real temptation to use the prototype code as the basis for the final product. Don’t do this! I’ve made that mistake in the past and it always ends badly. I ended up spending far more time trying to wrangle prototype code to a production level than if I had just started from a clean slate.

Build prototypes to test ideas, designs, interactions, and interfaces …and then throw the code away. The value of a prototype is in answering questions and testing hypotheses. Don’t fall for the sunk cost fallacy when it’s time to switch over into production mode.

Of course it should go without saying that you should never, ever release prototype code into production.

And yet…

More and more live sites seem to be built with a prototyping mindset. Weighty JavaScript frameworks are used regardless of appropriateness. Accessibility, if it’s even considered at all, is relegated to an afterthought. Fragile architectures are employed that rely on first loading and then executing JavaScript in order to render basic content. Developer experience is prioritised over user experience.

Heydon recently highlighted an article that offered this tip for aspiring web developers:

As for HTML, there’s not much to learn right away and you can kind of learn as you go, but before making your first templates, know the difference between in-line elements like span and how they differ from block ones like div.

That’s perfectly reasonable advice …if you’re building a prototype. But if you’re building something for public consumption, you have a duty of care to the end users.

Monday, November 12th, 2018

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.

Thursday, November 8th, 2018

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.