[HN Gopher] The right tag for the job: why you should use semant...
___________________________________________________________________
The right tag for the job: why you should use semantic HTML
Author : tmfi
Score : 109 points
Date : 2021-06-06 16:26 UTC (6 hours ago)
(HTM) web link (localghost.dev)
(TXT) w3m dump (localghost.dev)
| aimor wrote:
| The better control I have over styling the more empowered I feel
| to use semantic HTML. It was frustrating, years ago, to jump on
| board wide eyed only to realize that styling is a minefield. I
| believe this is much improved today.
| coldtea wrote:
| I don't see any reason to use semantic HTML. It's cargo cult.
|
| At some point web designers (at the time in the early 00s web
| development was not as involved as it has been post Ajax) learned
| the term "semantic" and went wild with it (made you sound smart,
| and you could charge a little more than the unsophisticated shop
| down the road), without understanding the science behind data.
|
| Instead we should have separation of concerns, with structured
| raw information (you know, like what we have in our relational
| and document databases), served with different represenations:
| for accessibility, for data access, for web, for syndication, for
| print, for reading devices, and so on.
|
| Of course the web being the web, it needed to make this too in
| the most inefficient and multi-layered way (and leave it up to
| the web designers/devs to have "proper" semantic tags).
| chrisjshull wrote:
| For all those saying that ARIA trumps semantic elements, consider
| that for basic interactions semantic elements come out of the box
| keyboard accessible.
|
| For example, a <button> will have default tabindex=0 and respond
| to spacebar key presses, but you'd have to add that yourself if
| you put role=button on a <div>.
|
| In short, if there is a semantic element that matches your need,
| use it.
| extra88 wrote:
| > In short, if there is a semantic element that matches your
| need, use it.
|
| Yes! This is known as The First Rule of ARIA.
| admax88q wrote:
| If the browser would make the semantic elements actually look
| good out of the box a lot of developers would use them by
| default.
| pjc50 wrote:
| Isn't that an extremely moving target? What looks good is
| very subject to changes of fashion.
|
| Your comment below about being difficult to style is more to
| the point.
| anoncake wrote:
| Unfortunately, Firefox recently actually stopped making
| semantic elements look native (=good).
| JoshTriplett wrote:
| If people could agree on what "look good" means, I don't
| think it'd be impossible to get the major browsers to update
| default styles. But every site seems to have a different idea
| of the look they want.
|
| I'd be curious to see a somewhat-objective look at what's
| actually wrong with default browser styles, separating out
| well-established usability and design considerations from
| personal preferences and branding preferences. I wouldn't be
| at _all_ surprised if there are near-universal things wrong
| with the default styles, and those might be possible to
| change if they can be separated out.
| Swizec wrote:
| Based on my experience as a web developer working with many
| designers over some 20 years of design trends, here's the
| problem:
|
| Default styles aren't pretty.
|
| That's it. They're superior in every other way. You always
| know what to click, you always know what an element will
| do, how it behaves, the UX is consistent with your OS, etc.
| Default elements are fantastic.
| robin_reala wrote:
| Who cares about looking good, when we're talking about
| working good?
|
| Of course, it's worth putting the effort in to both looking
| good _and_ working good, but if we're going to pick one, we
| should go for the second.
| worik wrote:
| I think that is a false dichotomy.
| shadowofneptune wrote:
| It would be equal effort to restyle something done with ARIA
| compared to a semantic element, yes?
| admax88q wrote:
| Depends on the element, the select and input elements are
| notoriously difficult to style, which is why people often
| remake them with divs and JS.
|
| Combo boxes are a fucking nightmare to style, as are
| checkboxes and radios. Buttons arnt as bad, but you still
| spend a lot of time fighting against browser defaults which
| differ across browsers.
| tanaypingalkar wrote:
| You can reset your css
| lolinder wrote:
| For some elements, yes. Many others have certain attributes
| that are completely unstylable, a lot of browser-specific
| attributes and selectors (not just prefixed attributes but
| also whole pseudoclasses), or both.
| throw_m239339 wrote:
| CTRL+F "microdata": no result. Yeah, I thought so too...
|
| The Semantic web has failed. ARIA tags are important for
| accessibility though, but semantic HTML has been irrelevant for a
| decade, I haven't seen a single successful product based on that
| or a single use case that yielded something interesting SEO wise.
| extra88 wrote:
| Using semantic HTML in web authoring is not the same as the
| concept of the "semantic web" [0].
|
| The article makes it clear what it is about and it's not about
| the goals of the semantic web.
|
| [0] https://en.m.wikipedia.org/wiki/Semantic_Web
| chipotle_coyote wrote:
| The article, and the comments on the article here, and even the
| ARIA documentation itself as quoted in comments explain why
| semantic HTML is important to accessibility. "Yeah, but it
| doesn't yield something interesting SEO-wise" leads us to make
| web sites that are trash fires, and not just from an
| accessibility standpoint.
| [deleted]
| eyelidlessness wrote:
| Oddly, I had to use microdata to fix reader mode on my site
| recently.
| crazygringo wrote:
| It's very unfortunate that the term "semantic" is overloaded --
| the "semantic" web you're referring to which I agree was
| basically a total failure, but also "semantic" HTML which is
| used for accessibility, essentially as a shortcut for ARIA
| tags.
|
| I think it's led to a lot of confusion, especially since it's
| often not clear which purpose is being referred to in a
| context.
| worik wrote:
| "semantic" is not overloaded in this case. It has the same
| meaning in both cases
| ctoth wrote:
| Semantic HTML != ARIA tags.
|
| Also, isn't the semantic web the reason that we get things like
| link previews with titles and content and images and...
| Considering [0] is a SEO website, and it was in the top three
| for my search for og:title I'd say the problem is rather that
| SEO infected the whole thing, not that it's not useful to SEO.
|
| [0]: https://seosetups.com/open-graph/
| runawaybottle wrote:
| Oddly enough, I think semantic HTML might be more important for
| React developers than anyone else. React developers are very
| vulnerable to creating copious amount of abstract components due
| to the freedom composability gives you. Over time, it's possible
| different people literally speak different languages (even in the
| same codebase) because of how they see the structure of tags.
|
| Thinking in Semantic HTML might help normalize the variances.
| jeroenhd wrote:
| I've run into some bugs because of composition, something about
| <a> tags nesting breaking everything, but only in release mode
| (minified etc.). Not fun to hunt down. I don't remember the
| details, but I've also seen warnings about other semantic stuff
| that's enforced (it at least complained about) by the
| framework.
|
| Technically you could make everything a div or a text element,
| but most frameworks you use come with certain expectations: the
| closer you are to using semantic tags, the less likely you'll
| be to violate those external expectations.
|
| If you're not using any frameworks, I don't see why you
| wouldn't use semantic tags by default. Sure, you can override
| the onclick if an anchor with no href and call preventDefault,
| but why not just use a button instead?
| brutal_chaos_ wrote:
| Protip:
|
| Semantic HTML != Semantic Web
|
| Accessibility is important, learn this stuff!
| drummer wrote:
| Excellent article thanks for sharing
| Animats wrote:
| Here's Google's test page for "canvas rendering".[1]
|
| Try that with a screen reader.
|
| [1]
| https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
| willeh wrote:
| Most of the heavy lifting in accessibility is in the ARIA
| attributes and being thoughtful about actually including those.
| The problem faced by semantic tags is that not all websites use
| them and that the information that they carry is of very limited
| use for a screen reader. A section-element without any other
| information is just a div.
|
| Unfortunately adding semantic information to website has gone
| from a promising avenue for building websites usable from many
| different kinds to part of the SEO cat-and-mouse game played by
| Google et al.
|
| Unless you're doing SEO, everything semantic is just a
| distraction. That said do take accessibility seriously, it will
| never be justified by profits but doing the right thing is a
| feeling no amount of money can buy.
| wwweston wrote:
| > Unless you're doing SEO, everything semantic is just a
| distraction
|
| Accessibility and SEO are (usually) desirable system effects
| that rely on meaningful semantic code-inputs to the system.
|
| But that doesn't mean that only software system effects matter,
| and everything else is a distraction.
|
| Consider that when you're programming your various identifiers
| -- the names of variables, functions, classes, types that you
| choose -- are largely without any semantics to your system. To
| the computer, they're simply keys. And yet we sometimes say
| that one of two the hard/important problems in computer science
| (besides cache invalidation) is naming things. Why?
|
| Because the _actual_ system isn 't just the software & machine.
| The system includes the developers groking and shaping the
| software. And names and their relationship with domain concepts
| matter to people and help them manage their work.
|
| I've found that the _first_ benefit to semantic markup -- not
| necessarily the most important, but the first -- is helping me
| better conceptualize the domain and my code. It functions as an
| orientation anchor when I 'm working with components that look
| different between their source and rendered as part of a
| sprawling document in the browser. And it helps me get
| reoriented faster when I've been away from it for
| days/weeks/months.
|
| The heart of "semantic" anything is the idea that code is for
| people too. Maybe not all people, but definitely at least
| anyone who's writing it.
| eyelidlessness wrote:
| > Most of the heavy lifting in accessibility is in the ARIA
| attributes and being thoughtful about actually including those
|
| This isn't true. Semantic HTML is also very important, often
| more so.
|
| > Unless you're doing SEO, everything semantic is just a
| distraction.
|
| This is also not true. Besides actively harming accessibility
| (or making it substantially more difficult to improve), non-
| semantic HTML also breaks Reader Mode. And it can also add
| cognitive burden to maintenance and future feature work.
| pjc50 wrote:
| Since reader mode is often "no annoying ads" mode, I'm
| wondering when sites are going to start breaking it on
| purpose.
| plorkyeran wrote:
| Reader mode probably has a pretty low impact on ads. The
| full page is usually going to load before you activate
| reader mode, so the only ads it's actually hiding from you
| are ones below the fold, which are much lower value to
| begin with.
| lolinder wrote:
| Yes, but at some point advertisers have to realize that
| people who use reader mode don't actually see the ads.
| The ads might load, but the user is just staring at the
| reader mode button waiting for it to turn on.
| goto11 wrote:
| > That said do take accessibility seriously, it will never be
| justified by profits but doing the right thing is a feeling no
| amount of money can buy.
|
| Why can accessibility not be justified by profits? If you sell
| something, lack of accessibility will cause you to lose sales.
| How much you will lose depends on the demographics of the
| potential customers.
| richardwhiuk wrote:
| Cost of ensuring a site is accessible is greater than the
| profit from the sales which you get in addition?
| ctoth wrote:
| For what kind of site? If you just use semantic HTML as
| this article recommends, the cost is quite low for
| development, and your QA people should already know the
| basics of accessibility testing.
| goto11 wrote:
| Yes but what is the the cost of accessibility? How much
| more expensive is it to use a <button> compared to a <div>
| with attached event handlers?
| open-source-ux wrote:
| > "Most of the heavy lifting in accessibility is in the ARIA
| attributes"
|
| Best practice is use to use HTML semantic tags and only add
| ARIA attributes if it is relevant. For example, HTML5 has a
| <nav> tag, therefore it is not necessary to add the ARIA
| attribute "role=navigation". Even the Accessibility section on
| MDN (Mozilla Developer Network) states: " _developers should
| prefer using the correct semantic HTML element over using ARIA
| if such an element exists_ " (Source:
| https://developer.mozilla.org/en-
| US/docs/Web/Accessibility/A...)
|
| > "The problem faced by semantic tags is...the information that
| they carry is of very limited use for a screen reader."
|
| That's precisely why those semantic HTML tags are important -
| so that screen readers navigate the page more easily (among
| other reasons).
|
| > "...semantic is just a distraction"
|
| Accessibility is not difficult if you follow HTML5 semantic
| markup. Compared to CSS, HTML5 semantic tags are _easy_. If you
| use HTML5 semantic tags, accessibility comes built-in - you get
| it for free.
|
| Where accessibility fails is when you're using a JavasScript
| framework that generates non-semantic markup. Or you're using a
| CSS framework and your HTML markup is littered with endless
| <divs> rather than HTML semantic tags.
|
| I recently posted this video playlist of quick accessibility
| tips for websites (each tip is just 1 minute). Many websites
| don't follow these best practices. However, I think people
| might be surprised by how simple and low-effort it is to
| incorporate these tips into any website.
|
| _Quick accessibility tests_ :
| https://www.youtube.com/playlist?list=PLTqm2yVMMUKWTr9XWdW5h...
___________________________________________________________________
(page generated 2021-06-06 23:00 UTC)