I've never understood the argument that "semantic" tags are easier to render for screenreaders. Like a screenreader knows that <em> is for emphasis, but couldn't possibly render <i> the same way it renders <em>. Or knows that a <div> must be for layout but couldn't possibly treat <table> the same way (modern UI toolkits build tables out of divs, so it's not like div-users semantically distinguish between layout and actual tabular data).
It's not the tags themselves that are "semantic" but how they are used. The semantic web is a content-first approach, as opposed to using tags to design the structure of your page. If you're adding div's to create a specific layout, you're doing it wrong.
That said, I think that CSS is inadequate for the task of controlling the layout of elements so there are very few truly "semantic" layouts.
It's the same problem as deciding whether an API is RESTful enough or not. Eventually, pragmatism wins over dogma. Still, I think (like REST) the semantic web is a good ideal to shoot for.
>knows that a <div> must be for layout but couldn't possibly treat <table> the same way //
How then would you treat actual tables, like <table noreally="true"><tr><th> ... ?
Screenreaders treat tables differently because they carry semantic weight - table headings, rows and such relate to one another in a way that mere areas of a web-page do not.
It's not the table tag that's bad, people don't [shouldn't!] use divs for marking up tabular data.
