E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 33 (In chronological order)

From: Reinhard Stebner
Date: Tue, Jan 28 2014 6:25PM
Subject: complex layout tables
No previous message | Next message →

Does anyone have any good explanations why nested layout tables should not
be used?

From: Karl Groves
Date: Tue, Jan 28 2014 7:52PM
Subject: Re: complex layout tables
← Previous message | Next message →

Nested table layouts aren't inherently any more inaccessible than images,
CSS, or anything really.

In practice however, there are a couple of issues that tend to arise

1. The table layouts tend to create a source order that leads to content
being read in an order other than what is intended, visually. The higher
the density of tables, the greater likelihood this will be the case. Even
though it is 2014, I've seen tables 10-deep as recently as last month.

2. The existence of the tables are often announced by assistive
technologies. So each new table gets announced, adding to unnecessarily
verbose output and possible user confusion.

3. Layout tables are often combined with other bad practices like spacer
images (without alt attributes) and deprecated presentational markup both
of which serve to exacerbate the accessibility problems

4. Tables-based layouts are gross and make me want to take a bath whenever
I look at their markup.





On Tue, Jan 28, 2014 at 8:25 PM, Reinhard Stebner < = EMAIL ADDRESS REMOVED = >wrote:

> Does anyone have any good explanations why nested layout tables should not
> be used?
>
> > > >



--

Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

From: Karl Groves
Date: Tue, Jan 28 2014 8:26PM
Subject: Re: complex layout tables
← Previous message | Next message →

Here's a case-in-point. In this case there's a mish-mosh of presentational
attributes and a spacer gif in a layout table. While they've added an
empty alt on the spacer gif, the presentational markup cannot be overridden
by user styles or by turning off styles.

<table bgcolor="#999999" width="100%" cellspacing="0" cellpadding="0"
border="0">
<tbody><tr valign="top"><td><img src="/uscmap/images/dot_clear.gif"
width="10" height="5" alt=""></td><td class="lftNavBot">






On Tue, Jan 28, 2014 at 9:52 PM, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:

> Nested table layouts aren't inherently any more inaccessible than images,
> CSS, or anything really.
>
> In practice however, there are a couple of issues that tend to arise
>
> 1. The table layouts tend to create a source order that leads to content
> being read in an order other than what is intended, visually. The higher
> the density of tables, the greater likelihood this will be the case. Even
> though it is 2014, I've seen tables 10-deep as recently as last month.
>
> 2. The existence of the tables are often announced by assistive
> technologies. So each new table gets announced, adding to unnecessarily
> verbose output and possible user confusion.
>
> 3. Layout tables are often combined with other bad practices like spacer
> images (without alt attributes) and deprecated presentational markup both
> of which serve to exacerbate the accessibility problems
>
> 4. Tables-based layouts are gross and make me want to take a bath whenever
> I look at their markup.
>
>
>
>
>
> On Tue, Jan 28, 2014 at 8:25 PM, Reinhard Stebner < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Does anyone have any good explanations why nested layout tables should not
>> be used?
>>
>> >> >> >>
>
>
>
> --
>
> Karl Groves
> www.karlgroves.com
> @karlgroves
> http://www.linkedin.com/in/karlgroves
> Phone: +1 410.541.6829
>



--

Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

From: Olaf Drümmer
Date: Wed, Jan 29 2014 12:20AM
Subject: Re: complex layout tables
← Previous message | Next message →

Hi Karl,

On 29 Jan 2014, at 03:52, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:

> 2. The existence of the tables are often announced by assistive
> technologies. So each new table gets announced, adding to unnecessarily
> verbose output and possible user confusion.

so why not introduce a rule such that AT should skip 'announcing' (does that apply to anything other than screen readers?) the table-ness of layout tables, and just progress through the layout table's cell in the intended order?

Olaf

From: Nathalie Sequeira
Date: Wed, Jan 29 2014 1:58AM
Subject: Re: complex layout tables
← Previous message | Next message →

Am 29.01.2014 03:52, schrieb Karl Groves:
> In practice however, there are a couple of issues that tend to arise
>
>

In addition to what Karl already mentioned (and this applies to complex
or simple layout tables):

Layout tables are actually a HACK dating from the 1990's before the
advent of CSS to satisfy the desire to lay out HTML documents.
So it's kind of like still wanting to use a floppy disk to store data or
going down to the river with a scrubbing board to wash your clothes.

To my mind the major issue with layout tables is the mixup of
presentation and content.
This, apart from stumbling blocks it may present to assistive
technology, creates problems when a site is viewed on different devices
(try making a design that uses layout tables responsive?)

HTH
Nathalie

From: Patrick H. Lauke
Date: Wed, Jan 29 2014 2:42AM
Subject: Re: complex layout tables
← Previous message | Next message →

On 29/01/2014 07:20, Olaf Drümmer wrote:
> Hi Karl,
>
> On 29 Jan 2014, at 03:52, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:
>
>> 2. The existence of the tables are often announced by assistive
>> technologies. So each new table gets announced, adding to unnecessarily
>> verbose output and possible user confusion.
>
> so why not introduce a rule such that AT should skip 'announcing' (does that apply to anything other than screen readers?) the table-ness of layout tables, and just progress through the layout table's cell in the intended order?

Which you CAN do using WAI ARIA role="presentation". That still leaves
you with the other problems Karl outlined. Also, building relatively
solid and well-supported layouts purely with CSS has been possible
since...oh...2001 or thereabouts. Just because you can apply a band-aid
to table-based legacy layouts to make them at least not be announced as
tables in AT is not a reason to carry on using them...


--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Wed, Jan 29 2014 2:45AM
Subject: Re: complex layout tables
← Previous message | Next message →

