1. Check if the image really needs a description. Maybe it is decorative. The W3C alt decision tree(opens in a new tab) is an excellent resource to help you categorize your photos.
2. Avoid writing "Image of", "Icon of", or "Picture of". Screen readers announce the presence of an image. Adding these words inside your alt is unnecessary.
3. Keep it as short as possible. Be specific but not overly descriptive.
4. Try to put the most essential information at the beginning of your description.

allyphanta11yphant teaches web accessibility, one step at a time, broken down into manageable pieces. We call these challenges. You won't need to read large amounts of text to complete those. Instead, you will learn by applying the concepts in code. Get started with your first web accessibility challenge and improve your skills.

A first approach of ARIA with a toggle button

How an array was built before Ecmascript v1

Compilers are pipelines with a serie of step. Each step transform the input and provides data to the next.

Each step has then a contract with the input provided and its output 😃

The author goes in depth.

We can completely segment one component of the compiler from another by having the right form of data structure in between them. To build that data structure, you don’t need to know anything that happens to it afterwards, you just need to know what it means.

To solve XDG misconfiguration, if wanted.

That would be awesome indeed: using @scope (.classname) to specify styles that only applies from this class.

In a form, the user gets the screen reader navigation capabilities. The tab key becomes the norm again, and all that helps without aria is then the <label for=""> each input.

A disabled link is not a link, its just text. You need to really need to rethink your design if it calls for disabling a link.

The href attribute on a and area elements is not required; when those elements do not have href attributes they do not create hyperlinks. - W3C, Hyperlink spec

and how to build a disabled link... the hard way

aria-label, aria-labelledby, and aria-describedby can all be used to bring extra clarity to a given element when it's exposed to assistive technology.

• aria-label overrides an element's name with contents you specify.
• aria-labelledby replaces an element's name with contents from another node on the page. You'd use this when you'd already have a visible label anyways.
• aria-describedby sets your element's description to the contents of another node on the page. This is great for noncritical, supplemental information.
• aria-description… is coming.

As always, avoid ARIA whenever possible.

Using a description list dl with description terms dt and their description detail dd: so basically a list of key - value pairs.

Advangtages for screen readers instead of divs:

1. The screenreader could tell the user how many name–value groups are in the list.
2. The screenreader could tell the user how far into the list they are.
3. he screenreader could treat the list as one block that the user could skip over if they're uninterested in it.