Search posts, tags, users, and pages
What do you recommend as good learning resources for Web Content Accessibility besides (in addition to) the following sites?
w3.org/WAI/standards-guidelines/wcag
w3.org/WAI/fundamentals/accessibility-intro
What an excellent commentary!! Huge thanks to Jason Knight ! It will take some time to go through these resources, but I'm quite motivated to learn this stuff.
On the side note, I did take a very quick peek at webaim.org's HTML out of curiosity. Would you say that their site's HTML is written quite well? I thought it was. I notice that their div tags have a concise class name that describes what it was in each of them. Consequently, their primary stylesheet is also concise. Both HTML and CSS are far more compact than anything I've seen lately. I also thought that the site looked quite good in terms of appearance. It's amazing to me how they manage to render the site so well visually with such a compact set of code. Again, no wonder you've called Bootstrap "Bootcrap" and very heavily criticized BEM when I asked. People should learn this stuff better! I feel like it's been hard to navigate through waves after waves of articles advocating all kinds of conflicting and puzzling information and pick the right one. BEM is definitely one prime example, because all kinds of people who are supposedly well-known in the industry claim it's a good idea, which, we've already gone over this, is completely false. That's pretty messed up, I think.
Kevin C. In terms of webaim's markup it has flaws, some of which could even cause accessibility issues -- but as you noted it's far, FAR cleaner than most of the schlock out there. Still, I could point at any section of their code and find severe HTML issues.
Issues like the lack of media targets on their stylesheet links, gibberish numbered heading orders... though numbered heading use is the #1 place people screw up in their HTML. For example having the first heading on the page be a H2 is semantic gibberihs. Having the first heading inside (the pointless HTML 5) SECTION tag be anything BUT a H1. Completely ignores the concept of logical document structure.
Take this part for example:
<div id="headcontainer" class="clearfix" style="background-image: url(/media/banners/home.jpg)">
<header role="banner">
<div id="skiptocontent"><a href="#maincontent">skip to main content</a></div>
<h2><a href="/"><img src="/media/logo.png" width="302" height="80" alt="WebAIM - Web Accessibility In Mind"></a></h2>
<nav role="navigation">
<h2 class="hidden">Main Navigation</h2>
<ul>
<li><a href="/services/">Services</a></li>
<li><a href="/articles/">Articles</a></li>
<li><a href="/resources/">Resources</a></li>
<li><a href="/community/">Community</a></li>
</ul>
</nav>
<div id="search">
<form method="get" role="search" action="/search/" id="sitesearch">
<p class="search"><label for="q" class="hidden">Search Terms</label> <input type="text" name="q" id="q" placeholder="Search WebAIM"><input type="image" src="/media/template/search.png" alt="Submit Search"></p>
</form>
<p class="intro"><a href="/intro">Introduction to Web Accessibility</a></p>
<p class="training"><a href="/training">WebAIM Training</a></p>
</div>
</header>
</div>
If they were using numbered headings properly, both the HEADER and NAV tags server ZERO legitimate purpose, nor would they need that aria role bloat. The use of paragraphs around things that quite clearly are NOT grammatical paragraphs is semantic gibberish, those static presentational images really have ZERO business in the markup, nor does that STYLE attribute have any business being there either... .and even that "skip to content" link in any proper markup would be redundant to what the first H2 would/should provide on any UA where such things make sense, the form lacks a fieldset to mark user editables.... and of course the biggest giant glaring cock-up of all, PLACEHOLDER IS NOT A FLIPPING LABEL!
Whenever you see that last part on websites, it's ignorance and incompetence in action -- SADLY the artsy types love it even if it's flipping the bird at usability and accessibility. And no, hiding the LABEL and then derping along with the placeholder is NOT a fix.
They're not doing a single thing that this:
<div id="top">
<h1>
<a href="/">
Web<span>AIM <span>-</span></span>
<small>Web Accessibility in Mind</small>
</a>>
</h1>
<ul>
<li><a href="/services">Services</a></li>
<li><a href="/articles">Articles</a></li>
<li><a href="/resources">Resources</a></li>
<li><a href="/community">Community</a></li>
</ul>
<!-- #top --></div>
<div id="searchBanner" class="home">
<div>
<form method="get" action="/search">
<fieldset>
<label for="search_text">Search WebAIM</label>
<input type="text" id="search_text" name="q">
<button title="Search">
</fieldset>
</form>
<a href="/intro" class="intro">Introduction to Web Accessibility</a><br>
<a href="/training" class="training">WebAIM Training</a>
</div>
<!-- #searchBanner.home --></div>
Could not provide in terms of accessibility, usability, or style IF one reserved the first H2 on the page for their "We have web accessibility in mind" text or whatever heading starts the main content. (the part in giant red on their home page) -- since the first H2 or HR on a page SHOULD mark the start of the main content, which is why HTML 5's pointless MAIN tag is another silly redundancy to try and plug the fact most people refuse to use numbered headings properly.
So it has issues. A LOT of those issues are caused by the disaster that are the new HTML 5 structural tags, which really belong more in 1997 than they do 2018. MORE of those issues are caused by the silly aria role nonsense which is more placebo than fact in terms of supported user agents, and if anything reeks more of trying to address the wants of the content thieves known as "data scrapers" than it is actually helping users with accessibility needs.
Which is why there's a LOT of talk in certain accessibility circles on how much of HTML 5 as a markup specification is a step BACKWARDS from HTML 4 Strict. Now, I'm not saying the WHOLE specification is so flawed, there's a lot of good stuff in there... but ARTICLE, ASIDE, MAIN, SECTION, NAV, HEADER, and FOOTER are all pointless code-bloat redundancies that honestly, feels like they tried to give the people who went from endless pointless TABLE's for nothing to endless pointless DIV for nothing, "legitimate" tags to continue with their broken, outdated site-building methodologies '90's style.
Said result hardly being a shock given how many people never embraced HTML 4 strict, semantic markup, and logical document structure, and just spent a decade and a half sleazing out HTML 3.2 under the guise of 4 tranny -- and as I've said many times now slap HTML 5's lip-service doctype atop the same broken, bloated, outdated, outmoded methodologies.
... and throwing more tags into the specification has only muddied the waters.
The simple concept that THE H1 (singular) is THE heading (singular) on EVERY page of a website that everything on EVERY page is a subsection of is utterly unfamiliar to many people writing content -- but if you are at all familiar with actual writing norms you'd know that's said level of heading's job, just like how at the top of every page or fold-pair in a book, newspaper, or technical document it's right there. Sure on the front page / cover it's bigger, but it's semantically/grammatically the same LEVEL of heading.
Which is why H2 indicate the start of major subsections of a page, with the first H2 being the start of the main content of the page. H3 indicating the start of subsections of the H2 before it, H4 being the start of subsections of the H3 before it and so forth... so forth down to H6. Just like how HR means "a change in topic or section" and not "draw a line across the screen".
... which if those headings and rules divide things into sections, why do we need a SECTION tag? If the first H2 is the start of your main content, why do we need a MAIN tag? If everything before that first H2 is the header, why do we need a HEADER tag? If everything after the last heading or HR is separate from what's before it, why do we need a FOOTER tag? If NAV means "this section can be skipped to get to the main content" why do we need HEADER, or MAIN, much less if the first H2 is the start of the content, why do we need NAV?
Don't even get me started about the 100% grade A derpitude that is ASIDE, where unless your doing nothing but transcribing the bard, or writing scripts for Ferris Bueller or deadpool, has ZERO semantic/grammatical business being in the code -- which is why the way people use it? Might as well go back to using FONT and CENTER tags since it ends up THAT "semantic". Which is to say not at all!
POINTLESS REDUNDANCIES. Which is why a LOT of developers will tell you code for 4 Strict, and deploy as HTML 5 for the handful of real improvements (like the tighter/cleaner HEAD area) and stuff shoved down our throats (VIDEO, AUDIO).
Akin to how SMALL does not mean "show this text smaller" it means "WOULD BE shown smaller for grammatical reasons such as de-emphasis" -- or how the italic tag doesn't mean "show this in italic" it means "would be italic for grammatical reasons like a book title that isn't being CITE'd or receiving EMphasis."
There's a reason the people who say NEVER use the bold or italic tags are basically talking out their collective arses! Kind of like those who say to never use tables and then add 20 div for nothing or abuse DL/UL nesting to show tabular data. Aherpaderp.
So their code's NOT the cleanest and for the places I do work for it would fall short on accessibility, efficiency, and usability grounds, BUT they do have some good information and their colour checking tool is quite handy.
It's certainly -- as you noticed -- far better than what people vomit up with bootcrap and it's endless pointless classes for nothing, endless pointless DIV for nothing, and little if anything remotely resembling an ATTEMPT at semantics or accessibility.
In general be warned there's a LOT of "extra code" people throw at things that serves little to no purpose either from a lack of graceful degradation, lack of user-agent support, or redundancy to simpler approaches. Hot, trendy, new, and shiny often end up taking precedent over what should be common sense. Those new HTML 5 structural tags and "Aria roles" being a stunning example of this in action.
See such facepalm worthy code as:
<button role="button">
It's like... wow, really? Whoddathunkit?!? Or the stupidity of setting role="menu" on a UL -- if we needed that level of semantics why was the MENU tag deprecated. Did you know there was once a menu tag? Actually it's back, but not for what it was originally created for -- in fact I can't seem to get a straight answer on what it's even FOR!
But what can one expect when we went from trying to eliminate redundancies in 4 Strict to not only introducing new ones in 5 (audio, video) but even going so far as to accept into the specification crap that was rejected in 4 Strict (embed, target) for a reason! Made all the worse by scripting only stuff that shouldn't even HAVE a bloody tag -- like CANVAS.
I like canvas as a JavaScript feature, however since it has no grammatical/document meaning, is not a neutral hook like DIV and SPAN, and only works when scripting is present it has ZERO business being a tag. Also implementation-wise it would be a hundred times more useful if it just rendered as any element's background-image.
This is rich. Another helpful pointer that I plan to take time learning. Now, I am wondering, though, do you have a set of recommendations specifically for HTML semantics as well, besides what you already wrote here and in your website? What do you often refer to when you are figuring out stuff like this?
The WCAG guidelines are a good starting point, but they're starting to age poorly. The number one source I suggest supplementing them with is the Nielsen Norman Group. Their articles are based on actual UX studies with actual people, instead of the wild guesswork and card-stacked lies so common elsewhere.
nnGroup is also utterly reviled by the fools calling themselves "web designers" whilst only knowing how to shove pixels around in Photoshop. Makes it a hundred times more credible in my book if they're pissing off those ignorant clowns who's lack of understanding HTML, CSS, JS, limitations of the medium, emissive colourspace, or accessibility norms leaves them qualified to "design" but two things -- and Jack left town.
nngroup.com
They have articles and research dating back nearly two decades, actual scientific papers with double-blind studies, and are one of the few places offering coursework that I would actually recommend.
Interpreting the language of the WCAG is also tricky as the language barriers common to all W3C creations gives it the feeling of having been written in swedish, translated to Japanese by a Russian, then google translated to what can only be described as "Engrish moist goodry, me love you long time."
The math of things like the legibility rules is also a bit off/akilter as normal people often don't grasp it, and things like font-smoothing (a technology that wasn't even in OS when the WCAG was created) mean to truly meet it you have to go by a screencap zoomed in of a rendered page and NOT the colours you declare in your CSS.
The math for me seems simple, but that's because I've worked directly with YCbCr implementations, and the luma for the WCAG rules is just Y.
Thankfully WebAim -- itself a fairly reliable source of advice:
webaim.org
Has a tool to help with knowing what levels of WCAG standard your fonts meet:
webaim.org/resources/contrastchecker
A quick rule of thumb is that with thin-glyph fonts -- like Google's DREADFUL "raleway" you should treat a larger size as "normal AAA" and avoid using it at "normal" sizes (16px / 1REM) or smaller altogether. Thanks to font-smoothing which blurs the bars and slabs on glyphs, you will end up more often than not having to treat normal text as needing to meet AAA at all times. It sucks but these technologies that improve the shape and form of the glyphs actually compromises legibility. Microsoft tries to address this with core fonts by hammering them into pixel boundaries, whilst Apple's answer is to make everything feel bold/blurry. Neither is actually a great answer on the majority of normal displays.
Though retina / hdx / high pixel density displays are slowly changing that, not everyone can afford that or is likely to want/need it any time soon. Particularly since even Joe Sixpack and Susie Sunshine continue to scoff at 4k as placebo instead of fact, waiting until they NEED a new display to take the plunge.
... and there will always be a place and platform for cheaper displays.
Likewise be warned that due to its age, it's easy to take parts of the WCAG out of context, like the part saying that pixels can be acceptable when user agent support for scaling override is present. What they are referring to is how Firefox USED to handle them Netscape 4 style, the IE7/earlier behavior, and how "classic" Opera's zoom/scaling worked which would actually override your layout styles if possible to maintain a working layout. As such that part can no longer be used as justification for declaring font sizes in pixels since neither UA behavior is still in common circulation. Not that it was ever justifiable given how IE dropped the ball when they moved to 8, firefox ditched it some time around 2003, and blink/webkit/khtml never supported it. -- That's why of all the sizes the WCAG says are usable for font-size, %/em is for screen, pt is for print.
BUT there are those who will read that same section and interpret it differently. They're quite shocked when prosecutors, civil litigators, and judges disagree.
Hence why I often joke "The WCAG says to use EM, so use 'em!"
But really, for ALL the things the WCAG says, 99% of staying out of trouble and being properly compliant can be achieved by:
1) Having proper semantics. Say what things ARE, NOT what you want them to look like.
2) Establish a logical document order where your H1 (singular) is THE heading that EVERYTHING on every page of your site is a subsection. H2 indicating the star of a major subsection of the page with the first H2 being the start of your primary content. (what HTML 5 added their pointless MAIN tag for). H3 being the start of a subsection of the H2 before it. H4 being the start of a subsection of the H3 before it... all the way down to H6. HR -- horizontal rule --even means "a change in subject or topic where heading text is unwanted/unwarranted" and NOT "draw a line across the screen"
All stemming from the fact that HTML tags are not for presentation, and if they seem to have presentational meaning that's because they represent what things WOULD BE for grammatical reasons in a professionally written document, and NOT "it must be shown this way". Particularly when many HTML compatible UA's are incapable of showing bold, italic, font-sizes, drawing lines, etc. A detail many people miss completely!
To that end I also suggest skipping past all the new HTML 5 tags that are SUPPOSED to provide that same functionality (pointless redundancy) that not one legitimate accessibility UA actually obeys. (making it toothless). That means do not waste your time on, or do not rely upon ARTICLE, ASIDE, NAV, MAIN, HEADER,FOOTER, or SECTION.
...and if you do use SECTION beware that it utterly screws up legacy support as the rules for using it 'modern' style means if you open SECTION you're now back to H1 depth. Basically under HTML 5 rules it's "start with H1 as your heading depth for each BODY or SECTION". End result being that headings other than H1 being correct/appropriate reaches near to zero. There's a reason a lot of HTML 5's die hard fanboys even suggest that SECTION should be axed.
In general those tags speak to having been made by folks at the WhatWG who never embraced HTML 4 Strict, read the WCAG, or grasped any of the core concepts of semantic markup. For all it's improvements, those tags I just outlined are if anything a step backwards to mid '90's methodologies undoing twenty odd years of progress. It's why some people will tell you "Code for 4 Strict, but deploy as 5 for the handful of advantages".
The same goes for that Aria role nonsense -- mostly redundant to semantics, mostly nothing more than code bloat, and few if any legitimate UA's do a blasted thing with them. That entire specification seems to have been created for the microformat junkies to have their own little corner to spank it in, and to satiate the wants and desires of "data scrapers"... or if we were to refer to them by their proper name, CONTENT THIEVES!
... and of course neither are listed in the WCAG as they're too new, and it's so old. Also I wouldn't plan on seeing the WCAG updated in our lifetimes given many top names at the W3C hate it because it has hard strict rules that clashes with their
Aka the type of people you might actually want to keep OUT of your website. You want that type of data passing, set up a REST service and stop trying to use HTML to do things it's not designed for.
Moving on.
3) Elastic layout. Declare EVERYTHING possible in EM's. That means margins, padding, font-size, line-height, and your media query breakpoints for responsive design!
4) Semi-fluid layout. Aka having a max-width so long lines aren't hard to follow.
5) Responsive layout -- whilst so new the WCAG doesn't even mention it, maintaining a useful layout prevents OTHER parts of the design from creating new violations.
6) Scripting off/blocked functionality -- I'm not saying don't use JavaScript, JS can be applied in a compliant manner. But if your page's base functionality and usability goes bits-up face-down when JS is blocked/unavailable, you ARE in violation under most LEGAL interpretations.
7) Graceful degradation -- every care should be taken so that if newer bits of the specifications (like JS, CSS, or HTML) are missing, or if specifications like images, media, CSS and JS are blocked / unavailable / inapplicable, you are still delivering a useful and useable website.
Which is why I'm endlessly advocating the progressive enhancement development approach.
You do those seven things, and you are close enough to compliant that NOBODY will nitpick any of the other details. In most jurisdictions if you have those simple things, it's your get out of jail free card.
Now think about how many of those things the majority of off the shelf templates and HTML/CSS/JS frameworks fail to deliver on, or worse outright INTENTIONALLY seem to want to piss all over.
You may enjoy a few of my own articles on the topic of progressive enhancement since it relates to meeting these norms.
cutcodedown.com/article/progressive_enhancement
My article on "what's wrong with YOUR website" is starting to age like milk, but still has some key insights that go above and beyond what the W3C offers.
cutcodedown.com/article/whats_wrong_with_YOUR_web…
That help any?