Why, How, and When to Use Semantic HTML and ARIA

Semantic HTML and Accessible Rich Internet Applications (ARIA) help create interfaces that work for everyone in the most performant, robust, and simple way possible. They add essential meaning to your content, which lets web browsers, search engines, screen readers, RSS readers, and ultimately users understand it.

And yet, many people still don’t use them. I wanted to know why, so I set up a Twitter poll. The most common reason people gave was a lack of awareness and understanding of the benefits of using semantic HTML and ARIA.

Let’s look over the benefits of using HTML and ARIA, why starting with semantic HTML is the way to go, and why ARIA ought to come in as a last resort.

Starting with raw text

The <body> element of an HTML document contains the main content a user sees on a page. If content is put inside the body without any additional elements, the browser has no way of differentiating between different types of content, like paragraphs and headings.

<body>
A Study of Butterflies

Butterflies are little bugs with cute wings.

Butterfly Habitats

Butterflies live in flower houses and hang out at dank coffeeshops.
</body>

If the browser can’t differentiate between pieces of content, then it can’t present that content to the user in a meaningful way. That means:

  • We can’t style the headings differently from paragraphs.
  • It’s harder for search engines to interpret the content, meaning it’s likely to rank poorly and be difficult for users to find.
  • Screen readers and other assistive technology can’t communicate it properly to the user.

Not to mention, it’s more than a bit awkward visually:

A screenshot of the HTML rendered on the front end, which displays as a single line of text.

Adding some structure with HTML

To provide some structure we could wrap the lines of text here in divs like this:

<div>A Study of Butterflies.</div>
<div>Butterflies are little bugs with cute wings.</div>
<div>Butterfly Habitats</div>
<div>Butterflies live in flower houses and hang out at dank coffeeshops.</div>

This is slightly better because each piece of content is displayed in the browser on its own line instead of one long unbroken line …

The Place of UX

Every time “UX” comes out of my mouth or is typed by my fingers, I think, “did I just use that term correctly?” It feels like such a big and loaded term these days, that perhaps the way I use it only contributes to the confusion. Ryan Singer frames that problem well:

Debates continue to rage about the role of UX designers, user research, and how far knowledge about the user should permeate the organization. On one extreme, UX is seen as a specialized pocket of knowledge that informs the definition of projects and sets requirements. On the other, UX is something for which the entire organization should somehow feel responsible.

It can feel so big, like UX is literally the only thing that matters in an entire project. It can also feel so small, like 2px of extra padding on a specific dropdown will make the options easier to tap.

Direct Link to ArticlePermalink

The post The Place of UX appeared first on CSS-Tricks.

from CSS-Tricks https://m.signalvnoise.com/the-place-of-ux/…

A CSS Golfing Exercise

Code golfing is a type of programming where the goal is to accomplish a task using as few bytes as possible. CSSBattle is a code golfing battleground where players complete to recreate target images using CSS and HTML.

The rules are fairly simple:

  • No external resources (sorry, no <img src="the-solution.png">)
  • Your solution must render correctly in Chrome (just for scoring purposes)

This can be a pretty fun departure from day-to-day front-end work. There’s no need to worry about maintainability, semantics, performance, accessibility, or anything other than making a thing really, really small and still render correctly.

A golf solution in 12 attempts

This type of thinking is a pretty dramatic departure from how most of us are writing front-end code for production sites (I hope!), so I’ve been posting all of my solutions on GitHubhttps://github.com/alexzaworski/cssbattle-solutions) in an effort to both share some knowledge and learn from others. As a fortunate side effect, it also means there’s a fairly detailed history of my submissions.

Here’s a start-to-finish account of my attempts CSSBattle’s 7th target, which looks like this:

CSSBattle Target #7 — Leafy Trail

The “just center the dang thing” method

A reasonable first approach is to simply stick an element in the middle of the page, slap a box shadow and a border radius on it, and call it done. If we were writing this “for real,” it might look like this:

<!DOCTYPE html>
<html>
  <head>
    <style>
      body {
        background: #0B2429;
        margin: 0;
      }

      .leaf {
        width: 150px;
        height: 150px;
        border-radius: 67% 0;
        background: #F3AC3C;
        margin: 75px 0 75px 175px;
        box-shadow:
          -50px 0 #998235, 
          -100px 0 #1A4341
      }
    </style>
  </head>
  <body>
    <div class="leaf"/>
  </body>
</html>

But that’s 423 bytes! That won’t do for CSS golf, so let’s see what we can remove.

