Hacker News Reader

Comment by wwweston | Hacker News Reader

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.

View on HN

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.

> 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.

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/ (collection of videos & articles)

http://www.youtube.com/watch?v=izrC4R7SsH4

http://www.youtube.com/watch?v=S4QBqpU1jj8

http://www.youtube.com/watch?v=AmUPhEVWu_E

http://www.youtube.com/watch?v=vK1tlLOavvM (linked by PavlovsCat below)

ARIA provides a solution for the problems caused by <table>.

> Lynx is a text-mode browser, not a screen reader; it's still visual.

Sure. The point isn't that Lynx is an assistive UA, the point is that it's at least one UA that figured out how to throw away layout-purposed table markup (which, like some assistive UAs, doesn't make any sense in its rendering context) and still render (some) markup that represented tabular data.

Is it really the only one?

> 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

Right, but is that really tied up with non-semantic table use? I'd think it's the presence or absence of things like access keys, title/alt text, and I guess at this point aria attributes that makes the difference, not table markup.

Exactly, Lynx is not an assistive UA. Keyword there is `render`. It makes very little use of tags' semantic meaning compared to a screen reader. Alt/title attributes are just a small part of the picture.

You are underestimating the damage bad markup does, and how deeply assistive software relies on semantics/metadata/structure. As I said, just fire up voiceover and try to browser HN. Actually, I'll quickly do that for you:

http://cl.ly/3l3E2C000419

I'm comparing table-based HN to one of it's alternative interfaces, not ideal but much better. It's a very shallow example, and I'm using only basic navigation commands - experienced users can use more complicated navigation schemes to discover content, out of necessity - but you get the idea. Lots of noise (row x of x, column xxx..), blank cells are "read", etc. Remember HN is a very simple and spartan website, now imagine what a slightly more complex nested table layout looks like.

Also, see WebAIM surveys for actual assistive tech usage data: http://webaim.org/projects/

> Lynx is not an assistive UA. Keyword there is `render`. It makes very little use of tags' semantic meaning compared to a screen reader.

It is, however, apparently smarter about the use-semantics of table markup than most screen readers, if I'm to take your example as the norm.

> imagine what a slightly more complex nested table layout looks like.

Having spent more time than I care to remember inside the code of complex nested table layouts, I unfortunately don't really have to work too hard to imagine. :/

> You are underestimating the damage bad markup does, and how deeply assistive software relies on semantics/metadata/structure.

I can see/hear from your example that the table markup is a challenge for voiceover.

I'm not sure I was underestimating the damage repurposed markup does more than I was overestimating the ambitions of assistive UI devs. I'm just astounded that voiceover wouldn't haven't implemented at least a mode for making likely distinctions between table markup that's being used for tabular data and table markup that's being used for layout, when making such a distinction is not only clearly possible but has been done.

Then again, I'm astounded that it's 2013 and Adobe still can't install onto case-sensitive volumes, so there's that.

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

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.

What you want to make (modern) screen readers not try and parse the table semantics is to set the role to presentation:

Reply on news.ycombinator.com