Don't get me wrong, I used to write as semantic HTML as I could; nav for navigations, table for table's, aside for well asides, etc as the author suggests, but ultimately it just really doesn't matter. nav and div render exactly the same. In fact, I find zero value in using ul/li's for lists that aren't bulleted. I know it's an unordered list of items, but really, what _is_ the value in writing semantic HTML if the devs/browser/users don't care or know the difference? Especially if you're changing the "semantic" element's default behavior in order to get a look and feel or behavior that is far from the original "semantic" intent.
This comment amazes me, I understand that I'm fairly old but I thought that around 2008 we got people away from using nested tables for layout to using semantic HTML + CSS because of accessibility (for humans accessing with different devices but even machines). I guess like the article says:
> Don’t forget that there is always someone new into the world of design and development. Hopefully this post steers others towards keeping HTML code semantic and clean.
Perhaps it's time to start linking to old A List Apart articles?
If you use semantic HTML you get a lot of accessibility for free, since screen readers etc. all speak semantic HTML.
That doesn't mean you can't write accessible web applications without semantic HTML, but it does mean you have to spend time adding the accessibility after the fact.
I mean you can, off course, write accessible HTML without semantic HTML. Just remember to:
* Set the correct aria attributes and roles for assistive technologies.
* Make the correct elements focusable, and order the focus correctly between elements, and add a specific style when then element is in focus.
* Capture the focus when appropriate but still allow focus to the URL bar.
* Set the correct key event handlers for keyboard navigation, submit events and triggers, validation events, etc. for assistive technologies, etc.
* Be prepared to warn users that your site will not work without javascript or in reader modes or in text based browsers, as well as make your site somewhat inaccessible for bots and crawlers.
And I’m sure I’m forgetting something. Point is, it is possible, but really hard.
Ever tried to use your pages with a screen reader? It's quite an interesting (and potentially maddening - screen readers are power-user tools, and quite difficult to get into if that's not how you normally operate) exercise.
I tried doing this once, and I wasn't even able to install the damned thing. If you've got any advice or instructions on how to get started with a screen reader for testing purposes, I'd be really interested.
On Windows I tried NVDA and the demo version of JAWS. Installation worked without issues for me, and I looked for tutorials on how to use them/put up the keyboard shortcut overview. Sorry I can't point you to anything more specific right now.
I thought this as well until a recent project needed to meet WCAG or whatever the requirements are called for accessibility... in those cases using the "standard" tags can save a lot of headaches in trying to make sure a screen reader knows what's going on with the page...
I think quite an important bit missing in sibling comments is web browsers and setups (in addition to screenreaders) other than the most popular ones. If an HTML document is composed as a document (i.e., using semantic markup, instead of focusing on exact visual representation), it has a decent chance to be usable in textual and lightweight browsers, and to look decently in mainstream browsers in a few years as well.
To get an illustration, one could browse WWW in such a browser (w3m, links, lynx, netsurf, etc), or even in FF with customizations, and/or browse web.archive.org (particularly websites from a decade or two ago) using a mainstream browser: basic HTML pages tend to be nice and accessible, while the ones using graphics, CSS (possibly optimized for 1024x768 or a similar resolution), and Flash/Java/JS/etc are usually a pain to get information from. I think most of the contemporary websites would produce a similar impression in another decade.
Another example where semantic markup matters is conversion into other formats.
Accessibility is one reason. A web page may Visually look the same regardless of which elements you use, but it may be treated very differently to screen readers used by visually impaired people.
Using semantic HTML also helps search engine crawlers and other automated software understand the structure of your pages.
> ultimately it just really doesn't matter. nav and div render exactly the same.
More precisely, they render the same in common visual user agents.
It turns out the semantics can be distinct for other kinds of user agents. Accessibility is one context that matters. Intermediate UAs like search engines are another. Maybe voice browsing is going to take off with virtual assistants.