Attempt 1: 144 bytes

<p style="margin:75 167;height:150;width:150;border-radius:67%0;box-shadow:-50px 0#998235,-100px 0#1A4341,0 0 0 5in #0B2429;background:#F3AC3C">

Here’s a golfed version. There’s definitely some weirdness going on here — no <!DOCTYPE>, no <html>, no <body>, no nothin’. The browser doesn’t need them (and, in fact, inserts …

A Conspiracy to Kill IE6

Chris Zacharias published a few notes about why the team at YouTube added a banner that asked users to switch from IE6 to a more modern browser back in 2009:

The bittersweet consequence of YouTube’s incredible growth is that so many stories will be lost underneath all of the layers of new paint. This is why I wanted to tell the story of how, ten years ago, a small team of web developers conspired to kill IE6 from inside YouTube and got away with it.

I do not recall the exact triggering event that led to our web development team laying out plans to kill IE6 over lunch in the YouTube cafeteria. Perhaps it was the time I pushed out a CSS stylesheet that included an attribute selector on a semi-supported HTML element. Any reasonable web developer would expect this to be ignored by browsers not up to the task. This was not the case with older flavors of IE. Under very specific conditions, an attribute selector on an unsupported HTML element in IE would create an internal recursion that would at best, cause the browser to crash and at worst, trigger a blue screen of death.

There are a lot of interesting things to consider here. IE6 was notoriously difficult for developers to work with and would cause teams to spend a great deal of time fixing game-breaking bugs for what often represented a mere slither of their overall site traffic. However, it’s important to note that as soon as you make a call like this, where do you stop? It suddenly becomes easier to make a Chrome-only website, to ignore basic accessibility principles, to ignore semantic markup, and to make a website optimized for yourself. That leads us to more sticky topics, such as browser diversity and proprietary resources that seem at odds with an open, inclusive web.

I’m reminded here of Jeremy Keith’s book, Resilient Web Design, where he writes:

If a website is built using progressive enhancement then it’s okay if a particular

Making the Move from jQuery to Vue

As someone who has used jQuery for many. years and has recently become a Vue convert, I thought it would be an interesting topic to discuss the migration process of working with one to the other.

Before I begin though, I want to ensure one thing is crystal clear. I am not, in any way whatsoever, telling anyone to stop using jQuery. That’s been pretty fashionable lately, and heck, I wrote up something similar myself a few year ago (“How I’m (Not) Using jQuery”). If you get things done with jQuery and your end users are successfully using your site, then more power to you. Keep using what works for you.

This guide is more for people who may be coming from years of jQuery experience and want to see how things can be done with Vue. With that in mind, I’m going to focus on what I consider “core” jQuery use cases. I won’t cover every single possible feature but instead take a “I often did [X] with jQuery” approach that may be more relatable to people considering learning Vue. (As an aside, also note that how I write my examples are simply one way of performing a task. Both jQuery and Vue give provide multiple ways to accomplish the same goal and that’s a great thing!)

With that in mind, let’s consider some high level things we might turn to jQuery for:

  • Finding something in the DOM (with the idea of doing something with it later)
  • Changing something in the DOM (e.g. the text of a paragraph or the class of a button)
  • Reading and setting form values
  • Form validation (which is really just a combination of the items above)
  • Ajax calls and handling the results
  • Event handling (e.g. on button click, do something)
  • Measuring or changing the styles of an element

There’s more to jQuery, of course, but these uses (at least in my opinion), cover the most common use cases. Also note there’s a lot of cross pollination in the list above. So, …

Currently Reading: Progressive Web Apps by Jason Grisby

I’ve been reading Jason Grigsby’s new book on progressive web apps this past week and it’s exciting. Jason explains what PWAs are and how they work while while doing a bang-up job covering the business case for using them them, too. But perhaps you might be thinking that a PWA isn’t necessary for the project you’re working on right now. Well, Jason argues that progressive web apps are for everybody:

Should your website be a progressive web app? The answer is almost certainly yes. Even if you don’t think of your website as an “app,” the core features of progressive web apps can benefit any website. Who wouldn’t profit from a fast, secure, and reliable website?

One of the challenges I’ve experienced when thinking about how to apply a progressive web app to a project I’m working on is figuring out what content to cache. Should the homepage be cached? Do we make a custom offline page? What is useful information to provide a user in that context?

Jason goes there, too, and even describes how he tackles that for his own projects:

For cloudfour.com, we chose to only cache recently viewed pages because the main reason people come to our site is to read the articles. If we tried to anticipate which articles someone would want offline access to, we’d likely guess incorrectly. If we precached top-level pages, we might force people on a metered network connection to download content they would never look at…

That makes a ton of sense to me and I realize that the offline cache should probably be different depending on the situation and the website. For example, maybe a design agency website could replace the big flashy homepage with an offline page that only shows the phone number of the agency instead. Or perhaps a restaurant website could cache the food menu and make that experience offline, but remove all the images to make sure it’s not too impactful for folks on those metered networks.

Anyway, I think that Jason’s book …

Split

Jeremy on the divide between the core languages of the web, and all the tooling that exists to produce code in those languages:

On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with.

On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript: pre-processors, post-processors, transpilers, bundlers, and other build tools.

Jeremy likes the raw materials side the best, but acknowledges a healthy balance of both worlds is a healthy mix.

I think a great front-end developer is hyper-aware of this split. Every choice we make is a trade-off between developer productivity and complexity management and the user’s experience. The trick is to punish the user as little as possible while giving yourself as much as you can.

Direct Link to ArticlePermalink

The post Split appeared first on CSS-Tricks.

from CSS-Tricks https://adactio.com/journal/15050…

Making Web Components for Different Contexts

This article isn’t about how to build web components. Caleb Williams already wrote a comprehensive guide about that recently. Let’s talk about how to work with them, what to consider when making them, and how to embrace them in your projects.

If you are new to web components, Caleb’s guide is a great read, but here are more resources that will get you up to speed:

Since web components are now widely supported (thanks to the hard work of many people behind the scenes) — and considering the imminent switch that Edge will make to the chromium platform — people are now thinking about web components as “native” and a platform-compliant way to build reusable UI components to keep consistency across design systems and web projects, while using the power of the Shadow DOM to encapsulate style and logics inside the component itself.

Well, this can be true and false at the same time. But first, let’s get acquainted with the Abstraction Layers Triangle.

The Abstraction Layers Triangle

Technically, we should consider web components as an extension of our favorite markup language, HTML (yep!). The Web Components API allows us to create custom HTML elements (e.g. <foo-bar>) that don’t exist in HTML.

We are told web components are basically new HTML elements, so we should consider them as part of the HTML specifications and, consequently, we should follow its paradigms, core concepts, and utilization. If we assume all of these points, we will figure out that our components will live among the lowest levels of the web platform stack, alongside HTML, CSS, and JavaScript.

Frameworks and libraries like React, Vue, Angular, SvelteJS work on their abstraction level, right above other tools that live in a sort of “middle earth,” like StencilJs, Hybrids and Lit. Under these layers of abstraction, we can find our basic web technologies… and vanilla web components. We can represent this concept …

Easily Turn Your Photos into Vectors with Photo Vectorizer

(This is a sponsored post.)

Photo Vectorizer is a simple-to-use Photoshop action that can convert any photo into a vector. With just a few clicks of your mouse, you can save tons of time and frustration by turning your photos into vectors. With super sharp results, these vectors are great for any project either online or in print.

Highlights:

  • Turn your photos into professional looking vectors.
  • Easy to use — just a few clicks.
  • Save tons of time.
  • Sharp, clean results.
  • Great for backgrounds, spot illustrations and presentations as well as printed projects like T- shirts, mugs, totes and more.

Visit Site

Direct Link to ArticlePermalink

The post Easily Turn Your Photos into Vectors with Photo Vectorizer appeared first on CSS-Tricks.

from CSS-Tricks https://synd.co/2ISy7YW…

Naming things to improve accessibility

I like the this wrap-up statement from Hidde de Vries:

In modern browsers, our markup becomes an accessibility tree that ultimately informs what our interface looks like to assistive technologies. It doesn’t matter as much whether you’ve written this markup:

  • in a .html file
  • in Twig, Handlebars or Nunjucks
  • as the <template> in a Vue Single File Component
  • exported in the JSX of your React component
  • outputted by a weird legacy CMS

It is which markup that determines if your site is pleasurable to experience for AT users. In short: it’s the markup that matters

As a front-end developer, you’ll find yourself writing markup in lots of different places with lots of different technologies. I think it behooves you think of how best to write it regardless of where and how.

Direct Link to ArticlePermalink

The post Naming things to improve accessibility appeared first on CSS-Tricks.

from CSS-Tricks https://hiddedevries.nl/en/blog/2019-04-18-naming-things-to-improve-accessibility?utm_source=CSS-Weekly&utm_campaign=Issue-360&utm_medium=email…