DEV Community: mighty_peach

Accessible images, pictures and SVGs

mighty_peach — Thu, 02 Feb 2023 08:06:45 +0000

Author of cover image is Marek Piwnicki

Accessible images

Images are an important part of any web app. We are using them for a lot of different purposes: decoration of text content, information about interactive UI, logos and icons. And how many goals we have for images, so many problems we meet in everyday routine. How to make image accessible? How to load different image for different device? What to do with <svg />? Animated <svg />?! Through this guideline, I want to solve these main, common problems with accessible images in web.

As always, I want to refer to W3C guidelines, as the source of most reliable and safe information. It splits images by several categories, we will check few of them in detail. But it doesn’t describe how to optimise images, which image format to use, we will check these topics too. Let’s start with categories.

Why we can’t just put image to DOM with <img src=”my/image.jpeg” /> and keep it like this? Because:

User may use your site with a screen reader.
Your site needs to have proper Search Engine Optimisation.
User could use your site from difference devices/screens.
User could browse your site with bad internet connection.

Simple setup

If the image is simple enough, that you could describe it with one sentence, or it presents simple information, a small piece of data, we could use <img /> with alt attribute.

<img src=”my/img.jpeg” alt=”A white owl” />

Simple rules for alt content:

Do not use words “picture”, “image of”, “pic of”. <img src=”my/img.png” alt=”picture of beautiful white owl” />
Describe shortly what is going on in the image.
Provide instruction if needed instead of describing image’s content.
Add small explanation for images with icon role.

Providing alt attribute also helps for SEO – some search engines rely on it for “understanding” content of images on your site.

Decorative images

We often use images to decorate content: add snowfall to the site ❄️, add emotions for phrases 😂, create special mood 🌓. For this type of images, we have a really simple rule – keep alt attribute empty.

Texture for background image

<img src=”src.jpeg” alt=”” />

Attribute role=”presentation” also allow skipping this image for screen-readers. If we do not add empty alt attribute to <img /> tag, screen readers will find and pronounce src attribute of image, that can confuse users. And do not put whitespace accidentally, alt attribute will be not hidden from screen readers then.

Functional Images

If you have buttons with only image as content - you need to add simple description as: “what will happen if I will click on button”:

<img src=”src/print.png” alt=”print the form” />

You should never use image as a single source of truth. Always add text or tooltip for icon, that could be an action too and have some sense in text. You can add, at least, title attribute.

Graphs and charts

Sometimes we have a very complex image that represents some data: image of a table, a graph or maybe screenshot of some chart. In this situation, we can’t describe image with simple sentence, but user of screen reader or search engine could have profit of reading data of image. Tag <figure /> will help us in with the problem:

<figure role="group">
    <img src="chart.png"
         alt="Interest about Vite and Webpack over the year" />
    <figcaption>
        On graph we can see, that Vite is on the pick of popularity with rate 100, webpack has stable 13 points of popularity WorldWide. 
    </figcaption>
</figure>

So then we associate an image with provided text. If this text shouldn’t be in site content - we can visually hide <figcaption /> from user:

.visually-hidden {
  position: absolute;
  position: absolute !important;
  width: 1px !important;
  height: 1px !important;
  padding: 0 !important;
  margin: -1px !important;
  overflow: hidden !important;
  clip: rect(0,0,0,0) !important;
  white-space: nowrap !important;
  border: 0 !important;
}

SVG

Often, sites have SVG icons for logotypes, as secondary icons or even as a hero picture. We are using them to provide better quality of content, to inline image or animate it. But how to do <svg /> content more accessible?

Let’s imagine that we have this SVG:

<svg height="100" width="100">
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red" />
</svg>

First, let’s add <title /> tag to the body:

<svg height="100" width="100">
  <title>Red Circle</title>
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red" />
</svg>

Hmm, what if our <svg />asks for proper description? Let’s add <desc /> tag:

<svg height="100" width="100">
  <title>Red Circle</title>
  <desc>Red circle with black border and transparent background</desc>
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red" />
</svg>

Also, let’s add role=”image” attribute, to make browser “think” that this bunch of SVG tags are single image:

<svg height="100" width="100" role=”image”>
  <title>Red Circle</title>
  <desc>Red circle with black border and transparent background</desc>
  <circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red" />
</svg>

User Generated Content

A lot of content on the Internet is user generated. Users are loading photos, custom thumbnails for articles, user avatars. How to make this content accessible? There is a complex solution - check what is on photo, add keywords to alt attribute as Twitter does. Yeah, sounds almost impossible. As simple solution - you could provide to user an input, where users could describe pictures or even add alt attribute.
I agree, we can’t do this for every image, but we could add “speculative” alt attribute, for example, we could add alt=”Profile picture of user @peact_tea”.

Wrapping up

With all this content, we could say - easiest way to make image accessible is just adding alt attribute (even empty still works - <img /> tag without it is not valid) to <img /> tag made it accessible. Unless somebody wrote something unexpected here 😅. Add title attribute to SVG and icons, to buttons and links, that contains only images and never use image as single source of truth.

