Examples of complex tables in the wild needed
Home / Site Building & Testing / Examples of complex tables in the wild needed
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.
Share: 
I can't afford @media events, otherwise I would do. Thanks muchly for responding. 
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.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
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?
Share:
Conversation with Steve Faulkner over PM which others may be interested in:
| Ben 'Cerbera' Millard wrote: | ||||||
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! 
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> |
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
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
Share:
| stevefaulkner wrote: |
| Hi Ben, first off it would have been courteous to ask me if i wanted my private messages published. |
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):
|
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
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
Share:
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: | ||
|
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.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Last edited by Ben Millard on 30 Jun 2007 08:42 am; edited 1 time in total
Share:
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?
Share:
OK, that's a good question.
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:
- HTML5 differences from HTML4 (version 1.25). Describes the differences between HTML 4.01 and the current proposed draft of HTML5.
- HTML Design Principles. Intended to set the direction discussions and decisions will take within HTMLWG.
- HTML5 (draft specification). The proposal from WHATWG which was formally adopted as HTMLWG's starting point.
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.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
Thanks, that makes a lot more sense now.
So ... we should watch and wait? Or are we still meant to find lots of complex tables in the wild?
Share:
| 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
Share:
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.)
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._________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
| 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/... (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/... (222k)
scope_abbr
http://www.moondemon.co.uk/... (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/... (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)
.
Share:
Outstanding, thanks for that Jake! I look forward to going through this in detail.
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.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Share:
All times are GMT
You cannot post new topics in this forumYou cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum