DEV Community: am i angie?

A Quick and Dirty Intro to Web Accessibility

am i angie? — Wed, 27 Nov 2024 09:45:43 +0000

Accessibility is the inclusive practice of designing and coding websites to be usable by everybody. It helps to achieve the fundamental goal of the Web: to work for all people, whatever their hardware, software, language, location, or ability. Accessibility is often neglected, but it is a basic and fundamental part of work for anyone striving for technical excellence. If the mission doesn't inspire you, consider this: web accessibility is also required by law in many countries and situations, and there is a very real possibility that your client will get sued if their website is not accessible.

International standards for web accessibility are developed by the World Wide Web Consortium (better known as W3C). An example of such a standard is Web Content Accessibility Guidelines (WCAG) that is developed by Web Accessibility Initiative (WAI) (where you can participate too!). Every once in a while WCAG is updated to reflect the latest changes in technologies and our understanding of accessibility needs.

According to WCAG, web accessibility can be broken down into four main principles, commonly abbreviated as POUR. Any user interface component or a piece of information on the website must be perceivable (adjusted to different ways users can see or hear your page), operable (usable with devices other than mouse), understandable (readable and consistent and predictable in behaviour), and robust (compatible with a variety of different user agents, current and potential future ones).

To summarise what each principle means in practice:

Perceivable: no matter how a user is accessing the site, whether they're visually impaired and are using a screen reader or glasses, or hearing impaired and need captions for video content, they can receive all the information;
Operable: the site must function with various devices and inputs, not just a standard mouse and keyboard — so things like touch screen or even voice control;
Understandable: the information is clear and easy to understand, and the user interface responds to user actions in a predictable way;
Robust: the site is built following best practices for coding and design, and regular testing is conducted with different browsers, devices, and assistive technologies.

Under each of these principles there are guidelines that address the principle, and under each guideline there are testable success criteria that describe what specifically must be achieved in order to conform to this standard. These criteria are organised into three levels of compliance: A (lowest), AA (the most reasonable and popular), and AAA (highest, not even recommended for entire sites by WCAG).

A common misconception I encounter quite often is "we don't need accessibility, disabled people don't use our website anyway". First of all, of course they don't, if they literally can't. But second and most importantly, accessibility is not only for disabled people — it's for everyone.

Useful links and further reading:

Finch Front-End Day 1 Write-Up: Layout, Optimisation, and Organisation

am i angie? — Fri, 27 Sep 2019 08:19:56 +0000

Last month, I was fortunate enough to receive a free diversity ticket to one of the days of #FinchConf, a front-end conference held in Edinburgh. I've chosen to attend day one, focused on Layout, Optimisation, and Organisation. Here are my notes.

Jeremy Keith (probably more famous as @adactio ) on Going Offline

The web has come a long way. Websites used to be static pages, which changed with the rise of JavaScript and then AJAX (which actually stands for Ask Jeremy About XML, true story). After we started doing stuff in JS, over time some of the things like :hover actually came down to declarative HTML/CSS languages, leaving JS for something more fun.

(And look where it led us. If twenty-aughts were all about “lets use more JS”, 2019 is more like “can we please tone it down with JS already”.)

We had a couple of paradigm shifts along the way, too. One came with jQuery, which ultimately changed the way we manipulate the DOM. The other might be coming now, with the rise of service workers.

Jeremy described service worker (SW) as a “man-in-the-middle attack on your own website”, which I think is quite brilliant. Indeed, after SW is installed on a device, it acts as an interceptor for network calls, which allows us to do all kinds of things like re-routing a request from going all the way to the server to look in cache at hand instead.

Considering we now have two possible sources - remote server and local cache, - there can be different strategies for implementing service workers:

Cache first, which basically means “if you have a resource saved in cache, use it, and skip the network call”;
Network first, or “try fetching the resource from server first, and if something goes wrong, get it from cache, or if you don't have it in cache, show a specifically designed offline page”.