On 29/01/2014 02:52, Karl Groves wrote:
> Nested table layouts aren't inherently any more inaccessible than images,
> CSS, or anything really.
>
> In practice however, there are a couple of issues that tend to arise

I'd add another one:

5. It's not possible (without then resorting to heavy JavaScript) to
easily adapt a table-based layout to different screen sizes,
particularly to small windows/mobile. With CSS layouts, you have a lot
more flexibility (using media queries, rearranging some of the content,
changing floated elements to non-floated linear presentation, etc).

P
--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Nathalie Sequeira
Date: Wed, Jan 29 2014 3:03AM
Subject: Re: complex layout tables
← Previous message | Next message →

Hi Olaf,

Am 29.01.2014 08:20, schrieb Olaf Drümmer:
> so why not introduce a rule such that AT should skip 'announcing'
> (does that apply to anything other than screen readers?) the
> table-ness of layout tables, and just progress through the layout
> table's cell in the intended order?

But... what IS the "intended order"?
Screen readers just linearize table contents.
There is no mechanism in HTML to define which table cell comes first
should that (in a Western context) default left-to-right top-to-bottom
order lead to incoherent reading order - and why? Because thats not what
tables are there for!

Yes, accomodations have been made all over based on the fact that many
adamantly insist on still using tables for their layouts.

But in 2014, we can build sites with slim, lightweight HTML styled by
CSS - that ALL browsers understand, and insisting on using table layouts
IMHO is a sign of ignorance and laziness to learn state-of-the-art
(goodness, theyre not even that, just plain middle of the road
actually!) techniques.
Today, there is NO reason to be using a technique that bloats page size,
is difficult to maintain, potentially creates problems for a whole
segment of users and is not at all in tune with the reality of an
increasing variety of devices being used to access the web.

Bottom line: it is up to webpage-creators to kick their antiquated
habits. Enough excuses have been made and it really is time to change.

Cheers,
Nathalie

From: Steve Green
Date: Wed, Jan 29 2014 3:49AM
Subject: Re: complex layout tables
← Previous message | Next message →

" Today, there is NO reason to be using a technique that bloats page size, is difficult to maintain, potentially creates problems for a whole segment of users"

I totally agree, but that criticism could equally be levelled at the very latest development approaches. We see websites with 1MB or more of JavaScript (200k seems to be the absolute minimum these days) and dozens of CSS files - single pages on the BBC website use more than 30.

Despite the claims, JavaScript libraries are not accessible out-of-the-box and very few developers have any idea how to make them so. Some are so awful that all the ARIA in the world can't fix them.

By comparison, the accessibility barriers resulting from the use of layout tables are trivial (not that I advocate them of course).

Steve Green

From: Hewitt,Susan (DSHS)
Date: Wed, Jan 29 2014 7:10AM
Subject: Re: complex layout tables
← Previous message | Next message →

I have nothing else to add that hasn't already been said but I have no other way to favorite this sentence:

"4. Tables-based layouts are gross and make me want to take a bath whenever I look at their markup."

Really people, take pride in what you do and learn CSS already.

From: Olaf Drümmer
Date: Wed, Jan 29 2014 12:16PM
Subject: Re: complex layout tables
← Previous message | Next message →

Hi all,

> "4. Tables-based layouts are gross and make me want to take a bath whenever I look at their markup."

sometimes I wonder what the mission of some of you is:

- force everybody in the world to use a certain style you like, e.g. a coding style that's fresh, modern, elegant, …? What gives you the right to do so, or to bad-mouth styles you do not like?

or rather

- make sure that stuff out there can be accessed by everyone in a reasonable fashion


I can't see why a style that is 'gross' hinders equal access.


And: from a stylistic point of view, I find a substantial portion of accessible web sites highly awful. While I think it's OK for me to have that opinion, it is nothing that would or should be discussed on this discussion list (so if you wish to discuss **this** get in touch with me privately ;-) ).


Olaf

From: Hewitt,Susan (DSHS)
Date: Wed, Jan 29 2014 12:20PM
Subject: Re: complex layout tables
← Previous message | Next message →

" make sure that stuff out there can be accessed by everyone in a reasonable fashion"

Semantic markup is one of the biggest steps you can take to make this happen.

From: Patrick H. Lauke
Date: Wed, Jan 29 2014 12:43PM
Subject: Re: complex layout tables
← Previous message | Next message →

On 29/01/2014 19:16, Olaf Drümmer wrote:
> sometimes I wonder what the mission of some of you is:
>
> - force everybody in the world to use a certain style you like, e.g.
> a coding style that's fresh, modern, elegant, …? What gives you the
> right to do so, or to bad-mouth styles you do not like?

This is not a question of style. Tables are not meant to be used for
layout. They're for tabular data. I hope you're not intending to dispute
that?

Fresh, modern and elegant...using CSS for layouts has been the
recommended practice for...oh...going on at least 13 years.

> - make sure that stuff out there can be accessed by everyone in a
> reasonable fashion
>
>
> I can't see why a style that is 'gross' hinders equal access.

So you ignore the 3 factual statements that relate to how table-based
layouts DO hinder equal access, and pick on the 4th statement which was
added for comedic effect?

> And: from a stylistic point of view, I find a substantial portion of
> accessible web sites highly awful.