(https://www.w3.org/WAI/tutorials/images/)[https://www.w3.org/WAI/tutorials/images/] - accessibility guidelines
(https://squoosh.app/)[https://squoosh.app/] - optimise your images via squoosh

About a11y in general

mighty_peach — Sat, 21 Jan 2023 18:39:00 +0000

Author of cover image is Wolfgang Hasselmann

What is accessibility?

User of old laptop with bad performance - accessibility. User of mobile app who have broken hand - accessibility. ASAP task that you need to do with bad Wi-Fi in a loud place - accessibility.

Accessibility is the ability of users to complete their tasks in a product in any condition: with broken hand, in loud place, even without internet. I plan to help you find easy ways to correct accessibility of your app/site and how to manage accessibility in future.

Why accessibility is important?

Yeah, we all heard that accessibility is mostly for screen-reader users, or that percent of users so low that we can neglect accessible UI. That is not really true. Imagine a user, who is trying to answer something really important via phone app with having grocery bags or even little child in one hand. Or user, who is working using your site, while being in train with continued tunnels on a way. Or even simpler, a user who turned on battery save mode, and because of that display lost its contrast. What do scenarios have in common? User without any disability became to have problem with access to a product, with usage of a product.

Accessibility is not only about people with disabilities. A product with accessibility-oriented design would help every user of your app. (And even to you, if you are a mouse-less user 😅). Some rules and core principals further in text will show, that accessibility is not about “how to design this particular component”, it’s more about “how to make system and every-day routine being more accessibility friendly without waste of time”.

I would even count performance of your product as an accessibility issue. I was in situation with 4Mb Internet, that constantly toggle its workability, and I got used to download everything that I need during night. And if your product works only with stable optic Internet, some users with bad devices, in places with bad Internet just can’t use it, so have no access to your product.

In web, Web Content Accessibility Guidelines (WCAG) helps designers and developers make accessible UI/UX. But the same rules work for Mobile/Desktop development.
Good practice of writing guides is base a guide on four principles, that WCAG provides: perceivable, operable, understandable, and robust. Let’s talk a little more about these principles.

Perceivable

This principle tells us that information of a product should be accessible via any comfortable for user way.

Of course, we can’t make this for a whole product, for 100% cases. But the interesting part is we don’t really need. Most of our app is a text, so we don’t need to bother with doing something with it - just put it to the proper tag: <h1/> - <h6/>, <p/>. It is easy with images, just add alt attribute to the image tag and that’s it. It is harder for tables and graphs, and to be honest, we can bother more with images too, but I will create separate article-helper for these content.

Next, we need to focus on visual representation of content:

For large text, (18px) contrast should be 3:1, other text - 4,5:1.
But sometimes, for example, for disabled state, you can’t continue to use the best contrast and make input looks like disabled one.
Text and colour should never be the only one source of information for user, add icons to buttons and links, add borders to information statements (pop-ups).
For form field, as input or textarea, use icons together with colour for validation state.

Operable

Users should have the ability to use a product with comfortable input devices. User can use mouse and keyboard, screen-reader or touch-screen and should be able to complete a scenario.

Make focus state visible is an easy way to support this. Together with keyboard navigation, it is a good start for accessible UI. And, as developer, you don’t really need to do a lot, don’t turn outline off, use semantic tags: inputs inside forms with labels, hierarchic headers, name parts of layout with <main />, <article /> and others. This isn’t asking for additional time in most cases, but you automatically add keyboard navigation, that means screen-readers support 😅

So, basically you need:

Use HTML tags semantically.
Add focus, hover, active and visited states for controls, links.
Check that user can complete scenario with only keyboard: tab, enter, arrows.
Make focus state be visible.
Design complex controls using simple built-in ones (and check the guide).

Understandable

“Information and the operation of user interface must be understandable” - quite meaningless definition. But we can find few good thoughts here:

Speak in user language. And this is not about English, French or Spain. If your user is not a lawyer - explain complex terms and simplify a text.
Be consistent in UI - if you are using green button with “OK” text as agree-button, don’t suddenly use orange with “Agree” somewhere.

Robust

Your product should be accessible with assistants. Sounds scary, sounds like a lot of work. Nevertheless, this is pretty simple with few rules:

Use <a /> for links, and <button /> for interactive elements. If click changes URL – you need to use <a />.
Use role attributes, for example role="alert". This allows to certainly mark HTML element with its role for screen-readers.
Add alt attribute for images. This not only allows reading image content for screen-reader users, but also could show text in case of image loading error.

Wrapping this up

These simple rules don’t ask for “let’s plan next sprint for accessibility tasks and forget about it” and sounds easy enough to make your product accessible even without convincing your boss 🙂

Few additional tools, that can help you:

https://developer.chrome.com/docs/devtools/#accessibility - Chrome developer tools allows testing accessibility right in browser.
https://www.deque.com/axe/ - Axe tool has convenient browser extension for accessibility testing (also, you can use Axe with Jest).
https://github.com/pa11y/pa11y - Tool for testing ally using node.js (it also has integration with Cypress).
https://www.npmjs.com/package/eslint-plugin-jsx-a11y - ESLint plugin, that shows errors and warnings right in your editor.

Dependencies hell

mighty_peach — Sun, 20 Mar 2022 15:18:27 +0000

How does typical frontend project start?

git clone project

cd project

npm i

And we have received thousands of modules installed in the OS, megabytes (or gigabytes) of files. After installation we try to start a project using npm start, but we get some node-gyp, versions errors or vulnerabilities This walls of information, that we can't fix, are really frustrating. I want to talk about some of these problems.

What’s wrong with deps

Deps size is so big

Let’s see how much size popular project Create React App has:

It has 300mbs that does nothing. After template was created devs can install mobx, axios, css-in-js packages, components library, something like lodash or rx.js, some type definitions for typescript, etc. In result we have half of GB space of empty project without actual code base.

I want to remind - we are in chip shortage, Apple asks ~200$ for 128GB. These gigabytes of packages, that we transfer back and forth, don’t just disappear — they are stored in our disks (and often this is global npm packages, that we can’t just delete as project dependencies), in DNS servers, in data centres. This is unbelievable how irresponsibly we develop software, without looking into future and software complexity.

Deps doesn’t update theirs deps

How regularly devs update their package dependencies? During my practice, this doesn’t happen as often as necessary. Let’s look at create-react-app for example. It has jest as dependency with version 27.4.3, when I wrote this article actual version was 27.5.1.
Jest has micromatch package with version 4.0.4 (that was actual version for jest@27.4.3). And micromatch has minimatch package with version 3.0.4. But actual version is 5.0.1, that solve, at least one major security problem.

And this is just five minutes research, Create React App has dozens of dependencies, which have dozens of dependencies, which have... One of them could be out of date or has vulnerability issues.

Deps control can be more hard with very popular projects. Cypress updates its version very often. Sometimes it happens twice a week. When I’ve started to use Cypress I updated it every two week, but then I just got tire to do this. But this was mistake - Cypress team, probably, fixed some major bugs, solved some vulnerabilities in this updates. But as developer in modern and big project, where you have many deps, you can’t hold dependencies actual every time.

Maybe you don’t need these deps

There are many instructions and StackOverflow answers that recommend: “Install this to solve your problem”. Package distribution systems (npm, yarn, pnpm) are very easy to use, they installed by default in some Unix-system, they installed with Node.js. And this ease doesn’t good for our industry.

Because complexity of IT is growing up from year to year, new folks learn only the tip of the iceberg (not all people, of course). Because the main goal of business is getting money, not creating good and robust software, we have no time to control every aspect of development. Open-source folks spend their own time to support projects.

And because of these points we don’t spend time to check package size, all dependencies (include dependency’s dependencies), vulnerabilities, but much more, we don’t think that this package is necessary. We install Axios instead of just using fetch api. We use css-in-js or css modules instead of using BEM. We could use just REST API, instead of GraphQL. And there is much more examples.

What we can do

Prioritize robustness over development speed and “developer experience”.

Ask yourself about package necessity, maybe there is standard library method for your problem, or you don’t need full module, just a part, that you can copy-paste to your project.
Check not only stars and popularity, but also maintenance, update regularity, communication with community
CRA doesn’t update about year, we don’t have any news from their team. This is red flag not to use CRA. Actually, they released new version, but anyway, this was red flag :)
You can store node_modules in version control system

That sound stupid, but this is easy way to maintain dependencies, to ask questions “why do I need this”. This care us from unexpected node_modules extending.
Best practices are propaganda for juniors

This topic can be disputed, but I think that the Patterns and other best practices, that puts into folks head to use it without thinking about necessity - are propaganda just as is. The Patterns are good, but we need to use it when we really meet a problem in code base. Sounds like I recommend to go to the Assembly and code using it, but no, I just recommend to think twice before doing something.
Solve actual problem, don’t solve future problem

I have met so many times, when “architect” decided to use something like a store, argued that in future we could have a lot of data which we can share between modules and etc. And in this scenario we could use the react context and change it with store when we actually find a problem with data management. Another problem is technology FOMO - you need to use popular solutions, be in edge of technology. And there is much more examples when we solve problems that doesn’t exist.

Easy receipts using std

I want to show easy solutions of popular problems using standard library.

Often we have installed by default Lodash in our projects. Lodash give us some handy functions, some syntax sugar. One of the best function is debounce, that we use when we need to control user input.

What’s wrong, you can ask. Source code of function is unreadable. This is little function, but we install a whole Lodash for this. This is how debounce looks using plain JS:

function debounce(func, timeout = 300){
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => { func.apply(this, args); }, timeout);
  };
}
// copy-paste from https://www.freecodecamp.org/news/javascript-debounce-example/

The difference is dozens of lines of code, is less maintainable, needs more code control.

We often use css-in-js or special setup of webpack to stop class intersection. Really simple solution is BEM — methodology of a class naming. We need to name every class like block_element-modification. Using React it looks like: componentName_someWord. This is easy.

Wrapping up

When I've written this article I never stood a goal to change your mind, but if you start to think more about dependencies - this would be cool.

I can recommend you to read or watch:

nikitonsky - Software disenchantment
Jonathan's Blow - Collapse of Civs

Thank you ❤️