Tags: html

806

sparkline

Monday, September 20th, 2021

In Quest of Search

On the surface this is about the pros and cons of minting a new HTML search element to replace div role="search" but there’s a deeper point which is that, while ARIA exists to the plug the gaps in HTML, the long-term goal is to have no gaps.

ARIA is not meant to replace HTML. If anything, the need to use ARIA as ‘polyfill’ for HTML semantics could be considered as a sign and a constant reminder of the fact that HTML falls short on some semantics that benefit users of assistive technologies.

Tuesday, September 14th, 2021

Benjamin Parry~ Writing ~ Engineering a better design test ~ @benjaminparry

It sometimes feels like we end up testing the limitations of our tools rather than the content and design itself.

What Benjamin found—and I heartily agree—is that HTML prototypes give you the most bang for your buck:

At the point of preparing for usability testing, it seemed ludicrous to move to any prototyping material other than the one we were already building in. The bedrock of the web: HTML, CSS and Javascript.

Accessibility testing

I was doing some accessibility work with a client a little while back. It was mostly giving their site the once-over, highlighting any issues that we could then discuss. It was an audit of sorts.

While I was doing this I started to realise that not all accessibility issues are created equal. I don’t just mean in their severity. I mean that some issues can—and should—be caught early on, while other issues can only be found later.

Take colour contrast. This is something that should be checked before a line of code is written. When designs are being sketched out and then refined in a graphical editor like Figma, that’s the time to check the ratio between background and foreground colours to make sure there’s enough contrast between them. You can catch this kind of thing later on, but by then it’s likely to come with a higher cost—you might have to literally go back to the drawing board. It’s better to find the issue when you’re at the drawing board the first time.

Then there’s the HTML. Most accessibility issues here can be caught before the site goes live. Usually they’re issues of ommission: form fields that don’t have an explicitly associated label element (using the for and id attributes); images that don’t have alt text; pages that don’t have sensible heading levels or landmark regions like main and nav. None of these are particularly onerous to fix and they come with the biggest bang for your buck. If you’ve got sensible forms, sensible headings, alt text on images, and a solid document structure, you’ve already covered the vast majority of accessibility issues with very little overhead. Some of these checks can also be automated: alt text for images; labels for inputs.

Then there’s interactive stuff. If you only use native HTML elements you’re probably in the clear, but chances are you’ve got some bespoke interactivity on your site: a carousel; a mega dropdown for navigation; a tabbed interface. HTML doesn’t give you any of those out of the box so you’d need to make your own using a combination of HTML, CSS, JavaScript and ARIA. There’s plenty of testing you can do before launching—I always ask myself “What would Heydon do?”—but these components really benefit from being tested by real screen reader users.

So if you commission an accessibility audit, you should hope to get feedback that’s mostly in that third category—interactive widgets.

If you get feedback on document structure and other semantic issues with the HTML, you should fix those issues, sure, but you should also see what you can do to stop those issues going live again in the future. Perhaps you can add some steps in the build process. Or maybe it’s more about making sure the devs are aware of these low-hanging fruit. Or perhaps there’s a framework or content management system that’s stopping you from improving your HTML. Then you need to execute a plan for ditching that software.

If you get feedback about colour contrast issues, just fixing the immediate problem isn’t going to address the underlying issue. There’s a process problem, or perhaps a communication issue. In that case, don’t look for a technical solution. A design system, for example, will not magically fix a workflow issue or route around the problem of designers and developers not talking to each other.

When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.

Wednesday, September 8th, 2021

404PageFound – Active Vintage Websites, Old Webpages, and Web 1.0

Well, this is rather lovely! A collection of websites from the early days of the web that are still online.

All the HTML pages still work today …and they work in your web browser which didn’t even exist when these websites were built.

Monday, August 16th, 2021

Collecting my thoughts about notation and user interfaces (Interconnected)

HTML sits on a boundary between the machine, the creator, and the reader.

Tuesday, July 6th, 2021

CSS Anchored Positioning

An interesting proposal for defining how one element could be “anchored” to another, and how that positioning could be expressed declaratively instead of having to write a whole load of JavaScript. Melanie’s looking for use cases so share ‘em if you have ‘em.

Personally, I’m not convinced that a new element is needed but I’m open to the suggestion.

Tabs in HTML?

I’ve been having some really interesting chats with Brian about tabs, markup, progressive enhancement and accessibility. Here’s a braindump of his current thinking which is well worth perusing.

Thursday, July 1st, 2021

Diana Ashktorab

This is my new favourite indie web site (super performant and responsive too).

Wednesday, June 9th, 2021

Introducing Astro: Ship Less JavaScript

In Astro, you compose your website using UI components from your favorite JavaScript web framework (React, Svelte, Vue, etc). Astro renders your entire site to static HTML during the build. The result is a fully static website with all JavaScript removed from the final page.

YES!

When a component needs some JavaScript, Astro only loads that one component (and any dependencies). The rest of your site continues to exist as static, lightweight HTML.

That’s the way to do it! Make the default what’s best for users (unlike most JavaScript frameworks that prioritise developer convenience at the expense of the end user experience).

This is a tagline I can get behind:

Ship Less JavaScript

