Log in   Register a New Account

Accessify Forum - Discuss Website Accessibility

New to the forum?

Only an email address is required.

Register Here

Already registered? Log In

Examples of complex tables in the wild needed

Reply with quote I have no “automated” replies on my E-mail. I’ve just been really busy getting two @smedia presentations ready and trying to relax a little between them. Come talk to me in London if you’re gonna be there.

I’m running a search in BBEdit to see if I even used headers= before in real tables.
Reply with quote I can't afford @media events, otherwise I would do. Thanks muchly for responding. Smile

I've finished my first run through recoding the PDF/UA tables, including your Joe Clark Does the Movies table. Several of the original PDF/UA links had succumbed to linkrot. Error reports on my work from anyone are welcome.

The pdftables pictures aren't really big enough for the data to be legible to me.

(EDIT) Jake has expressed an interest in testing a table in HPR. I've asked for more than one, namely the Tide Table examples.
Reply with quote Just remembered something from my stats classes way back....

... isn't a Back to Back Stem & Leaf Diagram an obvious example of a table with row headings in weird places?
Reply with quote Conversation with Steve Faulkner over PM which others may be interested in:
Ben 'Cerbera' Millard wrote:
stevefaulkner wrote:
Ben 'Cerbera' Millard wrote:
stevefaulkner wrote:
If you intend on voting in this latest HTML 5 WG survey please do
before 2007-07-03.
Release "HTML 5 differences from HTML 4" as a W3C Working Draft?
http://www.w3.org/2002/09/wbs/40318/trdiff/
Thanks for reminding me. I voted "yes" because:
  • Fulfills the heartbeat requirement.
  • Merely documents facts and is accurate enough in doing so.
  • Introduces how the HTML5 proposal differs technically from current widespread standards, making it suitable as a first publication.
  • Is not binding and does not lock us into the current feature set. As the HTML5 proposal changes, so will this document.
I see you've formally objected to it. It's just a draft. It will be changed as the spec changes (such as when the Editors come to review table accessibility features, etc). Rationales and stuff can be added after first publication.

If HTMLWG doesn't publish anything, it could get shut down. And then where will the future of HTML accessibility be?
hi ben, understand your views, don't agree though.
the document will get published and the HTML WG has no chance of being shut down. And hopefully the document will published clearly reflecting the disputed status of the accessibility supporting attributes.
I think you are giving too much significance to this publication. It's just Anne's "Editor's Draft" about differences between HTML4 and the HTML5 proposal. Published it as a "First Working Draft" is basically to say "Hi, Tim. Don't worry, we are actually doing stuff...but it's early days yet." Smile

Rationales and stuff cannot be added at this stage because we have to publish something now. Any substantive changes would need the survey to restart, meaning another delay which jeopardises the WG's status at W3C.

We could contribute to the next version of the document by finding the rationales already given on the WHATWG mailing list and summarise them on the ESW wiki in an unbiased way. Send suggested text to the mailing list which would satisfy your objection if Anne pasted it into the document. This new version would be published if agreement was reached after a new survey.

Bear in mind HTML5 will take years to produce. All the features in the current HTML5 proposal are rough and subject to change; especially the accessibility stuff! (Ian Hickson has clarified this in recent messages to the list.)

<soap box>
Our (i.e. the accessibility community) efforts are best focussed on doing unbiased research into the various proposed and existing solutions for making data tables usable in ATs. Suggesting spec text which better describes how the current implementations work would be another constructive thing to do. Taking surveys on web forums of what approaches authors currently do and whether they would like to spend more or less time doing it would be another. Testing and documenting authoring tool support for the various table techniques is yet another.

There's lots of things we can be doing (if we can find the time!) which will help improve the Editors' decisions when these sections come under review.

Blocking the WG's process now, when it's such early days, seems a bit drastic to me. If the HTML5 spec were being published as a Last Call Working Draft or something, I could understand blocking it over inadequate support for accessibility. But it's not even in the /TR/ area yet! Razz

