Hacker News new | past | comments | ask | show | jobs | submit login

I feel like Bootstrap (and similar) are a lot "to blame" for some of these.

People have been using HTML tags non-semantically for a very long time and, to be honest, before HTML 4 you often didn't have a lot of choice in the matter.

Still, when I was getting back into web development in 2013 I became aware of an "I can just use <div> and <a> for everything, and then stick Bootstrap classes and event handlers on to get it to look and behave the way I want" attitude that had become pervasive amongst developers.

Now, to be fair, at the time this was legitimate: in 2013 older versions of Internet Explorer were still quite prevalent. They didn't support newer HTML5 constructs, or proper styling of certain elements. The <div>/<a> approach was often the only way to get things to look good, or even to look the same, across all browsers.

Those days are long since gone (for most of us, anyway[1]), but I wonder if the reason we continue to see this style of HTML is that we're still living in a sort of post-IE hangover period? Old habits die hard[2].

[1] I'm aware that even now not everybody has the luxury of pretending that IE doesn't, and never did, exist.

[2] Again, reminds me of the migration from earlier versions of HTML, where you'd really had to do things like use tables for layout and use various HTML elements for styling (with variable cross-browser support), to HTML 4, where you nominally didn't (except, of course, that not all browsers were created equal).

When i started working web IE6 was still far far in the future, i also learned the semantic use of html JADAJADAJADA table-layouts bad JADAJADAJADA and i most of the time enforced myself to apply this 'best'-practices - truth is - i never saw this providing value in any kind. The web is so full of shit and abuse of 'best'-practices - nothing will every really on this and work. I would often have saved myself and my clients a lot of headaches/time and money if i had just used table-layouts instead of css-layouts and other crap - but hey whatever 'float's your boat.

I believe you mean "yada yada" instead of jadajada?


Perhaps in their native language a J is sometimes/always pronounced like an English Y.

Why are people down-voting an honest and helpful suggestion?


Can we stop producing the -splaining words and roll back the ones already shipped.


I would consider correcting someone politely as being helpful. We are all here to learn.

thanks, captain :)

The benefit is for people who need assistive technologies to browse the web. If you don’t know anyone who needs assistive technologies, then of course you wouldn’t see the benefit.

Nope... how would someone have used (with assistant technology) the web back in the day if that would break it. You have to do some extra work for a good user experience, for these users anyway - so i don't take this as an argument ( as i said - if a screen-reader or other tools would fully relay on html-semantics to work - it wouldn't work).

> Nope... how would someone have used (with assistant technology) the web back in the day if that would break it.

This is begging the question! You start with the assumption that assistive technologies can handle table-based layouts well, and then work backwards from the conclusion that you’re trying to prove.

It may shock or surprise you, then, to learn that in actual fact, table-based layouts caused problems for screen readers (and still do, if I am not mistaken). There are a number of other ways that websites break screen readers, and the difference today is that (1) table-based layouts are hardly necessary or even popular these days and (2) more people are suing over ADA violations for inaccessible web pages.

The screen-reader tools do not fully rely on HTML semantics, but they do need some logic to differentiate between tabular content and purely presentational <table>. The reason for this should be fairly obvious once you look at any actual web page—when you navigate tables, you want to go by columns and rows, but if you are reading a table used for layout, you probably just want to flatten it and go through the entire thing in linear order (more or less). The process can be disorienting for people with screen readers if your site is poorly designed.

Of course, if you just make assumptions and guess about how screen readers and assistive technologies work, there is a good chance that your guesses are wrong.

Well, i don't use table layouts knowadays too - i didn't go into details about screen-readers, as the styles i usally apply for those are more similar to the printing stylesheets, hiding most design-elements -displaying the content more in a document-format, adding special screen-reader navigation, like goto-navigation/content etc. created a website for a 'disabled home' ( is this correct word ) - which was mostly used by the patients there, had some vision impaired ( not fully blind i think), but mostly spastics using various input-methodes ( keyboard, joysticks and some software ) and it seemed to work pretty good. What i meant in my first comment was purly targeted at the semantic meaning of html-elements.


> I feel like Bootstrap (and similar) are a lot "to blame" for some of these.

IMO, it's more about developers just using Bootstrap without reading the documentation. The examples are pretty well done, they use semantic elements and are accessible.

For example, the Navbar[1] element has a good HTML structure and uses `aria-label`s that announces what's going on to assistive technologies.

Another one is the modal example[2], it has semantic elements, the `tabindex="-1"` attribute to make it accessible to keyboards and the correct use of the `aria-label` as well.

So, their documentation pretty much teaches you how to use it correctly. I'm not a fan of Bootstrap myself, but I think throwing the blame at it is unfair.

[1] https://getbootstrap.com/docs/4.3/components/navbar/

[2] https://getbootstrap.com/docs/4.3/components/modal/

That shift happened in bootstrap 4, bootstrap 3 was <div class="..."> everywhere. Also 3 was when bootstap was really big.

Good to see they improved, i guess :-)

That shift happened in Bootstrap 3's lifetime. The 3.4.1 navbar markup [1] and 3.3.7 navbar markup [2] is very similar to 4.x, but most of the semantic stuff and ARIA stuff is missing in 2.3.2 [3].

(I probably paid a lot more attention in 3.x documentation than most because of the mistake in a past life of forking Bootstrap 3 for an enterprise project and trying to keep it in sync with upstream. Never again would I consider doing that.)

[1] https://getbootstrap.com/docs/3.4/components/#navbar

[2] https://getbootstrap.com/docs/3.3/components/#navbar

[3] https://getbootstrap.com/2.3.2/components.html#navbar

> They didn't support newer HTML5 constructs

I am pretty sure at least as old as IE6 it was really simple to enable the newer HTML5 constructs via JavaScript (leading to small libs like HTML Shiv). Just a couple lines of JS to tell the browsers the element(s) exist, via document.createElement("blah") enabled the elements and allowed styling.

Oh my... HTML Shiv ( These are the old days man, the bad days, the all-or-nothing days. Marv ) - as far as i remember i still prefered to not relay on js back then - browser support/broken implementations where just spoty/common - also lot's of users/browsers would have js disabled. Only for using an attribute-selector in your css ( which you shouldn't if possible ) i thought that was to much overhead

That's true, but these polyfills weren't necessarily perfect. E.g., IE7 or 8 (I forget exactly which version - it's a long time ago) not supporting rounded corners on buttons.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact