I really like the progressive enhancement approach that this little library uses—it’s basically the Hijax approach I was talking about back in the days of Bulletproof Ajax but all wrapped up into a neat package that you can use entirely via HTML attributes.
Did you know there’s an imagesrcset attribute you can put on link rel="preload" as="image" (along with an imagesizes attribute)?
I didn’t. (Until Amber pointed this out.)
A handy reminder from Léonie (though remember that the best solution is to avoid the problem in the first place—if you avoid using ARIA, do that).
A really great one-page guide to HTML from Bruce. I like his performance-focused intro:
If your site is based on good HTML, it will load fast. Browsers incrementally render HTML—that is, they will display a partially downloaded web page to the user while the browser awaits the remaining files from the server.
Modern fashionable development techniques, such as React, require a lot of JavaScript to be sent to the user. When it’s all downloaded, the user’s device must parse and execute the JavaScript before it can even start to construct the page. On a slow network, or on a cheaper, low-powered device, this can result in an excruciatingly slow load and is a heavy drain on the battery.
Smart thinking from Sara to improve usability for keyboard users by using aria-hidden="true" tabindex="-1" to skip duplicate links:
A good rule of thumb for similar cases is that if you have multiple consecutive links to the same page, there is probably a chance to improve keyboard navigation by skipping some of those links to reduce the number of tab stops to one. The less tab stops, the better, as long as it does not worsen or compromise on other aspects of usability.
I’ve cautiously implemented this pattern now over on The Session where snippets of comments had both a title link and a “more” link going to the same destination.
Chris has put together one of his indispensable deep dives, this time into responsive images. I can see myself referring back to this when I need to be reminded of the syntax of srcset and sizes.
Here’s one simple, practical way to make apps perform better on mobile devices: always configure HTML input fields with the correct
type,inputmode, andautocompleteattributes. While these three attributes are often discussed in isolation, they make the most sense in the context of mobile user experience when you think of them as a team.
This is an excellent deep dive with great advice:
You may think that you are familiar with the basic
autocompleteoptions, such as those that help the user fill in credit card numbers or address form fields, but I’d urge you to review them to make sure that you are aware of all of the options. The spec lists over 50 values!
A nice succint explanation of using the srcset and sizes attributes on the img element—remember, you probably don’t need picture and source elements if your use case is swapping out different sized versions of the same image.
One caveat thought: you do need to know the dimensions of the images. If you’re dealing with unknown or user-generated photos, that can be an issue.
This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.
I have to admit, I don’t think I even knew of the existence of the playsinline attribute on the video element. Here, Chris runs through all the attributes you can put in there.
Some solid research here. Turns out that using input type=”text” inputmode=”numeric” pattern="[0-9]*" is probably a better bet than using input type="number".
Chris takes two side-by-side deep dives; one into the a element, the other into the button element.
Even if you think you already know those elements well, I bet there’ll be something new here for you. Like, did you know that the button element can have form over-riding attributes like formaction, formenctype, formmethod, formnovalidate, and formtarget?
A great explanation of aria-label and aria-labelledby!
The many ways of improving a single form field in HTML.
I love these kinds of deep dives into markup!
Google’s pissing over HTML again, but for once, it’s not by making up rel values:
A new way to help limit which part of a page is eligible to be shown as a snippet is the “
data-nosnippet” HTML attribute onspan,div, andsectionelements.
This is a direct contradiction of how data-* attributes are intended to be used:
…these attributes are intended for use by the site’s own scripts, and are not a generic extension mechanism for publicly-usable metadata.
A very useful explanation of the ARIA attributes relating to state:
aria-expanded,hidden,aria-hidden, andaria-current.A good look at the (over)use of the aria-label attribute that confirms the first rule of ARIA.
I encourage you to think about and make sure you are using the right elements at the right time. Sometimes I overthink this, but that’s because it’s that important to me - I want to make sure that the markup I use helps people understand the content, and doesn’t hinder them.
Léonie makes a really good point here: if you’re adding aria attributes to indicate interactions you’re making available through JavaScript, then make sure you also use JavaScript to add those aria attributes.
When to use aria-hidden="true", and when you might need display: none:
aria-hiddenby itself is not enough to completely hide an element from all users, if that is the end goal.
When to use role="presentation" (or role="none"):
Where
aria-hiddencan be used to completely hide content from assistive technology, modifying an element’sroleto “none” or “presentation” removes the semantics of the element, but does not hide the content from assistive technologies.