Nobody was talking about visual aesthetics. Unless you're suggesting
that the awful look of those accessible websites is directly related to
the fact that they use CSS styling rather than layout tables? (In which
case I'm having flashbacks to, well, around 13 years ago).

Cheers,

P
--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Olaf Drümmer
Date: Wed, Jan 29 2014 12:44PM
Subject: Re: complex layout tables
← Previous message | Next message →

Hi Nathalie,

On 29 Jan 2014, at 11:03, Nathalie Sequeira < = EMAIL ADDRESS REMOVED = > wrote:

> But in 2014, we can build sites with slim, lightweight HTML styled by CSS - that ALL browsers understand, and insisting on using table layouts IMHO is a sign of ignorance and laziness to learn state-of-the-art (goodness, theyre not even that, just plain middle of the road actually!) techniques.
> Today, there is NO reason to be using a technique that bloats page size, is difficult to maintain, potentially creates problems for a whole segment of users and is not at all in tune with the reality of an increasing variety of devices being used to access the web.
>
> Bottom line: it is up to webpage-creators to kick their antiquated habits. Enough excuses have been made and it really is time to change.

I have to say that I find the tone of your message inappropriate for this list.

terms like 'ignorance', 'laziness', 'kick antiquated habits' and so forth probably are just a sign that you had a bad morning but still do not belong in discussions like this one.


So please let's get back to a fair discussion about reality, without denigrating others.


I sometimes have the impression that many on this list believe web sites and web content are created exclusively by selected web site professionals and web content creation professionals. I do not think this takes into account some massive trends that have occurred in the last years. The biggest trend here is that web systems have been democratised. Just look at systems based on the likes of WordPress, Drupal, Joomla, Typo3 and so forth. More often than not the person entering content is **not at all** an expert on web site technology, accessibility or anything like that. They use what they have, and they try to get the job of entering content done in their best possible way. They will hardly ever be in a position to do anything about the CSS for that site, nor will the be allowed near the JavaScript stuff. So if these people wish to present and arrange content in an easy to digest manner, and because they can't use CSS for number of reasons, they might find themselves juggli
ng around with a table once in a while.

Now there are at least the following ways you could approach this:
- you could shout at these people, call them lazy, ignorant, or whatever is your favourite swearword; my guess is you won't achieve much
- you could be nice and try to convince people that they should do something about it, like: do not use tables, take a training course on CSS, stay at the office until the sysadmin leaves, and hack the web system, etc.; my estimate: good luck
- you try to find some easy, cost effective, convincing, good enough approach (easy to developer/implement, and easy to use) to "fix the system"; such an approach could be to come up with a rule like "any table that does not have TH cells is a layout table", and ask AT developers to take that (and the current writing mode) into account when presenting the table (can we please stop to always only refer to screen readers when it comes to AT? blind people are a relatively small portion of those suffering from one or the other disability)?


I think we should do some math once in a while and figure how expensive an approach is:
- how expensive is it to convince/train each and every content creator in the world? What is the number of content creators? What is the 'cost' to reach out to one of them, and to change the way they "do content"?
- how expensive is it to change systems (mostly software in this context)? How many companies/developers exist that develop a relevant tool or technology? How expensive is it to reach out to one of them and convince him/her?


Olaf

From: Karl Groves
Date: Wed, Jan 29 2014 12:49PM
Subject: Re: complex layout tables
← Previous message | Next message →

" force everybody in the world to use a certain style you like, e.g. a
coding style that's fresh, modern, elegant, …? "

Well, I'm not forcing anyone to do anything. Regardless, I'm not really
sure what's "fresh" and "modern" about using CSS to do layouts. CSS based
layouts have been possible since about IE5 or so though an argument could
be made that it wasn't until IE6 that you could reliably have
cross-platform CSS layouts. The many benefits for both users and developers
of using CSS layout instead of tables have been well documented over the
years and probably don't require reiterating here.


"What gives you the right to do so, or to bad-mouth styles you do not like?"
Freedom of expression? Its the same right you have, as a member of the
list, to disagree.

In this case though it bears mentioning that the "coding style" to which
we're both reviewing has been discouraged as a non-semantic use of tables
for more than a decade[1]. This is, in all senses of the term, a
quality-of-work issue and not merely a discussion of coding style. Coding
style discussions, IMO, are oriented around doing good work in a way that
makes it even better. In this case we're talking about bad work.


"I can't see why a style that is 'gross' hinders equal access."

Actually those other items you conveniently snipped are the ones where the
accessibility issues were listed.


1 - http://www.w3.org/2002/03/csslayout-howto





On Wed, Jan 29, 2014 at 2:16 PM, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:

> Hi all,
>
> > "4. Tables-based layouts are gross and make me want to take a bath
> whenever I look at their markup."
>
> sometimes I wonder what the mission of some of you is:
>
> - force everybody in the world to use a certain style you like, e.g. a
> coding style that's fresh, modern, elegant, …? What gives you the right to
> do so, or to bad-mouth styles you do not like?
>
> or rather
>
> - make sure that stuff out there can be accessed by everyone in a
> reasonable fashion
>
>
> I can't see why a style that is 'gross' hinders equal access.
>
>
> And: from a stylistic point of view, I find a substantial portion of
> accessible web sites highly awful. While I think it's OK for me to have
> that opinion, it is nothing that would or should be discussed on this
> discussion list (so if you wish to discuss **this** get in touch with me
> privately ;-) ).
>
>
> Olaf
>
> > > >



--

Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

From: Karl Groves
Date: Wed, Jan 29 2014 12:55PM
Subject: Re: complex layout tables
← Previous message | Next message →

"terms like 'ignorance', 'laziness', 'kick antiquated habits' and so forth
probably are just a sign that you had a bad morning but still do not belong
in discussions like this one."

followed by:

"So please let's get back to a fair discussion about reality, without
denigrating others."

Ironic to the point of being humorous.

I'll stop feeding the troll now and get back to lurking.

Sorry, everyone, for being humorous and consequently setting this one off.


On Wed, Jan 29, 2014 at 2:44 PM, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:

