I like the design, but semantics and accessibility aren't great.
We have lists implemented like divs, navs like divs, lack of appropriate attributes, aria labels and few other things.
That's not great considering there's basically only static content without interaction.
Articles speaks about optimizing for performance but will still attempt to load 150kb of analytics library and doesn't handle fallback fonts and font rendering properly. What's the point of obsessing over bundle size when you will still shove fonts and analytics when loading the application?
In every one of my projects I always try to convince stakeholders and designers that they will find fonts that will be great among the system fonts and that it won't be that much of a difference to users generally (there's plenty of successful enterprises and top 50 websites out there that only use os fonts and make $$) and what I get are poorly implemented fonts with inconsistent heights and vertical positioning across different OSs.
And the irony is that since most of your company runs the same OS (MacOS) where this issue is not visible it's like it doesn't exist.
> We have lists implemented like divs, navs like divs, lack of appropriate attributes, aria labels and few other things.
I see content organized into sequential, distinct blocks of text which include multiple paragraphs— LI elements are block-level and can contain multiple paragraphs. There's no semantic problem here and no accessibility problem. In HTML5, for accessibility purposes, divs should be used for presentation only. They have no semantic meaning. Lists do.
> Articles speaks about optimizing for performance but [...]
Agreed, mostly.
> they will find fonts that will be great among the system fonts
Having sane fallbacks in your font stack is important, but that statement is false and is why developers don't make those decisions. That's fine— it's not your job— but even as a long-time developer I won't tell developers how to do their job if I'm serving in a design role on a project.
I was also as a culinary school trained chef. Many insist salt omitting salt and letting diners salt food themselves yields equivalent results. Obviously, health conditions should be accommodated for, but in most senses, they're provably wrong. We perceive most of "flavor" through our noses. Tongues sense few things but stimulating it focuses our brain on smell. Totally integrated seasoning drastically intensifies the overall flavor of food. Salt is also chemically and mechanically important in many processes, such as searing. I'd say 60% of professional polish in food comes from proper seasoning.
Design details are like seasoning. A famous designer said "the details are the design". Users don't consciously perceive those individual details but they have tremendous impact on a whole. Even people without experience, however could easily understand the difference between a title set in the 'Display' style of a Pro version of a font vs the standard paragraph version. Setting paragraphs type in the display version of a font makes it much less readable. The visual impact of properly tuned kerning pairs alone gives the pro version of a font a ton more polish. Even different versions of Helvetica have drastically different quality. Target, one of the most savvy businesses on the planet, developed their own version of Helvetica at tremendous expense. They didn't do that on a hunch— they had good reason to believe they'd recoup their expenses by doing so.
> We have lists implemented like divs, navs like divs, lack of appropriate attributes, aria labels and few other things.
Since I don't use accessibility tools: how big of a deal is this for people who do? I try to keep my personal website lightweight, but I think I also use `div` for almost everything.
Theoretically, screen readers handle the "semantic web" better than anything else. Divs are used for layout and presentation, and don't convey much useful information about structure most of the time, so div-heavy sites can be really hard for blind people even if they look great, clean, minimal, and simple for the sighted.
I say "theoretically" because I'm not blind and have never used a screen reader, and I'm not extremely experienced in the area.
For this particular website the impact isn't tragic, you can navigate, but you cannot navigate efficiently nor you can figure out well what and where you're navigating to.
In short, it's usable but not perfect, the sidebar should be a nav rather than a div to convey it's where major and meaningful navigation is found. It's not easy to figure out without the visual feedback that those links are different than the others on the website.
There's also lack of a "skip to content" and similar menus that would help into consuming the content. The dialog popups also lack the same usability, they would benefit of clearer aria-labels on the links.
Anyway, I don't think it's a tragedy, again, it's usable, but given that the author lists accessibility as one of its 4 rules and yet it's not really a pinnacle of accessibility, despite the lack of dynamic content and interaction is not great.
> the sidebar should be a nav rather than a div to convey it's where major and meaningful navigation is found
I think you are mixing two issues here, what's good for the end user and what's good for the developer and maintenance of the site. Both matter of course greatly but I think this article was about optimizing the user-experience.
From the users' point of view does it matter if a section is a 'nav' or a 'div' which has CSS-class 'nav' assigned to it?
> From the users' point of view does it matter if a section is a 'nav' or a 'div' which has CSS-class 'nav' assigned to it?
Yes.
There are people that use devices that rely on these accessibility options to differentiate nuances in the content that might otherwise be obvious when rendered in a standard browser: text only browsers, screen readers to name just a couple.
That's a good point and I think nav is a great idea, especially for maintenance reasons. Most users won't see the difference. But some will hear the difference.
> We have lists implemented like divs, navs like divs, lack of appropriate attributes, aria labels and few other things...Articles speaks about optimizing for performance but will still attempt to load 150kb of analytics library and doesn't handle fallback fonts and font rendering properly.
I'm not sure what you mean by 'lists implemented like divs'. My lists are good old <ul>/<ol>, as God intended.
The fallback fonts and font rendering are also implemented correctly AFAIK: we use a high-quality Adobe FLOSS font, we swap fonts for performance, and we have a full fontstack which falls back through all of it down through system to a last-resort.
The analytics is also super-useful for me. I use it all the time for finding broken links, discussions, making design choices about device screen size, etc. I do not regard it as wasted at all.
A lot of the WAVE stuff you refer to is things I neither can nor would fix, so gwern.net is never going to be the pinnacle of what you consider accessibility. While none of it is quite as stupid as when accessibility people were telling me to not use hyphens because screenreaders, 20+ years later, still are unable to delete soft hyphens (and this is somehow my fault and I should break hyphenation for 99% of readers), I raise my eyebrow at the claim that justified text is an accessibility problem; and when it flags PDFs, I can only shrug - yes, and I would like a pony too, but that ain't happening either.
I've switched the two navbar divs to <nav>s, and added a skip-to-content link. I also ran it through WAVE and fixed a few things. (I did a long time ago but there's been a lot of changes since then. I've added a cron job to check it again every few months.)
> The dialog popups also lack the same usability, they would benefit of clearer aria-labels on the links.
We have lists implemented like divs, navs like divs, lack of appropriate attributes, aria labels and few other things.
That's not great considering there's basically only static content without interaction.
Articles speaks about optimizing for performance but will still attempt to load 150kb of analytics library and doesn't handle fallback fonts and font rendering properly. What's the point of obsessing over bundle size when you will still shove fonts and analytics when loading the application?
In every one of my projects I always try to convince stakeholders and designers that they will find fonts that will be great among the system fonts and that it won't be that much of a difference to users generally (there's plenty of successful enterprises and top 50 websites out there that only use os fonts and make $$) and what I get are poorly implemented fonts with inconsistent heights and vertical positioning across different OSs.
And the irony is that since most of your company runs the same OS (MacOS) where this issue is not visible it's like it doesn't exist.