The official reference would be WCAG (aiming for level AA compliance is the most common):

https://www.w3.org/WAI/standards-guidelines/wcag/glance/

https://www.w3.org/WAI/WCAG22/quickref/

I usually find these docs verbose and intimating though. There's a lot of more friendly summaries and articles to pick from like:

https://webaim.org/standards/wcag/checklist

For alt tags, alt="" is appropriate if the image is only decorative or not adding anything that would be useful to someone on a screen reader. A useful tip for deciding on what to do is to get familiar with a screen reader interface available for your browser - see how easily you can browse, use, and understand your own web pages without being able to look at them.

> I am confused by the disparity between stated good practice and common practice by large websites.

Refer to WCAG for what to do and generally ignore what even large popular websites do.

Most websites don't prioritise accessibility, even the basic stuff. I think this is generally because: there needs to be knowledgable advocates of accessibility on the team, it's not always obvious how to follow the rules even when you're aware of them (there's subjective and contextual parts you can't automate, like with alt tags above), it requires extra design/dev/testing resources to do properly, people see other popular websites not following the rules so don't bother themselves, and branding often takes priority.

> For alt tags, alt="" is appropriate if the image is only decorative or not adding anything that would be useful to someone on a screen reader.

Malicious legal firms looking for quick payouts do scan for missing alt tags and file lawsuits based on their absence.

Given the option to pay corporate lawyers $$$$/hour to educate judge and jury on the finer points of the WCAG standard and then proving to said judge and jury that the occurrences pointed in the lawsuit meet a subtle distinction, most companies settle for adding text to all alt attributes avoiding the calamity in the first place.

At the cost of worse experience for screen reader users of course.

That has been what I have mostly done so far, but the fact that big sites do it and there are no apparent complaints or pushback makes me doubt my approach. Two of the sites I mentioned are trying quite hard, and the other does at least have alt tags.

With regard to using screen readers, do I need to use multiple screen readers if they differ?

There's some examples here of websites getting in trouble for not being accessible (the Domino's Pizza one is well known) if that helps:

https://en.wikipedia.org/wiki/Web_accessibility#United_State...

> With regard to using screen readers, do I need to use multiple screen readers if they differ?

Unfortunately, they all have their own quirks. Alt tags and other basics that are built into HTML should be pretty simple and consistent between screen readers. More custom things like modals and JavaScript interactivity and also random things you'd expect to be simple can be a headache though and require you to research what quirks screen readers have (random example: https://www.powermapper.com/tests/screen-readers/labelling/i...). It's very similar to how IE, Firefox and Chrome can render and behave differently on the same web page.

If you're testing on one screen reader though, you'll still be doing better than most and it'll catch a large portion of potential problems. It'll help with your alt tag dilemma as you'll experience first-hand how annoying useless alt tags are even if big websites are using them.

* Turn off CSS. Can you still read/interact with the content? Is the content in the correct order?

* Are there page headings? Some screen readers navigate the page using headers, tags h1-h6.

* Are the controls far enough a part that a motor impaired person can interact with the page? Think Parkinson’s, epilepsy, MS, and so forth.

* Does the content display with sufficient color contrast? I wrote a tool evaluate all colors of a color scheme for contrast according WCAG definitions: https://github.com/prettydiff/colorContrast

* You can test any page to determine if the content is well described using this other tool I wrote. You simply copy and paste the JS code into your browser console and a report displays on screen: https://github.com/prettydiff/semanticText

I have always done the first. Not thought enough about the third. That tool looks useful - it gives me something to show people other than my opinion.

Thanks.

Microsoft makes a very helpful Chrome and Edge plug-in that checks your site against WCAG 2.1 AA recommendations. Run it and fix the issues one by one and you're like 80% of the way there.

https://accessibilityinsights.io/

The other 20% is often like judgment calls on navigability and readability on screen readers. You can install one (or several) and try to navigate your site and menus using them. They are often free, especially the ones built into major operating systems.

If you want help, there are also website accessibility consulting firms, sometimes run or staffed by people who are blind or hard of vision. The one we used gave us an extensive audit and documents and spreadsheets full of things to address. It was largely similar to the methods I described above though, so I'd start with those first.

(I'm a sighted frontend dev who's done accessibility work and audits for a few orgs, but this isn't my specialization. It just doesn't take much to do all the low hanging fruit, but most websites don't bother. Depending on your jurisdiction, it may or may not be legally required for your site, but if it only takes you a couple days... Why not?)

I think the thumb rule should be for a basic test is is suing the tab key can I easily navigate your website. If I can’t then you need to fix that.