When the Editors get around to reviewing the affected sections of the spec (probably won't even be this year) they'll use the research we've conducted (with assistance from WAI, which is already happening) to inform their decision on what approach the spec will take. This will eventually prompt a new version of the HTML5 proposal to be published as a Working Draft, which can then be reviewed by us. We could suggest spec text which better matches current implementations; we could find existing content which the spec doesn't accomodate and suggest better spec text or cite current implementations which do support it; etc.

It's a lengthy process, but it's iterative. We can influence the process by contributing constructively, i.e. with actual work rather than rhetoric. I'm finding it very hard to set time aside to do this but it's what we need to be doing to be effective in making HTML5 accessible. If the accessibility still sucks at Last Call, that would be the time to kick up a fuss (imho).

I think research from level-headed and learned industry experts (such as yourself) will be the most helpful thing we can do over the next year or two.
</soap box>
I thought about fixing my typos and weird word order, but figured I'd leave it verbatim for integrity.
Reply with quote Hi Ben, first off it would have been courteous to ask me if i wanted my private messages published.

ben wrote:
I think you are giving too much significance to this publication. It's just Anne's "Editor's Draft" about differences between HTML4 and the HTML5 proposal. Published it as a "First Working Draft" is basically to say "Hi, Tim. Don't worry, we are actually doing stuff...but it's early days yet."
....
Blocking the WG's process now, when it's such early days, seems a bit drastic to me. If the HTML5 spec were being published as a Last Call Working Draft or something, I could understand blocking it over inadequate support for accessibility. But it's not even in the /TR/ area yet!


Each step that is taken with the status of the dropped elements not being questioned, will be a further entrenchment of their current status.

I have no intention of blocking, just ensuring that the disputed status "dropped" of the attributes in question is included (as is the status of the style attribute).

If the significance of the draft is minor, then there should be no problem with adding a bit of extra info into the document.


ben wrote:
There's lots of things we can be doing (if we can find the time!) which will help improve the Editors' decisions when these sections come under review.


Agreed, and I have been doing research/testing and adding it to the ESW wiki.

text of my answer to the questionaire "Release "HTML 5 differences from HTML 4" as a W3C Working Draft?"

steve faulkner wrote:

formal objection

Rationale:
The "HTML 5 differences from HTML 4" Editor's draft 25 June 2007 does not
provide a rationale for the dropping of the summary, headers and longdesc
attributes and does not provide any information regarding changed or new
elements and attributes that will provide the same or similar
accessibility features to the attributes being dropped. The arguments for
and against the dropping of these attributes are currently being debated
by and have been detailed by members of the working group[1] Also it does
not adequately document the dropping of these attributes as being open
issues within section "1.1. Open Issues"

As per the Formal Objection Guidelines[2]I propose that the "HTML 5
differences from HTML 4" document be modified to clearly indicate the
rationales for dropping the attributes in question and their status as
being open issues, both in "1.1. Open Issues" and in "3.6. Dropped
Attributes" section.

Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Reply with quote
stevefaulkner wrote:
Hi Ben, first off it would have been courteous to ask me if i wanted my private messages published.
Sorry Steve. I thought that since you've been discussing this publically at length on the mailing list you wouldn't mind, but in retrospect you're right and I should have asked. Embarassed

If it's just "a bit of extra info" you want then making a Formal Objection is kind of a "nuclear option", don't you think? There will be more versions of Anne's draft after this first one; the text you want added could be pasted into the next version.

Incidentally, does the second list item in the "Open Issues" section cover what you want?
Anne van Kesteren wrote:
1.1. Open Issues
HTML 5 is still a draft. This means that the contents of HTML 5, as well as the contents of this document as they depend on HTML 5, are still being discussed on the HTML Working Group and WHATWG mailing lists. Some of the open issues include (this list is not exhaustive):
  • De facto semantic definitions for some formerly presentational elements.
  • Details of accessibility and media-independence features.
  • The style attribute
  • The repetition model
(source: HTML 5 differences from HTML 4: Open Issues (version 1.25).)
That's the version which is being proposed as a First Working Draft and it's saying the accessibility stuff is an "open issue".
Reply with quote Hi ben,

ben wrote:
Incidentally, does the second list item in the "Open Issues" section cover what you want?


If it named the attributes it would suffice:

example wrote:
Dropping of the headers, longdesc and summary attributes.


ben wrote:
If it's just "a bit of extra info" you want then making a Formal Objection is kind of a "nuclear option", don't you think? There will be more versions of Anne's draft after this first one; the text you want added could be pasted into the next version.



I have not been involved the W3C WG process much, so am not aware that a "formal objection" is the 'nuclear option'. I read the "W3C Process Document" before deciding on lodging a formal objection rather than just a no, because I wanted to ensure that at least the core of my concerns are addressed. Reaching a compromise position where the issues are officially recorded right from the start, is my goal.

Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Reply with quote Dan Connolly has started a thread called some thoughts on objections to publishing ""HTML 5 differences from HTML 4" on the public-html list for the WG to discuss the current objections.

Henri Sivonen wrote:
On Jun 29, 2007, at 23:33, Robert Burns wrote:
This document does not reflect the work of this WG.
It only needs to reflect the *current* diff between HTML 4.01 and the HTML 5 *draft*. It tells how things *are* given the current state of the *draft* not how we want them to end up.
I'd like to see this document avoid rationales entirely, making it like a quick reference guide to the current HTML5 draft.

The accessibility features are already described as "open issues" in the document. A rationale cannot be provided for them because no decision has been made.


Last edited by Ben Millard on 30 Jun 2007 08:42 am; edited 1 time in total
Reply with quote Um ... the last few posts don't make much sense to me. I'm really not well up on the inner workings of the W3C.

Could you maybe explain in simple terms what is going on, and how folks like me could help?
Reply with quote OK, that's a good question. Smile

The HTML Working Group (HTMLWG) needs to publish something (a First Public Working Draft) to show W3C Management that we are doing actual work as well as inviting more feedback and review. This is the Heartbeat Requirement.

There were a few documents produced by Editors which were candidates for this:
As HTMLWG has already needed an extension to the heartbeat, publishing something is somewhat urgent.

The differences document was expected to cause the least disagreement amongst the 483 Participants since it is merely reporting facts about the current HTML5 proposal and is not binding the HTMLWG to any particular feature set. Dan Connolly created Release "HTML 5 differences from HTML 4" as a W3C Working Draft? to formally gauge support for publishing it. It remains open to HTMLWG Participants for new responses (or for respondents to edit their responses) until 3rd July 2007.

At the time of this message, there were 2 "No, disagree" responses and 3 Formal Objections. One of the Formal Objections was from Steve (he's quoted it further up).

I'm not sure there's anything you and I can do about it. It's really up to those who objected to provide the solution since they have the best understanding of their reason for objecting. This includes providing text which would satisfy the technical reasons for their objection when pasted into the document, for example. Steve has suggested text but his objection wasn't on technical grounds, AFAICT.
Reply with quote Thanks, that makes a lot more sense now. Smile

So ... we should watch and wait? Or are we still meant to find lots of complex tables in the wild?
Reply with quote
Cerbera wrote:
The accessibility features are already described as "open issues" in the document. A rationale cannot be provided for them because no decision has been made.


They are not explictly detailed as the style attribute is. what I have proposed is they are EXPLICITLY listed as open issues, so that going forward it is clear that the decisions to drop them have not been made by the HTML WG even though they were made by the WHAT WG.

It is disingenuous to say that "a rationale cannot be provided because no decision has been made", decisions were made to drop the attributes in question prior to HTML 5 being adopted by the HTML working group. The appropriateness of these decisions are being actively debated within the HTML WG.

Steve Faulkner
Technical Director
TPG Europe
The Paciello Group | Web Accessibility Tools Consortium
Reply with quote Laura, Collecting complex tables is still a productive contribution, AFAIK. Researching AT support for HTML4 table accessibility features such as summary and headers are as well, which is the area Steve has done a lot of work in.

Steve, neither WHATWG nor HTMLWG decided to exclude these features. This is a misconception I had when I started following their work, too. "Accessibility features" are "EXPLICITLY listed as open issues" by the differences document, which obviously includes the accessibility features we're concerned about.

Ian Hickson (an HTMLWG Editor and generally considered the spokesman for WHATWG) has clarified these things on the HTMLWG list:
  • The most specific description about accessibility features I've read was on Fri, 29 Jun 2007 21:03:02 +0000 (UTC). (A complete solution to handle accessibility use cases wasn't and hasn't been made.)
  • The highly unfinished and therefore flexibile state of the HTML5 proposal was explained succinctly in his message Re: How to productively contribute. (Search for "Good lord, no" and how it relates to the preceding quote.)
It's hard to keep track of the mailing list discussions. In fact, it's pretty much impossible! Smile That's why it's super important we don't take drastic action (like lodging a Formal Objection) before having a really thorough understanding of the situation, imho.
Reply with quote
Cerbera wrote:

(EDIT) Jake has expressed an interest in testing a table in HPR. I've asked for more than one, namely the Tide Table examples.



(a) The first thing to say is that none of the variations of the table presents any real problems with navigation.

(b) Unfortunately, none of the variations contain a 'summary' entry or 'summary' content that would prevent me from having to perform an initial scan of the table headings to tell me about the format of the table.

So. An initial scan is carried out:

http://www.moondemon.co.uk/tables/initial.mp4 (154k)

... at which point I know that the table consists of three main column divisions:

i. A date
ii. High water values
iii. Low water values

Each of the High and Low water values are further broken down into two time and height values.

As an example of how the markup affects what the reader speaks, here is a sample of what I hear (slowed down):

(I will use the first column to locate June 3rd, and then 'tab' across the row to listen to the data. I don't need to hear all the date -- so there will be some 'skipping' until I get to June 3rd).


minimal:
http://www.moondemon.co.uk/tables/minimal.mp4 (228k)

original:
http://www.moondemon.co.uk/tables/original.mp4 (155k)

scope:
http://www.moondemon.co.uk/tables/scope.mp4 (222k)

scope_abbr
http://www.moondemon.co.uk/tables/scope_abbr.mp4 (198k)


'minimal' is an interesting one.

If I listen to data for the month of May, I get a much more comprehensive header output than for June. It seems that the '<th>June' partway through has reset the headers.

Listen to one for a date in May:
http://www.moondemon.co.uk/tables/minimal2.mp4 (118k)

As you can see, how you markup the table directly affects what is read out.

In this case, it's not too difficult to remember what the sequence of dates/times/heights represents. But if I have any doubts, I can always use the reader's capabilities to read out the headers associated with a particular cell

e.g.

I want to stop and find out what the sixth data cell for June 3rd represents:

http://www.moondemon.co.uk/tables/check_hdr.mp4 (98k)

i.e. 'Low water' / 'Height in Metres'


In general, not a difficult table to navigate with minimal header information.

(Note: This example is using HPR 3.04 -- your reader may/will differ)

.
Reply with quote Outstanding, thanks for that Jake! I look forward to going through this in detail. Smile

It's quite possible I smegged up the markup in places, although I tried especially hard to make those ones perfect for more accurate test results.

Display posts from previous:   

Page 2 of 3

Goto page Previous  1, 2, 3  Next

All times are GMT

  • Reply to topic
  • Post new topic