Sunday, June 6th, 2021

The right tag for the job: why you should use semantic HTML - localghost

A great introduction to structuring your content well:

Using semantic HTML as building blocks for a website will give you a lovely accessible foundation upon which to add your fancy CSS and whizzy JavaScript.

Sunday, May 16th, 2021

Container Queries in Web Components | Max Böck

The point of this post is to show how nicely container queries can play with web components, but I want to also point out how nice the design of the web component is here: instead of just using an empty custom element, Max uses progressive enhancement to elevate the markup within the custom element.

Tuesday, May 11th, 2021

Design for reading: tips for optimizing content for Reader modes and reading apps

The more I consume content in reading apps, the more I am reminded of the importance and the power of progressive enhancement as a strategy to create resilient and malleable experiences that work for everyone, regardless of how they choose to consume our content.

Top stuff from Sara here!

We have a tendency to always make an assumption about how our readers are reading our content—probably in the browser, with our fancy styles applied to it. But if we make a habit out of thinking about the Web in layers and CSS as an enhancement on top of the content layer, then we can start optimizing and enhancing our users’ reading experiences regardless of their context.

Thinking about the different ways in which users access the Web only shines light on the importance of a progressively enhanced approach to building for the Web. The more we think about the Web in layers and try to improve the experience of one layer before moving to the next, the more resilient experiences we can create. That’s what the essence of progressive enhancement is about.

Monday, May 10th, 2021

Building a resilient frontend using progressive enhancement - Service Manual - GOV.UK

Using progressive enhancement means your users will be able to do what they need to do if any part of the stack fails.

What a terrific short guide to sensible web development!

  • Start with HTML
    • Using interactive elements
    • Adding the extras
    • Building more complex services
    • Testing your service
    • Do not assume users turn off CSS or JavaScript
    • Case studies and related guides

Saturday, April 24th, 2021

CSS Font Lorem Ipsum

Professional web designer on a closed course. Do not attempt.

Monday, April 19th, 2021

My current HTML boilerplate - Manuel Matuzović

This is a great HTML boilerplate, with an explanation of every line.

Tuesday, April 6th, 2021

Open UI and implicit parent/child relationships in HTML – Eric Bailey

I remember discussing this with Tantek years ago:

There are a few elements who need to be placed inside of another specific element in order to function properly.

If I recall, he was considering writing “HTML: The Good Parts”.

Anyway, I can relate to what Eric is saying here about web components. My take is that web components give developers a power that previous only browser makers had. That’s very liberating, but it should come with a commensurate weight of responsibility. I fear that we will see this power wielded without sufficient responsibility.

30 Days of HTML

Receive one email a day for 30 days, each featuring at least one HTML element.

Right up my alley!

Wednesday, March 24th, 2021

Show/Hide password accessibility and password hints tutorial | Part of a Whole

A good tutorial on making password fields accessible when you’ve got the option to show and hide the input.

Wednesday, March 17th, 2021

Good form

I got a text this morning at 9:40am. It was from the National Health Service, NHS. It said:

You are now eligible for your free NHS coronavirus vaccination. Please book online at https://www.nhs.uk/covid-vaccination or by calling 119. You will need to provide your name, date of birth and postcode. Your phone number has been obtained from your GP records.

Well, it looks like I timed turning fifty just right!

I typed that URL in on my laptop. It redirected to a somewhat longer URL. There’s a very clear call-to-action to “Book or manage your coronavirus vaccination.” On that page there’s very clear copy about who qualifies for vaccination. I clicked on the “Book my appointments” button.

From there, it’s a sequence of short forms, clearly labelled. Semantic accessible HTML, some CSS, and nothing more. If your browser doesn’t support JavaScript (or you’ve disabled it for privacy reasons), that won’t make any difference to your experience. This is the design system in action and it’s an absolute pleasure to experience.

I consider myself relatively tech-savvy so I’m probably not the best judge of the complexity of the booking system, but it certainly seemed to be as simple as possible (but no simpler). It feels like the principle of least power in action.

SMS to HTML (with a URL as the connective tissue between the two). And if those technologies aren’t available, there’s still a telephone number, and finally, a letter by post.

This experience reminded me of where the web really excels. It felt a bit like the web-driven outdoor dining I enjoyed last summer:

Telling people “You have to go to this website” …that seems reasonable. But telling people “You have to download this app” …that’s too much friction.

A native app would’ve been complete overkill. That may sound obvious, but it’s surprising how often the overkill option is the default.

Give me a URL—either by SMS or QR code or written down—and make sure that when I arrive at that URL, the barrier to entry is as low as possible.

Maybe I’ll never need to visit that URL again. In the case of the NHS, I hope I won’t need to visit again. I just need to get in, accomplish my task, and get out again. This is where the World Wide Web shines.

In five days time, I will get my first vaccine jab. I’m very thankful. Thank you to the NHS. Thank you to everyone who helped build the booking process. It’s beautiful.

Good, Better, Best: Untangling The Complex World Of Accessible Patterns — Smashing Magazine

I really like the approach that Carie takes here. Instead of pointing to specific patterns to use, she provides a framework for evaluating technology. Solutions come and go but this kind of critical thinking is a long-lasting skill.