Which one to use is up to you. Think about what content are you working with: most likely, styles can be cached, but a list of available products has to be fresh. We also don't have to decide everything for ourselves, and can offer choice to save the content for offline use to the user, as Sara Soueidan does on articles on her website.

Jeremy showed how easy it is to start using service workers. If you understand the general logic, you can implement them. There is no need for fancy frameworks or libraries, a couple of lines of JavaScript will do the trick. Throw in a manifest, which is a simple JSON file — and you have a PWA. You don't need to have a “web app” for this to work: having a website is perfectly fine.

Rachel Andrew (no, seriously, the Rachel Andrew) on CSS Layouts

If there's a motto for CSS Working Group, it's this: We can't break the web. No, really, we can't. We have to make sure every website, no matter how old, still works as expected after spec changes.

That's one of the reasons why spec writing is hard.

And yet, we still have a lot of new things in CSS, the biggest ones being, of course, flexbox and Grid.

If you think Rachel gave a once and for all answer to “should I use flex or should I use grid” question, you're wrong. Instead, she asked: “Well, does it work?”, and proceeded with an in-depth explanation of block formatting contexts (every time you set display property, you create a new block formatting context), two-value display properties (when you say display: grid, what you are really saying is display: block grid, first value for container, the second value for its children), and logical dimensions (width and height don't make much sense if document flow goes from right to left, do they?).

Rachel’s talk was packed with information. If you want to learn more about this, here are some articles by Rachel herself to dig into:

David Khourshid on Stateful Styles

David K. 🎹

@davidkpiano

@markdalgleish Designer: *presents beautiful, high-fidelity app screen mockup*

Developer: cool, this is one of... 1,208 possible states this app screen can be in... and we need an iOS and Android mockup too

Designer: I will start working on the second screen then!

23:00 PM - 01 Sep 2019

36 214

Personally, I almost never get all the designs from UI department. A button or a link will most probably only have two states: regular and :hover; it's rare when :focus and :active are also provided. Every single link or button on the web have these states, and yet they are still forgotten. But your website or app can have a lot of custom states as well, eg “Fetching information from back-end” state, or “Loading” state, or “Success” state, or “Error” state.

That's a lot of states.

David talked about how using finite state machines and statecharts can make life easier for everyone involved. Business will have a clear overview of application flows, designers will know what screens are missing, developers will know what to implement.

David suggests to start development in old-fashioned way: with pencil and a piece of paper, in order to draw statechart for the app. It will define which states the app can be in, and what events can lead to transition between different states.

In code, the diagram can be represented as a simple object.

const machine = {
  initial: 'idle',
  states: {
    idle: {
      on: {
        CLICK: 'loading'
      }
    },
    loading: {
      on: {
        RESOLVE: 'success',
        REJECT: 'error',
      }
    },
    success: {
      on: {
        CLICK: 'loading'
      }
    },
    error: {
      on: {
        CLICK: 'loading'
      }
    }
  }
};

Getting the next state then is as easy as getting the value from this object:

const transition = (state, event) => {
  return machine
    .states[state]
    .on[event]
    || state;
}

To tie JavaScript and CSS, David suggests using data-* attributes instead of classes. Not only they are designed to hold custom application data, but they are also easy to manipulate via JS and fully accessible in CSS.

If this topic if something you find interesting and want to dig deeper into, here are some links:

David's XState library;
Statecharts: A Visual Formalism For Complex Systems by David Harel;
Pure UI, by Guillermo Rauch.

Chen Hui Jing on Devtools and Using Them to Understand and Learn Modern CSS

Modern CSS can be hard to bend your mind around when reading about it. We have a whole new layout system built-in now, and with it a whole bunch of new units, and the only way to really grasp it all is to play around with it - and here's where browser's devtools can help, showing the layout and the computed values for any selected element.

