The Best Of The Internets

Web Developer Representation in W3C

One thing I’ve always felt was missing from the W3C process was input from real web designers and developers. Sure, a handful of us have been tapped to join specific workign groups as “invited experts,” but they have been few and far between. And few designers and developers have the piles of cash laying about that are required to join the W3C.

Over the years, I’d hoped to see an organization like the World Organization of Webmasters or the Web Standards Project—both of which I helped steer in some capacity­ at varying times—would step up an fill this suprising gap, but alas that never happened. And so I am so thankful to see the Fronteers folks (a web design community in the Netherlands) considering formally joining the W3C to fill this role. And I’m even more excited that Rachel Andrew is their first choice to act on our behalf.

I’m hopeful the Fronteers community will vote in favor of this so we can get a few of our own advocates on key committees.


Much Ado About ARIA

I’m always learning new things about ARIA and in this article I learned about some ways to ensure that radio controls marked up in legend and fieldset are actually exposed as a radio group. Now to figure out a way to get automatic role assignment…

Related: The state of fieldset interoperability


The state of fieldset interoperability

I’m a huge fan of fieldset and legend from a semantic standpoint and agree that getting better cross-browser alignment (and better assistive tech support) is key to their usefulness. I’m glad this work is being done.



Chrome’s NOSCRIPT Intervention

You can always count on Tim Kadlec to deep dive into the implications of new performance features and Chrome’s decision to remove block JavaScript in certain scenarios is no exception.

Long story short, the NOSCRIPT intervention looks like a really great feature for users. More often than not it provides significant reduction in data usage, not to mention the reduction in CPU time—no small thing for the many, many people running affordable, low-powered devices.



Removing jQuery from GitHub.com frontend

There’s so much great stuff in here. Of particular note:

As part of our refined approach to building frontend features on GitHub.com, we focused on getting away with regular HTML foundation as much as we could, and only adding JavaScript behaviors as progressive enhancement. As a result, even those web forms and other UI elements that were enhanced using JS would usually also work with JavaScript disabled in the browser. In some cases, we were able to delete certain legacy behaviors altogether instead of having to rewrite them in vanilla JS.

If you need to brush up on what progressive enhancement is and how to do it with aplomb, consider picking up a copy of my book, Adaptive Web Design.


The “Developer Experience” Bait-and-Switch

This piece is worth a thorough read. Then a re-read. It’s that important.

[W]e need to confront the “developer experience” bait-and-switch. Tools that cost the poorest users to pay wealthy developers are bunk. To do better, we need to move the conversation to an evidence-based footing. I wish the arguments folks made against my positions were data-driven. There’s so much opening! Perhaps a firm is doing market analysis and only cares about ever reaching users who make more than $100K USD/yr or who are in enterprise settings. Perhaps research will demonstrate that interactivity isn’t as valuable as getting bits on screen (the usual SSR argument). Or, more likely, that acknowledgement (bits on screen) buys a larger-than-anticipated amount of perceptual padding (perhaps due to scanning). Perhaps the global network landscape is shifting so dramatically that the budget for client-side JS runtime has increased. Perhaps the median CPU improvement that doesn’t look set to materialize until 2021 at the earliest will happen much earlier; i.e., maybe the current baseline is wrong!

But we aren’t having that conversation. And we aren’t going to have it until we identify, call-out, and end the “developer experience” bait-and-switch.

Further reading from this site:



Describing aria-describedby

This super-thorough examination of aria-describedby is well worth a read.

aria-describedby is an important tool to help provide information where it might otherwise be missed. However, the attribute should rarely be the sole manner in which information is communicated, as doing so will exclude people not using screen readers from the descriptive content. The best way to use aria-describedby is as an alternate way to provide quick access to descriptions that are accessible by other means.