Accessibility: Semantic labeling

Feature
1

This is split out from the master accessibility thread: Accessibility audit and shepherd for making improvements.

Accessibility question: Are form fields and links properly labeled?

Not always.
Missing label noted in screen shot of checker tool below.
See Techniques for proper labeling here H91: Using HTML form controls and links | Techniques for WCAG 2.0

I tried gathering more data using Inclusive Design Research Centre, trying to find tools to automate some of these checks. I checked several pages as representative of the user interfaces that make up the bulk of user interactions (home, category, topic pages). There was one class of “known problems” (using <b> tags). There’s some previous conversation here and here about whether the <b> / <strong> distinction is meaningful (from the perspective of the accessibility audit the answer is a definite “yes,” even if this might feel pedantic or like it’s adding cost of bytes over the wire for the longer tag).

I didn’t yet investigate the “potential problems,” but could include that in the next phase of improvements.

2

So the next steps here would be: what would it take to change <b> tags to <strong> on the accessibility checking tool’s recommendation? Or if folks have questions or concerns about trusting that tool’s recommendations, we could look for other guidance here (ideally that comes with automated tooling).

3

One problem here is that the checker needs to be loading the full page in the browser, as rendered by JavaScript – if it is doing a curl command it is not getting the same page the actual browser is getting, as the whole page is built using JavaScript commands.

4

@codinghorror Ah cool, that seems like a good thing to watch out for in general. :+1: I think there are bunch of better tools to do this as well, and it’d be good to find out more there too!

For the particular issue here, I don’t see as much how that’s related though, that tool seems to have done the trick in spotting this bit. :slight_smile: