Posts tagged “html”

A repository of styled and “styled” form control elements and markup patterns, and how they are announced by screen readers.

Adrian Roselli:

What we know is that native and custom calendar controls are often a problem for users and applied where they are not needed. Before dropping the code on a screen as a matter of habit, consider if it genuinely helps the user or just your workflow.

Andy Bell:

One thing that is often forgotten about accessibility is that keeping things simple and utilising semantic HTML gets you most of the way towards providing a fully accessible experience for everyone.

Brad Frost:

I was just talking with Dave about the accessibility of moving images on the web, and he said:

hm… I wonder if you could use picture + prefers-reduced-motion?

He then sends the following code:

<picture>
  <source srcset="no-motion.jpg" media="(prefers-reduced-motion: reduce)"></source> 
  <img srcset="animated.gif alt="brick wall"/>
</picture>

Whoa! This is a revelation.

Adrian Roselli:

Once major browsers started supporting <details> & <summary> developers immediately started to play with them to see what sorts of patterns they could enhance or replace. This is a good thing. Experimentation pushes boundaries, improves understanding.

However, we need to be careful of christening this new-to-us interaction as the solution to all our coding struggles.

Dave Rupert thinks version number bumps would be a good move for HTML and CSS, marketing-wise. I agree!

A single number bump replaces a mountain of marketing. Every discerning technologist knows it only makes sense to invest in technologies that are moving forward. To invest in a stagnant technology would be a dereliction of duty.

I think this has effected web technologies deeply. HTML5 was released in 2008 and its handful of new elements and APIs was a boom for the language. Even Steve Jobs advocated for it over Flash. Web Standards had won, Firefox and Webkit were our champions. “We need to upgrade to HTML5” was a blanket excuse for auditing your website and cleaning up your codebase.

Tyler Sticka:

When everyone finished translating articles to semantic, accessible HTML, I let them in on a secret: This was still design. While we hadn’t yet incorporated color, typography or composition, we had made decisions about prioritization, hierarchy, information architecture and user experience. And those decisions would be the most resilient… accessible to virtually any visitor, not just those blessed few with perfect vision, hearing and mobility. The web was the only medium that offered designers the chance to craft one work for such a varied landscape with so few gatekeepers.

A deep dive into figure accessibility from Scott O’Hara:

A figcaption is meant to provide a caption or summary to a figure, relating it back to the document the figure is contained within, or conveying additional information that may not be directly apparent from reviewing the figure itself.

If an image is given an empty alt, then the figcaption is in effect describing nothing. And that doesn’t make much sense, does it?

Many people I meet think title texts, also known as tooltips, improve both the accessibility and usability of their sites. They don’t. In fact, they can even cause problems.

Max Böck:

Text-only sites like these are usually treated as a MVP of sorts. A slimmed-down version of the real site, specifically for emergencies.

I’d argue though that in some aspects, they are actually better than the original.

This is the web as it was originally designed. Pure information, with zero overhead. Beautiful in a way.

Jeremy Keith:

I really like this design pattern. Cover 80% of the use cases with a declarative solution in HTML, but also provide an imperative alternative in JavaScript that gives more power. HTML5 has plenty of examples of this pattern. But I feel like the history of web standards has a few missed opportunities too.

In recent years there’s been a push to expose low-level browser features to developers. They’re inevitably exposed as JavaScript APIs. In most cases, that makes total sense. I can’t really imagine a declarative way of accessing the fetch or cache APIs, for example. But I think we should be careful that it doesn’t become the only way of exposing new browser features. I think that, wherever possible, the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for the simple use cases, and power for the more complex use cases.