> Hi Nathalie,
>
> On 29 Jan 2014, at 11:03, Nathalie Sequeira < = EMAIL ADDRESS REMOVED = > wrote:
>
> > But in 2014, we can build sites with slim, lightweight HTML styled by
> CSS - that ALL browsers understand, and insisting on using table layouts
> IMHO is a sign of ignorance and laziness to learn state-of-the-art
> (goodness, theyre not even that, just plain middle of the road actually!)
> techniques.
> > Today, there is NO reason to be using a technique that bloats page size,
> is difficult to maintain, potentially creates problems for a whole segment
> of users and is not at all in tune with the reality of an increasing
> variety of devices being used to access the web.
> >
> > Bottom line: it is up to webpage-creators to kick their antiquated
> habits. Enough excuses have been made and it really is time to change.
>
> I have to say that I find the tone of your message inappropriate for this
> list.
>
> terms like 'ignorance', 'laziness', 'kick antiquated habits' and so forth
> probably are just a sign that you had a bad morning but still do not belong
> in discussions like this one.
>
>
> So please let's get back to a fair discussion about reality, without
> denigrating others.
>
>
> I sometimes have the impression that many on this list believe web sites
> and web content are created exclusively by selected web site professionals
> and web content creation professionals. I do not think this takes into
> account some massive trends that have occurred in the last years. The
> biggest trend here is that web systems have been democratised. Just look at
> systems based on the likes of WordPress, Drupal, Joomla, Typo3 and so
> forth. More often than not the person entering content is **not at all** an
> expert on web site technology, accessibility or anything like that. They
> use what they have, and they try to get the job of entering content done in
> their best possible way. They will hardly ever be in a position to do
> anything about the CSS for that site, nor will the be allowed near the
> JavaScript stuff. So if these people wish to present and arrange content in
> an easy to digest manner, and because they can't use CSS for number of
> reasons, they might find themselves juggli
> ng around with a table once in a while.
>
> Now there are at least the following ways you could approach this:
> - you could shout at these people, call them lazy, ignorant, or whatever
> is your favourite swearword; my guess is you won't achieve much
> - you could be nice and try to convince people that they should do
> something about it, like: do not use tables, take a training course on CSS,
> stay at the office until the sysadmin leaves, and hack the web system,
> etc.; my estimate: good luck
> - you try to find some easy, cost effective, convincing, good enough
> approach (easy to developer/implement, and easy to use) to "fix the
> system"; such an approach could be to come up with a rule like "any table
> that does not have TH cells is a layout table", and ask AT developers to
> take that (and the current writing mode) into account when presenting the
> table (can we please stop to always only refer to screen readers when it
> comes to AT? blind people are a relatively small portion of those suffering
> from one or the other disability)?
>
>
> I think we should do some math once in a while and figure how expensive
> an approach is:
> - how expensive is it to convince/train each and every content creator in
> the world? What is the number of content creators? What is the 'cost' to
> reach out to one of them, and to change the way they "do content"?
> - how expensive is it to change systems (mostly software in this context)?
> How many companies/developers exist that develop a relevant tool or
> technology? How expensive is it to reach out to one of them and convince
> him/her?
>
>
> Olaf
>
> > > >



--

Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

From: Jared Smith
Date: Wed, Jan 29 2014 12:56PM
Subject: Re: complex layout tables
← Previous message | Next message →

On Wed, Jan 29, 2014 at 12:16 PM, Olaf Drümmer wrote:

> I can't see why a style that is 'gross' hinders equal access.

At face value, it probably doesn't. But there's more to ensuring broad
accessibility than simply implementing accessibility techniques. Good
coding practices - such as clean/valid code, not using tables for
layout, defining appropriate class/id names, using clean CSS that
takes advantage of inheritance, avoiding <div>itis, not browser
sniffing, doing progressive enhancement, etc., etc. - may have little
or no direct impact on the accessibility of a particular document.
However, when developers are working with inefficient code or tools,
they inherently have less time and more difficulty in implementing
more and better accessibility.

But I do understand your point, I think. We often conflate
accessibility compliance techniques and general best practice all the
time. We hear people say that using tables for layout or invalid HTML
or using red and green colors are "inaccessible", when they don't
always automatically result in any functional accessibility issues in
a web page. But the reality is that these less-than-optimal practices
will usually be detrimental to broader accessibility efforts.

Jared

From: Olaf Drümmer
Date: Wed, Jan 29 2014 1:00PM
Subject: Re: complex layout tables
← Previous message | Next message →

Hi Patrick,

On 29 Jan 2014, at 20:43, "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = > wrote:

> Tables are not meant to be used for layout. They're for tabular data. I hope you're not intending to dispute that?

I actually do dispute that. HTML 5 even tells you how to do layout tables:
> If a table is to be used for layout it must be marked with the attribute role="presentation" for a user agent to properly represent the table to an assistive technology and to properly convey the intent of the author to tools that wish to extract tabular data from the document.


It turns out that in HTML (but also in Word, layout applications, etc.) a substantial number of content creators use tables not for what they were invented for, but in a different fashion, to arrange content in two dimension on the page or canvas. Tables have turned out to be a very robust and efficient mechanism for that, cell sizes adjust and still continue to align nicely, you can easily add rows or columns as needed and so forth. From the point of view of numerous users that is very valuable, and allows them to get their job done in a very short time in a very high quality (as in: high quality from their point of view, not necessarily from the point of view of everybody else).

[BTW - this is not so different from some of the hacks being discussed on this list where content magically appears or disappears for certain presentation types, e.g. invisible for visual display, but presented when using text to speech presentation - such hacks very honestly scare the heck out of me….]

Now, how do you convince a user who finds layout tables highly useful (at least in certain use cases), believes that they work from his point of view (why don't mobile devices do a better job of displaying tabular content? It has been proven they could, but most don't), and has neither the expertise nor the technical means to use a CSS based approach for his layout table, to stop using layout tables? Will you send the "table police"?

Olaf

From: Patrick H. Lauke
Date: Wed, Jan 29 2014 1:04PM
Subject: Re: complex layout tables
← Previous message | Next message →

