I've been looking into accessibility in web-design a bit lately and one of the things that keep popping up is to use semantic HTML. As long as you design your web-pages well, accessibility should be fairly good.
Firstly, one thing that is worth remembering about accessibility is that is for everyone. If you have information on a website, and you want people to be able to access it, it should have good accessibility. How many times have you tried to find some specific information on a fancy corporate site, spending 15 minutes or more on something that should be easily found? All to often the access to information is secondary to the graphical design of the website.
The History of HTML
Accessibility as a whole is a huge subject, but the part I'm going to talk about in the post is the structuring of the HTML. To understand the subject well, some history might be in order. HTML (or HyperText Markup Language) was originally designed to display information. The original design envisioned web-pages to be like encyclopedias or scientific articles, graphical design was secondary. And from the W3Cs (World Wide Web Consortium) standpoint, I believe this is still how it is viewed. But of course almost immediately people stared to do graphical layout with HTML. In the beginning you really had to be creative with different elements to get fancy graphical pages, people did horrible nested table layouts. At one point CSS (Cascading Style-Sheets) were introduced, with the hopes that the HTML could represent to information, and the style-sheet would define how it looked. But CSS was still not very flexible in manipulating elements, so web designers created multi level div wrappers and other tricks to style their content.
The whole thing has for a long time been a battle between two conflicting philosophies. The standards body has been trying to keep HTML purely as a informational language, and web designers are trying to use it as a layout language. This has in my opinion been very counterproductive, because there's no reason why both couldn't be achieved.
What is Semantic HTML
So what is this Semantic HTML that people keep talking about? In short it's HTML that describes the purpose of the information contained in it, instead of describing the form it will take on the screen. The advantage of it is that it makes it easy to read for people and software that don't see the screen in the same way. HTML version 5 was designed completely with this in mind. It added a lot of elements that were visually identical to the "div" element, but added information about what the element contained. Like "header" for header information, "main" for main content, and "nav" for navigation. There are other ways of doing this, like using the ARIA (Accessible Rich Internet Applications) attributes, but semantic HTML5 should always be the main way of signaling function.
Responsive Frameworks
With mobile now being a huge part of the web, web designers started looking for an easy way to make content look good on different screen sizes. Frameworks like Bootstrap and Foundation became popular. These are mostly CSS styles that have ready classes you can apply to elements that make them look and behave a certain way on different screen sizes. This approach has a big fundamental problem. It returns to the days of old where you did layout in the HTML file. This in itself might not always be a problem, but it lead to a backward way of thinking about things. Say for example that a web designer wants to create one menu layout for the desktop version, and another one for mobile. But the different layouts don't have the information in the same order. Since the layout is done in HTML, the designer must create two different menus, and hide one or the other depending on screen size. For the standpoint of screen-readers or software that try to parse the information on the page, this is a disaster. If you are using a browser that doesn't parse CSS files, your menu will show twice. From a maintainability standpoint, this is also bad, as a change to the structure would have to be made in two places.
Designing Semantically
But the backwards thinking regarding responsive frameworks is mostly problematic when it comes to the broad strokes. And this is where the biggest adjustment comes in. Very often, when implementing a design, the web-developer is given a layout as a photoshop file or something similar. The layout is then converted into HTML, CSS and image files from the viewpoint of that graphical layout. The end goal is of course to make the finished product look like the graphical layout, but my argument is that the web-design should be implemented "content first". This doesn't need to be the final content, because having the copy for the text at this point is a rare luxury. But there should be some basic idea of what kind of content there will be. This content should be marked with HTML tags that explain what it is. Like <main> for the main content, <aside> for info boxes and so on. Extra <div> wrappers and such should be avoided as far as possible, but for some things they are still needed.
CSS
As I hinted to earlier, the W3C has had the viewpoint that neither HTML, nor CSS is designed for creating graphical layouts with, but they are only for styling content. This seems to have changed a bit recently with the new (post version 2) CSS standards. Some of the more recent additions are "flex" and "grid" properties, as well as many properties used for styling images, and text flows. Using these new properties, as well as some "hacks" using well documented (and standard) side-effects can usually get you most of the way there in order to style a purely semantic HTML page with just CSS. And if some parts of the graphical layout can't be implemented 100% with CSS, you may consider if it's important enough to change the HTML just to implement it, or if a partial implementation is enough. Remember that using Javascript to add elements to the DOM in order to style is usually even worse than modifying the HTML directly. It doesn't help screen-readers or other parsers unless they don't run Javascript, and this is not something you want to count on.
Conclusion
There's no easy solution when it comes to designing semantic HTML. In many cases it requires a completely different way of looking at the whole process of designing a web-site. It's also not something you can retrofit onto an existing theme. But it is a thing that's fairly important going forward. Arguably it has been important quite a long time, but it has not quite been feasible to do before to the degree it is now. The new regulations are also coming up that mandate a certain amount of accessibility for some web-sites, and it would be good if accessibility would not be one checkbox that you get to once the rest of the site is finished, because at that point, the result will not be good.