Website accessibility

@JEET, you’re talking like you know what his website is. Care to share?

Also ALT is not a tag, it’s an attribute. In fact most of your terminology is wrong.

Now that said, you also made a number of good points.

As many of you know I’ve been working the past decade as a web accessibility and efficiency consultant. Specifically, I go into places being sued for non-compliance and give guidance — and assistance re-coding — sites to meet accessibility norms to a sufficient level to negotiate in good faith with the courts or plaintiff. Done properly you can often get any fines waved, or negotiate a more reasonable settlement if you simply fix the damned thing in a prompt and orderly fashion.

In days past, when I first switched from full stack development unto and of itself to a focus on front end accessibility, life was easy. Most every site that failed compliance the problem was simple stuff. Improper metrics (aka using pixels for everything), fixed width layouts, invalid/improper semantics, and illegible colour contrasts. The past five or six years though a new problem has arisen: JavaScript for nothing and garbage “frameworks”.

One of the biggest blights upon web accessibility at the moment is “JavaScript for Nothing”, “JavaScript without graceful degradation”, also known as “JavaScript as the only means of functionality”. JavaScript in and of itself is not an accessibility violation, but it should not be used for anything normal users might need to do on a normal site.

Like navigation, contact forms, shopping carts, and basic delivery of content. If scripting off these things do not function, you are in violation of accessibility norms. PERIOD.

These things should be coded to work without client-side scripting FIRST, and then / only then should you enhance them with JavaScript, and only as needed or in ways that improve the overall user experience.

This is why how frameworks like React, Vue, etc, “work” are a giant middle finger to usability and accessibility since what they do is typically useless to screen readers (software reading the page aloud), braille readers, search engines, users/workplaces that block JS for security reasons, and a whole host of other perfectly valid ways of using the web. The Internet is about MORE than perfectly sighted users in front of a screen.

The same goes for website semantics, you need to understand things like “landings” — places keyboard and other alternative navigation methods can hook to get around the page — and why logical document structure is so important as your working base. Your HTML should be the foundation of your accessibility, and slopping it together in a broken, nonsensical, and half-assed manner leads to non-compliance.

Hence why these equally dumbass “front end frameworks” like bootcrap, tailfart, etc, etc, create far more problems than they solve. They too are clearly written by people who are unqualified to write a single damned line of HTML or CSS. They don’t use proper semantics for logical document structure, they use broken font metrics (oft willy-nilly mixing PX and %/EM), they oft operate in complete ignorance of legibile colour contrasts out of the box, and on the whole are train wreck laundry lists of how NOT to build a website.

… and betwixt the two of those alone, the people who say “nobody cares about the code” are talking out their asses. Bad code leads to violation of most if not all accessibility minimums.

Take any example from bootcrap and it’s out of the box style. One of the best ways to explain accessibility violations is to take something in total violation and to break it down.

Starting a document with a H4? 2:1 ratio of menu text color to the background color? Mix-and-match of PX media queries/widths with dynamic font sizes resulting in responsive layout being utterly broken? Abusing lists around obviously tabular data because “teh tabuls r evuls!!!” idiocy?

Hell, take v5’s splash page crap: (something we’ve been told for decades not to do in the first place)

In terms of JUST accessibility issues caused by their code, we have a H3 doing H1’s job, a run-on sentence masquerading as a menu as they have anchors slopped into NAV without a UL/LI structure, H1 doing H2’s job, paragraphs around non-paragraph elements like buttons/button-like anchors… and that’s just the markup. To screw up the most basic use of HTML in only 24 lines of content markup illustrates beyond a shadow of a doubt the clowns who MADE bootstrap are unqualified to write a single damned line of HTML!

Hence why they vomit up trash like this:

 <body class="d-flex h-100 text-center text-white bg-dark">
<div class="cover-container d-flex w-100 h-100 p-3 mx-auto flex-column">
  <header class="mb-auto">
      <h3 class="float-md-left mb-0">Cover</h3>
      <nav class="nav nav-masthead justify-content-center float-md-right">
        <a class="nav-link active" aria-current="page" href="#">Home</a>
        <a class="nav-link" href="#">Features</a>
        <a class="nav-link" href="#">Contact</a>

  <main class="px-3">
    <h1>Cover your page.</h1>
    <p class="lead">Cover is a one-page template for building simple and beautiful home pages. Download, edit the text, and add your own fullscreen background photo to make it your own.</p>
    <p class="lead">
      <a href="#" class="btn btn-lg btn-secondary font-weight-bold border-white bg-white">Learn more</a>

  <footer class="mt-auto text-white-50">
    <p>Cover template for <a href="" class="text-white">Bootstrap</a>, by <a href="" class="text-white">@mdo</a>.</p>


Code (markup):

To do the job of:


		<h1><a href="">Cover</a></h1>
		<nav id="mainMenu">
				<li><a href="#">Features</a></li>
				<li><a href="#">Contact</a></li>

	<main class="coverPage">
		<h2>Don't Do This!</h2>
			Cover is a one-page template for building some dumbass time-wasting splash page devoid of actual content of value. It's the type of rubbish that was on all the "don't make sites like this" lists of a decade ago, that are back with a vengeance because every new generation has to learn the hard way!
		<ul class="actions">
			<li><a href="#">Learn more</a></li>

		Cover template for <a href="#">NotCrap</a>,
		NOT by <a href="">@mdo</a>.

Code (markup):

Immediately fixing all of the accessibility woes caused by the garbage markup, and killing off the pointless idiotic code bloat caused by the tool they claim is somehow magically “Easier” when it clearly is not.

Then there’s the style. I won’t get into the shit-show of how their CSS is applied to the markup, but their values alone are ignorant trash. They’ve got dynamic fonts — 1rem on BODY — mixed with media queries like max-width:1400px; REM is a dynamic font size, if the breakpoints are there for the content, and the content dynamically resizes based on the user’s font preference, ALL of their media queries are broken for anyone who doesn’t use 16px as the default font size. It’s a giant middle finger to users with accessibility needs.

If you’re using EM/REM fonts like a good little doobie, this:

@media (min-width: 576px) {
  .container, .container-sm {
    max-width: 540px;

Code (markup):


Just as their default colour choices for things like the menu violates accessibility norms. Their bg-dark default is #343A40 whilst the non-current menu items are rgba(255,255,255,0.5). The render color for text is therefor #8D8F90… if we plug that into a contrast checker like the one at webaim:

We discover it fails AA and AAA for normal text, AAA for “large text” (which this is not “large text”). Even more of a laugh, that little dark underscore they use? Fails UI element minimums.

Out of the box they have utterly unacceptable values because the people working on it also are unqualified to do front-end design!

Hence why if you used a “framework” — be it HTML, CSS, or JS — to build your front-end? You are almost GUARANTEED to be in violation of accessibility minimums. Because the people who create and use frameworks are unqualified to write a single damned line of code, much less build a website. Do not pass go, do not collect your Covid “stimulus payment”, go straight to jail.

And these are the types of things you have to look for when you’re doing an accessibility analysis. If you are willing to send me a link to your site, I can provide you an initial overview of what needs to be fixed. I do these for prospective clients no-charge two or three times a week; it’s not even fifteen minutes work. One more won’t break my back.