On 29/01/2014 20:00, Olaf Drümmer wrote:
> Now, how do you convince a user who finds layout tables highly useful
> (at least in certain use cases), believes that they work from his
> point of view (why don't mobile devices do a better job of displaying
> tabular content? It has been proven they could, but most don't), and
> has neither the expertise nor the technical means to use a CSS based
> approach for his layout table, to stop using layout tables? Will you
> send the "table police"?

You're comically blowing this out of proportion...but ok, I'll bite once
more: what do I do? Nothing. But if they come on an accessibility
mailing list and ask what's wrong with using tables for layout, I'll
tell them.

P
--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: deborah.kaplan
Date: Wed, Jan 29 2014 1:21PM
Subject: Re: complex layout tables
← Previous message | Next message →

Forgive me if I am mistaken, because I have only just started
coding HTML email, but my understanding is that if you want to
send HTML email to end-users that will be functional on a wide
variety of email clients which claim to support HTML, you
effectively have to use layout tables, because of the variance in
support among different email clients.

I do understand that I'm conflating "HTML" and "the web" there;
that's email accessibility I'm discussing, not web accessibility.
But even so, it does mean that in order to create accessible HTML
email, you *must* be able to code accessible layout tables.

Deborah Kaplan
Accessibility Team Co-Lead
Dreamwidth Studios

From: Andrew Kirkpatrick
Date: Wed, Jan 29 2014 1:28PM
Subject: Re: complex layout tables
← Previous message | Next message →

Jared,
Great answer. I've seen tons of code that isn't optimal and doesn't always impact accessibility directly, and I've been told more often than I care to recall that a simple fix will take 10x more time than I think it should (and therefore won't be possible).

I advocate for clean code for these reasons and more, and agree wholeheartedly with your points.

AWK

From: Patrick H. Lauke
Date: Wed, Jan 29 2014 1:29PM
Subject: Re: complex layout tables
← Previous message | Next message →

On 29/01/2014 20:21, = EMAIL ADDRESS REMOVED = wrote:
> Forgive me if I am mistaken, because I have only just started
> coding HTML email, but my understanding is that if you want to
> send HTML email to end-users that will be functional on a wide
> variety of email clients which claim to support HTML, you
> effectively have to use layout tables, because of the variance in
> support among different email clients.
>
> I do understand that I'm conflating "HTML" and "the web" there;
> that's email accessibility I'm discussing, not web accessibility.
> But even so, it does mean that in order to create accessible HTML
> email, you *must* be able to code accessible layout tables.

Many email clients - and most web-based email services - are notoriously
lacking in web standards support (or they strip out/rewrite HTML/CSS so
it can be embedded in the context of the web-based interface). Further,
they may not expose the same amount of information to the OS'
accessibility APIs, meaning that even perfectly accessible markup may
not be announced correctly.

Accessibility and correct use of web standards rely on authors AND user
agents (as well as authoring environments) doing the right thing (the
WCAG/UAAG/ATAG triumvirate, if you will). In this situation, most email
clients don't hold up their end of the bargain, which unfortunately
means that authors will need to use workarounds (such as, indeed, using
tables for layout).

P
--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Olaf Drümmer
Date: Wed, Jan 29 2014 1:31PM
Subject: Re: complex layout tables
← Previous message | Next message →

On 29 Jan 2014, at 21:04, "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = > wrote:

> You're comically blowing this out of proportion...but ok, I'll bite once more: what do I do? Nothing. But if they come on an accessibility mailing list and ask what's wrong with using tables for layout, I'll tell them.

comical or not - this is linked to the subject of this thread, complex layout tables.

My interest is in reaching a state in the foreseeable future where content, that currently by some people is organised as a layout table, becomes accessible to as many users as possible.

Getting there can in principle be achieved in a couple of ways, for example
- do not use layout tables
- find ways to make layout tables work in a fashion such that consuming them becomes accessible

Technically speaking I believe it is correct to state that both can work / can be made to work. HTML5 discourage use of layout tables, but offers guidance (use role = 'presentation') how to use them if you feel you must use them. Based on writing mode in effect, it can be derived in which order to present the cells' contents.

But I am not (only/primarily) interested in theoretical correctness or technical feasibility, I am also interested in the likelihood and degree that something will actually happen - as my goal is to make such content accessible to widest range of users. Thus the question should be allowed, that while theoretically layout tables are not a good use of the table concept, whether it wouldn't be a good idea to accept their use anyway, and to come up with an approach how they can be put to work in an accessible fashion.

Olaf

From: Steve Faulkner
Date: Wed, Jan 29 2014 1:26PM
Subject: Re: complex layout tables
← Previous message | Next message →

On 29 January 2014 20:00, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:

> I actually do dispute that. HTML 5 even tells you how to do layout tables:


patrick is right, tables are for data, that is the semantics they convey,
when the normative advice in the spec is ignored one repair technique is to
remove the semantics with role=presentation.
HTML5 says<http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#the-table-element>;
:

"Tables should not be used as layout aids. Historically, many Web authors
have tables in HTML as a way to control their page layout making it
difficult to extract tabular data from such documents. In particular, users
of accessibility tools, like screen readers, are likely to find it very
difficult to navigate pages with tables used for layout. If a table is to
be used for layout it must be marked with the attribute role="presentation"
for a user agent to properly represent the table to an assistive technology
and to properly convey the intent of the author to tools that wish to
extract tabular data from the document."

note the SHOULD NOT in the first sentence is a normative statement (as is
the MUST in the third sentence). In other words use of tables for layout is
NOT RECOMMENDED, but the spec acknowledges that tables are misused and
provides advice on a repair mechanism. This advice could probably do with
strengthening and expanding.



--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;

From: Olaf Drümmer
Date: Wed, Jan 29 2014 1:59PM
Subject: Re: complex layout tables
← Previous message | Next message →

Regarding the use of the word "should" - here is an excerpt from [RFC2119].
"Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF""

> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
> may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and
> carefully weighed before choosing a different course.

so given there are valid reasons, it can be acceptable - on a normative level - to use a layout table.

HTML5 then proceeds - in a normative (and actually absolutely strict - by means of the word MUST) manner - what to do exactly when using a layout table (i.e. use role = "presentation" attribute)


I would see the task of the accessibility community in ensuring that content in a layout table is presented - by user agents and AT - in an accessible fashion. Given that such accessibility can technically be achieved I have difficulty seeing why banning layout tables anyway is deemed acceptable.


Olaf



On 29 Jan 2014, at 21:26, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:

> On 29 January 2014 20:00, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I actually do dispute that. HTML 5 even tells you how to do layout tables:
>
>
> patrick is right, tables are for data, that is the semantics they convey,
> when the normative advice in the spec is ignored one repair technique is to
> remove the semantics with role=presentation.
> HTML5 says<http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#the-table-element>;
> :
>
> "Tables should not be used as layout aids. Historically, many Web authors
> have tables in HTML as a way to control their page layout making it
> difficult to extract tabular data from such documents. In particular, users
> of accessibility tools, like screen readers, are likely to find it very
> difficult to navigate pages with tables used for layout. If a table is to
> be used for layout it must be marked with the attribute role="presentation"
> for a user agent to properly represent the table to an assistive technology
> and to properly convey the intent of the author to tools that wish to
> extract tabular data from the document."
>
> note the SHOULD NOT in the first sentence is a normative statement (as is
> the MUST in the third sentence). In other words use of tables for layout is
> NOT RECOMMENDED, but the spec acknowledges that tables are misused and
> provides advice on a repair mechanism. This advice could probably do with
> strengthening and expanding.
>
>
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
> > >

From: Patrick H. Lauke
Date: Wed, Jan 29 2014 3:26PM
Subject: Re: complex layout tables
← Previous message | Next message →

On 29/01/2014 20:59, Olaf Drümmer wrote:
> so given there are valid reasons, it can be acceptable - on a normative level - to use a layout table.

And those valid reasons were? That authors may not be aware how to do it
any other way? That doing a layout with tables is quicker for them?

If that is subjectively felt as being a valid reason, then fair enough,
stick role="presentation" in there as well and be done with it.

On the same token, constructs like

<p><font size="+2">I'm an H1 yo!</font></p>

are then also valid, of course, as long as you stick a role="heading" in
there somewhere.

I see that in future we'll refrain from making best-practice suggestions
that have been around for over a decade...

P
--
Patrick H. Lauke
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Lucy Greco
Date: Wed, Jan 29 2014 3:27PM
Subject: Re: complex layout tables
← Previous message | Next message →

I don't like the turn this message took. It is not only screen readers
that have problems with lay out tables it's just easy to point at us. For
get access. Lay out tables don't translate well to mobile or other screen
types at all. So its pass access. I am getting the idea that someone told
you should stop using lay out tables and you came here to get a reason to
not stop doing so well over all lay out tables just don't work access or
not

Lucia Greco
Web Access Analyst
IST-Campus Technology Services
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu

From: Denis Boudreau
Date: Wed, Jan 29 2014 3:39PM
Subject: Re: complex layout tables
← Previous message | Next message →

Patrick,

We will never succeed at preventing developers who couldn’t care less about semantic code - or worse, who think aria is the answer to everything - to just slap heading roles, presentation roles and whatnot on top of presentational markup. What we can do however, is keep on insisting that there’s a better way to do things ( that there’s ALWAYS BEEN a better way to do things), one that does not expects anyone to rely on aria to fix clueless coding mistakes.

/Denis



On Jan 29, 2014, at 5:26 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:

> On 29/01/2014 20:59, Olaf Drümmer wrote:
>> so given there are valid reasons, it can be acceptable - on a normative level - to use a layout table.
>
> And those valid reasons were? That authors may not be aware how to do it any other way? That doing a layout with tables is quicker for them?
>
> If that is subjectively felt as being a valid reason, then fair enough, stick role="presentation" in there as well and be done with it.
>
> On the same token, constructs like
>
> <p><font size="+2">I'm an H1 yo!</font></p>
>
> are then also valid, of course, as long as you stick a role="heading" in there somewhere.
>
> I see that in future we'll refrain from making best-practice suggestions that have been around for over a decade...
>
> P
> --
> Patrick H. Lauke
> > re·dux (adj.): brought back; returned. used postpositively
> [latin : re-, re- + dux, leader; see duke.]
>
> www.splintered.co.uk | www.photographia.co.uk
> http://redux.deviantart.com | http://flickr.com/photos/redux/
> > twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: Olaf Drümmer
Date: Wed, Jan 29 2014 4:00PM
Subject: Re: complex layout tables
← Previous message | Next message →

On 29 Jan 2014, at 23:26, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:

>> so given there are valid reasons, it can be acceptable - on a normative level - to use a layout table.
>
> And those valid reasons were? That authors may not be aware how to do it any other way? That doing a layout with tables is quicker for them?

yes, I believe these can be valid reasons. We all have to accept the fact that resources are limited. For some content creators / users in certain scenarios it can be very expensive (time, money, learning curve, deadlines, … ) to get hold of a solution that does not use layout tables. And it may make more sense to invest on other aspects of the content and its accessibility.

> If that is subjectively felt as being a valid reason, then fair enough, stick role="presentation" in there as well and be done with it.

Can you envision an objective assessment of the validity of a reason?

> On the same token, constructs like
>
> <p><font size="+2">I'm an H1 yo!</font></p>
>
> are then also valid, of course, as long as you stick a role="heading" in there somewhere.

I think it's not quite the same (but I do admit you have a point - where to draw the line … ?):
- using a layout table is substantially easier for many than developing the right CSS; at the same time, no semantic is lost
- using font size attribute on a P tag plus role = heading, versus using a heading tag right away to me does not sound easier, so the reason to use the former would be very weak

Olaf

From: Olaf Drümmer
Date: Wed, Jan 29 2014 4:33PM
Subject: Re: complex layout tables
← Previous message | Next message →

And on top of that, WCAG2 as well is happy to guide a user using layout tables:

from: F49: Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized
see: http://www.w3.org/TR/WCAG20-TECHS/F49

> Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML tableelements and to conform to the coding practice of separating presentation from content. If a layout table is used, however, it is important that the content make sense when linearized.

So the one thing to watch out for when using layout tables is to make sure that the order in which the cells are to be presented / consumed, match linearized processing of the table.

Olaf


On 29 Jan 2014, at 21:26, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:

> On 29 January 2014 20:00, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I actually do dispute that. HTML 5 even tells you how to do layout tables:
>
>
> patrick is right, tables are for data, that is the semantics they convey,
> when the normative advice in the spec is ignored one repair technique is to
> remove the semantics with role=presentation.
> HTML5 says<http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#the-table-element>;
> :
>
> "Tables should not be used as layout aids. Historically, many Web authors
> have tables in HTML as a way to control their page layout making it
> difficult to extract tabular data from such documents. In particular, users
> of accessibility tools, like screen readers, are likely to find it very
> difficult to navigate pages with tables used for layout. If a table is to
> be used for layout it must be marked with the attribute role="presentation"
> for a user agent to properly represent the table to an assistive technology
> and to properly convey the intent of the author to tools that wish to
> extract tabular data from the document."
>
> note the SHOULD NOT in the first sentence is a normative statement (as is
> the MUST in the third sentence). In other words use of tables for layout is
> NOT RECOMMENDED, but the spec acknowledges that tables are misused and
> provides advice on a repair mechanism. This advice could probably do with
> strengthening and expanding.
>
>
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
> > >

From: Steve Faulkner
Date: Thu, Jan 30 2014 2:46AM
Subject: Re: complex layout tables
← Previous message | Next message →

thanks Olaf, I am aware of the RFC and what the statements mean.

I have filed a bug against the HTML5 spec
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24447

to make the advice against table use for layout more explicit and to expand
the explanations of the issues.

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;


On 29 January 2014 20:59, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:

> Regarding the use of the word "should" - here is an excerpt from [RFC2119].
> "Key words for use in RFCs to Indicate Requirement Levels, S. Bradner.
> IETF""
>
> > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
> > may exist valid reasons in particular circumstances to ignore a
> > particular item, but the full implications must be understood and
> > carefully weighed before choosing a different course.
>
> so given there are valid reasons, it can be acceptable - on a normative
> level - to use a layout table.
>
> HTML5 then proceeds - in a normative (and actually absolutely strict - by
> means of the word MUST) manner - what to do exactly when using a layout
> table (i.e. use role = "presentation" attribute)
>
>
> I would see the task of the accessibility community in ensuring that
> content in a layout table is presented - by user agents and AT - in an
> accessible fashion. Given that such accessibility can technically be
> achieved I have difficulty seeing why banning layout tables anyway is
> deemed acceptable.
>
>
> Olaf
>
>
>
> On 29 Jan 2014, at 21:26, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
>
> > On 29 January 2014 20:00, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> I actually do dispute that. HTML 5 even tells you how to do layout
> tables:
> >
> >
> > patrick is right, tables are for data, that is the semantics they convey,
> > when the normative advice in the spec is ignored one repair technique is
> to
> > remove the semantics with role=presentation.
> > HTML5 says<
> http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#the-table-element
> >
> > :
> >
> > "Tables should not be used as layout aids. Historically, many Web authors
> > have tables in HTML as a way to control their page layout making it
> > difficult to extract tabular data from such documents. In particular,
> users
> > of accessibility tools, like screen readers, are likely to find it very
> > difficult to navigate pages with tables used for layout. If a table is to
> > be used for layout it must be marked with the attribute
> role="presentation"
> > for a user agent to properly represent the table to an assistive
> technology
> > and to properly convey the intent of the author to tools that wish to
> > extract tabular data from the document."
> >
> > note the SHOULD NOT in the first sentence is a normative statement (as is
> > the MUST in the third sentence). In other words use of tables for layout
> is
> > NOT RECOMMENDED, but the spec acknowledges that tables are misused and
> > provides advice on a repair mechanism. This advice could probably do with
> > strengthening and expanding.
> >
> >
> >
> > --
> >
> > Regards
> >
> > SteveF
> > HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
> > > > > > >
> > > >

From: Steve Faulkner
Date: Thu, Jan 30 2014 3:02AM
Subject: Re: complex layout tables
← Previous message | Next message →

I have also mailed the HTML WG
http://lists.w3.org/Archives/Public/public-html/2014Jan/0155.html


--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;


On 30 January 2014 09:46, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:

> thanks Olaf, I am aware of the RFC and what the statements mean.
>
> I have filed a bug against the HTML5 spec
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24447
>
> to make the advice against table use for layout more explicit and to
> expand the explanations of the issues.
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
>
>
> On 29 January 2014 20:59, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Regarding the use of the word "should" - here is an excerpt from
>> [RFC2119].
>> "Key words for use in RFCs to Indicate Requirement Levels, S. Bradner.
>> IETF""
>>
>> > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
>> > may exist valid reasons in particular circumstances to ignore a
>> > particular item, but the full implications must be understood and
>> > carefully weighed before choosing a different course.
>>
>> so given there are valid reasons, it can be acceptable - on a normative
>> level - to use a layout table.
>>
>> HTML5 then proceeds - in a normative (and actually absolutely strict - by
>> means of the word MUST) manner - what to do exactly when using a layout
>> table (i.e. use role = "presentation" attribute)
>>
>>
>> I would see the task of the accessibility community in ensuring that
>> content in a layout table is presented - by user agents and AT - in an
>> accessible fashion. Given that such accessibility can technically be
>> achieved I have difficulty seeing why banning layout tables anyway is
>> deemed acceptable.
>>
>>
>> Olaf
>>
>>
>>
>> On 29 Jan 2014, at 21:26, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> > On 29 January 2014 20:00, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
>> >
>> >> I actually do dispute that. HTML 5 even tells you how to do layout
>> tables:
>> >
>> >
>> > patrick is right, tables are for data, that is the semantics they
>> convey,
>> > when the normative advice in the spec is ignored one repair technique
>> is to
>> > remove the semantics with role=presentation.
>> > HTML5 says<
>> http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#the-table-element
>> >
>> > :
>> >
>> > "Tables should not be used as layout aids. Historically, many Web
>> authors
>> > have tables in HTML as a way to control their page layout making it
>> > difficult to extract tabular data from such documents. In particular,
>> users
>> > of accessibility tools, like screen readers, are likely to find it very
>> > difficult to navigate pages with tables used for layout. If a table is
>> to
>> > be used for layout it must be marked with the attribute
>> role="presentation"
>> > for a user agent to properly represent the table to an assistive
>> technology
>> > and to properly convey the intent of the author to tools that wish to
>> > extract tabular data from the document."
>> >
>> > note the SHOULD NOT in the first sentence is a normative statement (as
>> is
>> > the MUST in the third sentence). In other words use of tables for
>> layout is
>> > NOT RECOMMENDED, but the spec acknowledges that tables are misused and
>> > provides advice on a repair mechanism. This advice could probably do
>> with
>> > strengthening and expanding.
>> >
>> >
>> >
>> > --
>> >
>> > Regards
>> >
>> > SteveF
>> > HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
>> > >> > >> > >>
>> >> >> >>
>
>

From: James Nurthen
Date: Thu, Jan 30 2014 11:11AM
Subject: Re: complex layout tables
← Previous message | No next message

Steve,
What does the HTML spec mean by "and the CSS table model.
[CSS]<http://www.w3.org/html/wg/drafts/html/master/references.html#refsCSS>;
"
Which specific CSS features is it recommending?

I hope it is not recommending authors to style DIVs using display:table,
display:table-row and display:table-cell as that will result in data tables
being exposed to the accessibility APIs in Firefox even if there are no
tables in the HTML page!

Regards,
James


On Thu, Jan 30, 2014 at 1:46 AM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >wrote:

> thanks Olaf, I am aware of the RFC and what the statements mean.
>
> I have filed a bug against the HTML5 spec
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24447
>
> to make the advice against table use for layout more explicit and to expand
> the explanations of the issues.
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
>
>
> On 29 January 2014 20:59, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Regarding the use of the word "should" - here is an excerpt from
> [RFC2119].
> > "Key words for use in RFCs to Indicate Requirement Levels, S. Bradner.
> > IETF""
> >
> > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
> > > may exist valid reasons in particular circumstances to ignore a
> > > particular item, but the full implications must be understood and
> > > carefully weighed before choosing a different course.
> >
> > so given there are valid reasons, it can be acceptable - on a normative
> > level - to use a layout table.
> >
> > HTML5 then proceeds - in a normative (and actually absolutely strict - by
> > means of the word MUST) manner - what to do exactly when using a layout
> > table (i.e. use role = "presentation" attribute)
> >
> >
> > I would see the task of the accessibility community in ensuring that
> > content in a layout table is presented - by user agents and AT - in an
> > accessible fashion. Given that such accessibility can technically be
> > achieved I have difficulty seeing why banning layout tables anyway is
> > deemed acceptable.
> >
> >
> > Olaf
> >
> >
> >
> > On 29 Jan 2014, at 21:26, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> > > On 29 January 2014 20:00, Olaf Drümmer < = EMAIL ADDRESS REMOVED = > wrote:
> > >
> > >> I actually do dispute that. HTML 5 even tells you how to do layout
> > tables:
> > >
> > >
> > > patrick is right, tables are for data, that is the semantics they
> convey,
> > > when the normative advice in the spec is ignored one repair technique
> is
> > to
> > > remove the semantics with role=presentation.
> > > HTML5 says<
> >
> http://www.w3.org/html/wg/drafts/html/master/tabular-data.html#the-table-element
> > >
> > > :
> > >
> > > "Tables should not be used as layout aids. Historically, many Web
> authors
> > > have tables in HTML as a way to control their page layout making it
> > > difficult to extract tabular data from such documents. In particular,
> > users
> > > of accessibility tools, like screen readers, are likely to find it very
> > > difficult to navigate pages with tables used for layout. If a table is
> to
> > > be used for layout it must be marked with the attribute
> > role="presentation"
> > > for a user agent to properly represent the table to an assistive
> > technology
> > > and to properly convey the intent of the author to tools that wish to
> > > extract tabular data from the document."
> > >
> > > note the SHOULD NOT in the first sentence is a normative statement (as
> is
> > > the MUST in the third sentence). In other words use of tables for
> layout
> > is
> > > NOT RECOMMENDED, but the spec acknowledges that tables are misused and
> > > provides advice on a repair mechanism. This advice could probably do
> with
> > > strengthening and expanding.
> > >
> > >
> > >
> > > --
> > >
> > > Regards
> > >
> > > SteveF
> > > HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
> > > > > > > > > > >
> > > > > > > >
> > > >