>>41
legacy a11y software. this is my experiencing adding a11y feature to a large web based education technology solution: outside of u.s. there's a lot of national packages that are either stuck in pre html5 world, or else they've long adopted a strategy of mistrust, so html5 semantic is bolted on as a hint system, rather then "semantic first". a lot of a11y software sees the world through lynx-like eyes, rather than semantic web.
a11y software not trusting web developers. and for good reason, nerds are good at ocding over taxonomies ("i put <article> in <section> and there's a <summary>, i just orgasmed at how neat everything is"), but then fail to run the page through a screenreader. and we're talking about well-meaning people, nefarious agents might stick html5 elements, because pagerank will somehow go up, or to misdirect bots, or whatever.
semantic mismatch. html5 has incomplete, arbitrary and very much "we came up with this during a meeting" ontology, which fails to represent wide range of web experiences. there's no entities for text boards for example, there's no "post", etc. there's uncertainty about scope. what does "author" apply to for example? containing "article"? the whole page? the effect of this ontology on screen readers can be only partially reasoned from spec (you basically reason back from ARIA), so you have to run your app through a bunch of readers anyway and see the effects. and then you have a constant push/pull between "visual intent" and "semantic intent", and without your developers being constantly aware of the need for later, the later suffers. this subject has been discussed to death.
what we discovered works best is basically to go ARIA first: we encode intent (using our own ontology, expressed as react elements), which is then rendered into tagsoup with aria attributes. "navigation" role (nav in your example) requires more treatment than just "plop it here". it requires further extensive annotation as to order, labels, details, actions, etc of it's actionable elements.
tldr is that oftentimes "simpler html" does translate into "more accessibility". if you can read it in lynx, you can read it with a very wide range of screenreaders. but if you actually want to add accessibility to your pages, it's best to sprinkle aria annotations, that are explicitly about making the experience better for the people who need it.
this is gradually changing, as things like ChromeVox become dominant across the world. poor people move away from donated machines towards cheap chinese chrome machines, but then it's not really "HTML5 semantics!!" it becomes "do what google tells you to do"