Hui Jing's slides for Finch are not up yet, but you can poke around their slides for ConnectFest or examples for Examining “squishiness” in Intrinsic Web Design article - and when I say “poke”, I mean “inspect different elements while resizing browser window like a hundred times to see how different values of different properties behave in different screen sizes, eg observe the difference between auto-fill and auto-fit (spoiler: the first one preserves space for empty “imaginary” columns while the second doesn't), and click on everything you haven't ever clicked on in devtools in browser of your choice”.

Harry Roberts on Those Small Properties You Can Add to Resource Links in `<head>` to Make Page Faster

Not much to add there. Resource hints are a simple thing to implement, and they make page faster, - use them.

Léonie Watson on Talking Technology

Screen reader users rely on machines to read out content, and the result is... boring. Yet there isn't much we can do about it, not on the web, at least - sadly, CSS Speech module has been retired due to lack of interest in implementation from browser vendors.

Shame!

We could have had amazing things, like control over voice, volume, and speaking rate, to make our websites more expressive not only visually, but also verbally.

The spec for CSS Speech is still there, so maybe one day it will be implemented. In the meanwhile, semantic HTML is free, and it makes real lives easier. Please, ditch endless <div>s and <span>s in favour of semantic elements 💛

All in all, I loved Finch. Every talk was great in its own way, and it's incredible how many famous speakers there were in one place. I overheard that it was a tough conf to organise, and there weren't many attendees - but I'm very grateful it still happened.

Happy coding, and gods bless.

10x CSS

am i angie? — Wed, 14 Aug 2019 19:49:24 +0000

Let's get this straight: CSS is messy. It's a beautiful language that allows web to flourish - but it can get very dirty very fast. One of the reasons is the nature of the language itself: it's resilient, it's very forgiving - and it doesn't force almost any rules on you.

You can use tabs. You can use spaces. You can write everything in one line. You can repeat the same ruleset over and over again, each time adding one new declaration. You don't even need to have all the semicolons. This is your world, you can do whatever you want.

But should you?

Unlike painting, I don't think your CSS code is a place to get crazy.

There has been a lot of talk over the years about large-scale CSS architecture, and now we have all sorts of methodologies like BEM, SMACSS, and, my personal weapon of choice, Atomic OOBEMITSCSS. But none of them deal with the smaller scale, where most of our actual work is done.

I'm talking about single rulesets.

As said before, nothing stops you from writing declarations in any way or order you want. One might argue it doesn't matter, if it gets the job done; but as for any other language, better code style in CSS leads to better DX, better code quality, and fewer bugs.

So, lo and behold, my personal approach to lower-scale CSS structure:

.classname {
    /* is this thing even visible? */
    display: block;

    /* where is it on the page? */
    position: absolute;
    top: 0;
    left: 0;
    width: 20%;
    height: 300px;

    /* what does its content look like? */
    font-family: 'Roboto', sans-serif;
    font-size: 1.2rem;
    font-weight: bold;
    font-style: italic;
    text-align: center;
    text-transform: uppercase;
    color: rebeccapurple;

    /* what's its box model? */
    padding: 10px 0;
    margin: 20px;
    border: 2px dashed salmon;
    border-radius: 5px;

    /* backgrounds, 'cause declarations tend to get so very long */
    background: url(someawesomepic.jpg) center center no-repeat;
    background-size: cover;

    /* purely a e s t h e t i c s */
    transition: all .25s;
}

While by no means complete, this example covers the most frequent properties one usually has to define. No matter what, some declarations stick together, because together they make more sense: width and height, border and border-radius, font- and text- properties, positioning properties, and so on.

I have been following more-or-less this structure for almost a decade now, and it has made my life much easier. I only need a glance at any given ruleset to understand what's going on, what's missing, and spot some minor bugs like duplicates or declarations that will never actually be applied.

It might seem as if I'm arguing that my system is great - and while it obviously is, what I think is the most important here is to actually have one. It is hard to follow a story when it's all over the place, and it's very hard to work with code like that.