3 ms·

If using tables for layout broke non-screen user agents (like screen readers and Google), then the web must have been more or less unusable by them until at lea

If using tables for layout broke non-screen user agents (like screen readers and Google), then the web must have been more or less unusable by them until at least 2005. We know that's not true for Google, at least, and by 1999, Lynx actually had some capability for dealing with them. Even if layout tables did present a problem, an easy incremental fix convention (say, `<table class="layout">`) might have been a nice addition to user agents for situations where people either hadn't invested in semantic markup + CSS yet ... or for the layouts beyond CSS capabilities. That isn't to say that I think everybody should be using tables for layout or CSS completely sucks or we'd all be better off if we were doing layout like the Java/C#/Flash/Python library of your choice does it. I'm just not sure the "tables break things" argument is particularly strong.

DougBTX 13y ago
If I remember correctly, the summary="", was suggested for layout tables. I never looked into screen reader support for that though.
- wwweston 13y ago
  That's smart. A present but blank summary attribute would've been a great indicator. I also think that it could've been done pretty reliably by heuristics. A table that mostly has data cells that contain lots of images or block-level markup as descendants is quite likely a markup table. A table that has mostly text or inline-marked cells and has a full summary attribute or <caption> is all but certainly semantic. I guess with IE 6&7 all but dead, though, it's sortof irrelevant now -- you can mostly count on `display: table-cell` to help you out of a jam.
- steveax 13y ago
  What you want to make (modern) screen readers not try and parse the table semantics is to set the role to presentation: <table role="presentation">
ricardobeat 13y ago
Yes, using a screen readers with a table-based website has always been a nightmare. Google invested heavily on research to be able to make sense of tag soup, that's one of the reasons it could provide way better results than anyone else. It's an ugly workaround, like printing a document and scanning it back instead of copying a file. See rest of discussion above.
- wwweston 13y ago
  > Yes, using a screen readers with a table-based website has always been a nightmare. Have you experienced this personally, or do you have this on first-hand account, or are you repeating the common wisdom? Because like I said, Lynx had a way of doing this circa 1999. It mostly ignored tables except a few that met some criteria for likely semantics. So you generally got a cell-ordered page, which worked surprisingly well for most sites. Heck, if you've got a copy of Lynx at hand, fire it up right now and browse HN (which is layed out via table, ridiculous though it is for a site with such a simple layout). If Lynx can do it, I have trouble believing that deliberately assistive software wouldn't be able to. This matches most of the (admittedly limited) discussion I've had with people who use/write it (an aside: I've also heard that, believe it or not frames were sometimes a big boost to assisted usability). If you've got personal experience or first-hand accounts, though, I'm interested to hear it.
  - ricardobeat 13y ago
    I used to work at a company specialized in front-end development, where we used NVDA, Voiceover, Window-Eyes and Jaws extensively while building and testing websites, sometimes for legal compliance. Lynx is a text-mode browser, not a screen reader; it's still visual. Assistive tech has a whole lot more going on. They have a slew of navigation modes and need cues from content to prevent the user from getting lost, you can't just scroll or look back up to where you where. I recommend looking at the resources below, and trying to use an iPhone or mac with voiceover and screen curtain enabled to really experience what it is like. http://alistairduggin.co.uk/blog/screenreader-resources/ http://alistairduggin.co.uk/blog/screenreader-resources/ (collection of videos & articles) http://www.youtube.com/watch?v=izrC4R7SsH4 http://www.youtube.com/watch?v=izrC4R7SsH4 http://www.youtube.com/watch?v=S4QBqpU1jj8 http://www.youtube.com/watch?v=S4QBqpU1jj8 http://www.youtube.com/watch?v=AmUPhEVWu_E http://www.youtube.com/watch?v=AmUPhEVWu_E http://www.youtube.com/watch?v=vK1tlLOavvM http://www.youtube.com/watch?v=vK1tlLOavvM (linked by PavlovsCat below)

DougBTX 13y ago

If I remember correctly, the summary="", was suggested for layout tables. I never looked into screen reader support for that though.

wwweston 13y ago
That's smart. A present but blank summary attribute would've been a great indicator. I also think that it could've been done pretty reliably by heuristics. A table that mostly has data cells that contain lots of images or block-level markup as descendants is quite likely a markup table. A table that has mostly text or inline-marked cells and has a full summary attribute or <caption> is all but certainly semantic. I guess with IE 6&7 all but dead, though, it's sortof irrelevant now -- you can mostly count on `display: table-cell` to help you out of a jam.
steveax 13y ago
What you want to make (modern) screen readers not try and parse the table semantics is to set the role to presentation: <table role="presentation">

ricardobeat 13y ago

Yes, using a screen readers with a table-based website has always been a nightmare. Google invested heavily on research to be able to make sense of tag soup, that's one of the reasons it could provide way better results than anyone else. It's an ugly workaround, like printing a document and scanning it back instead of copying a file. See rest of discussion above.

wwweston 13y ago
> Yes, using a screen readers with a table-based website has always been a nightmare. Have you experienced this personally, or do you have this on first-hand account, or are you repeating the common wisdom? Because like I said, Lynx had a way of doing this circa 1999. It mostly ignored tables except a few that met some criteria for likely semantics. So you generally got a cell-ordered page, which worked surprisingly well for most sites. Heck, if you've got a copy of Lynx at hand, fire it up right now and browse HN (which is layed out via table, ridiculous though it is for a site with such a simple layout). If Lynx can do it, I have trouble believing that deliberately assistive software wouldn't be able to. This matches most of the (admittedly limited) discussion I've had with people who use/write it (an aside: I've also heard that, believe it or not frames were sometimes a big boost to assisted usability). If you've got personal experience or first-hand accounts, though, I'm interested to hear it.
- ricardobeat 13y ago
  I used to work at a company specialized in front-end development, where we used NVDA, Voiceover, Window-Eyes and Jaws extensively while building and testing websites, sometimes for legal compliance. Lynx is a text-mode browser, not a screen reader; it's still visual. Assistive tech has a whole lot more going on. They have a slew of navigation modes and need cues from content to prevent the user from getting lost, you can't just scroll or look back up to where you where. I recommend looking at the resources below, and trying to use an iPhone or mac with voiceover and screen curtain enabled to really experience what it is like. http://alistairduggin.co.uk/blog/screenreader-resources/ http://alistairduggin.co.uk/blog/screenreader-resources/ (collection of videos & articles) http://www.youtube.com/watch?v=izrC4R7SsH4 http://www.youtube.com/watch?v=izrC4R7SsH4 http://www.youtube.com/watch?v=S4QBqpU1jj8 http://www.youtube.com/watch?v=S4QBqpU1jj8 http://www.youtube.com/watch?v=AmUPhEVWu_E http://www.youtube.com/watch?v=AmUPhEVWu_E http://www.youtube.com/watch?v=vK1tlLOavvM http://www.youtube.com/watch?v=vK1tlLOavvM (linked by PavlovsCat below)