- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 20 Dec 2008 09:21:53 +0000 (UTC)
- To: 'HTML WG' <public-html@w3.org>
This is an omnibus reply to feedback sent to a variety of mailing lists.
To reduce the level of cross-posting I have only sent this e-mail to the
HTMLWG mailing list.
Summary:
* Header cells can now themselves have headers.
* I have reversed the way the algorithm is presented, such that it starts
from a cell and reports the headers rather than generating the list of
headers for each cell on a header-by-header basis.
* If headers="" points to a <td> element, the association is set up,
but I have left this non-conforming to help authors catch mistakes.
* Header cells that are automatically associating do not stop
associating when they hit equivalent cells unless they have also hit
a <td> first.
* The "col" and "row" scope values now act like the implied auto value
except that they force the direction.
* Empty header cells don't get automatically associated.
* I have removed the wide header cell heuristic.
* I have made headers="" use the same ID discovery mechanism as
getElementById(), to avoid implementations having to support multiple
such mechanisms.
* Finally, I have made the spec define if a header is a column header or
a row header in the case where scope="" is omitted.
* I haven't added summary="" on table; nothing particularly new has been
raised on the topic since the last times I looked at this:
http://lists.w3.org/Archives/Public/public-html/2008Mar/0215.html
http://lists.w3.org/Archives/Public/public-html/2008Aug/0505.html
These changes, in particular the change to make header cells also have
headers, required massive changes to the header association algorithm. In
particular, it required the algorithm to now make a decision about whether
cells are column headers or row headers -- before, all "auto" cells were
both, and it all worked out fine because if a header cell was on a row
with no data cells, you couldn't tell it was acting as a row header. Now,
however, the algorithm has to decide which header cells are which.
Thus, the algorithm is likely going to support far fewer table types
without attributes, which is going to result in a net decrease in the
number of tables that are accessible. In order to determine if making
moderately complex tables inaccessible is a price worth paying to make the
more complex tables (where headers are headers for other headers) more
accessible, it would be helpful if this algorithm could be independently
implemented and tested on a sample of real tables on the Web.
On another note, I have found that it is much more helpful if feedback can
be in the form "as defined, I can't do this with HTML5" rather than "HTML5
should have this". For example, "I can't describe the structure of my
table in HTML5 in a conforming manner" is better feedback than "HTML5
should have a summary="" attribute on <table>". Similarly, "I can't write
a conforming HTML5 table for this data that works in an accessible fashion
in JAWS today" is more useful feedback than "HTML5 should have a
headers="" attribute on <th>". Feedback detailing a problem is
significantly more likely to result in changes to the spec that address
your needs than feedback that requests a specific change. This is because
I can't evaluate how well we are addressing problems if all I have is a
request for a solution. With a request for a problem, I am much more able
to objectively assess how well each solution addresses the problem.
Ben's research was instrumental to the changes made here; his research
probably had more of an effect on the spec than all the other discussions
put together. I cannot emphasise enough how much more important objective
analysis and logical argumentation is compared to opinions and assertions.
TABLE HEADERS
(I have omitted a number of e-mails that did not bring any data to the
table, so as to avoid repeating myself in this reply.)
On Thu, 21 Aug 2008, Laura Carlson wrote:
>
> We request that the definition of the headers attribute in the spec be
> extended to allow it to reference a td. This would make it possible for
> complex data tables to be marked up accessibly.
This seems wrong; how can a cell that isn't a header be a header? What
kinds of tables can't be written without this?
On Fri, 22 Aug 2008, Al Gilman wrote:
>
> The crux of the matter is that the (highest and best) meaning of
> 'header' in <th> and in @headers is subtly different.
>
> 1) in <th> 'header' contains metadata pertinent to a collection of other
> cells
>
> 2) in @headers, the IDs in the attribute lead you to context
> characteristics critical for orientation
I think this is misleading because even without headers="", <th> can
orient the user through the use of implicit associations.
> In doing HTML4, we were operating in a world where the main use by
> actual authors of <th> was to control styling of cells. Not
> mathematical subtleties of Codd and Date (relational database theory).
> In the spirit of "pave the cowpaths" I think we should preserve 1) above
> as the concept for the use of <th> because this is the rule that makes
> most sense in terms of what cells one wants to style with the same
> stylistic distinction from the run-of-the-data cells.
I don't really understand how this is different than what the spec does.
> The other aspect of this is a touch of "be strict in what you emit, but
> lax in what you accept." There is not fundamental semantic dividing
> metadata from data. It's all a matter of perception. So let the author
> cast to <th> those things they want to emphasize for orientation of the
> visual user and let @headers pick up the slack for the non-visual users.
IMHO this kind of reliance on bold-on accessibility aids instead of using
the same semantics for all users is a major source of accessibility
problems. It assumes that authors are willing to write accessibility
annotations, which has repeatedly been shown to not be the case.
> Reasoning from @headers as a way to discover wrongly-typed cells is
> virtuous. But not insisting that the author change the element type just
> because @headers points there, or drop the cell from the list of
> @headers targets.
The idea is to help authors find errors that they did not intend. All of
the authoring rules in HTML have that, and basically only that, as their
purpose. We want authors to be able to use validators as a QA tool to
catch mistakes they make, such as accidentally pointing a data cell to
another data cell instead of to the header cell that they intended.
On Sat, 23 Aug 2008, James Graham wrote:
>
> I think the absolute simplest message that we can give authors is "mark
> up your table headers as <th>". It is then our job to make sure as many
> tables at this lowest end of the accessibility learning curve work
> correctly as possible. The next simplest message is "sometimes your <th>
> needs a scope attribute to make it apply to the right cells". In many
> cases this will be a simple tweak that just helps to make some parts of
> the table slightly more understandable. Comparatively using @headers,
> even when all headers are marked as <th>, is really complex and
> something that should be reserved only for the cases where it is needed.
> There is lots of scope for author error and hence user frustration.
> Trying to add on top of that the message "sometimes your header cells
> should be marked up <td> and you should use @headers even though it
> would work without @headers if you just used <th>" is like kicking out
> the bottom two sections of the accessibility learning curve and asking
> authors to scale a vertical wall to the top. Adding complex, abstract,
> and occasionally counterintuitive, rules about when <td> should be used
> and when <th> should be used is like adding greasepaint to that wall.
Hear hear.
On Mon, 25 Aug 2008, Robert J Burns wrote:
>
> I think the HTML5 draft should also make it clear [...] that to be
> conforming a headers attribute idref must reference either a TH or TD
> element's id attribute within the same table and sharing at least one
> indexed slot (as this term is used in the current draft) in common. This
> is a machine-verifiable conformance criterion that should help prevent
> many common headers errors.
This would prevent corner cells in row groups from being associated via
headers="", which seems bad.
On Wed, 29 Oct 2008, Aaron Leventhal wrote:
>
> On this part:
> "If there is a header cell in the table whose corresponding |th| element
> has an ID that is equal to the value of id, then assign the first such
> header cell in tree order to the data cell."
> I don't want to implement a special local table only getElementByIdIn-
> Table. I'd rather have this reworded to something like "If there is an
> element in the document with a corresponding ID (via getElementById)
> equal to the value of /id/, and it is a header cell in the current
> table, then assign it to the data cell."
Done.
> 2. The larger part of algorithm is upside down for our needs. I see a
> use case for providing what headers are associated with a cell, but not
> the other way around. Typically an AT will want to know what labels or
> headers to present to a user when a user navigates to a cell. Therefore,
> I wish the entire algorithm was flipped and tells us what headers are a
> match for a given cell.
Done.
> 3. The one piece of information we do need when we are on a given <th>
> is whether to expose it with ROLE_ROWHEADER or ROLE_COLUMNHEADER in our
> GetRole() implementation. If scope isn't "row", "rowgroup", "col" or
> "colgroup" then we'll need to base that on the position in the table. It
> seems fairly obvious if the <th> is in an edge (but not corner)
> position, but other cases are less obvious.
I've added this too.
On Sat, 22 Nov 2008, Henri Sivonen wrote:
>
> While implementing a special lookup method is something that one would
> want to avoid, using getElementById [...] makes the association brittle
> under copy and paste. Consider a case where a page author creates a
> table with internal id references and then a maintainer duplicates the
> table and edits the contents of the copy table. Now the table coming
> later in the document order is inaccessible but this brokenness is
> unobvious to a person who isn't accessing the page with AT.
That's true, but the same applies to other uses of id="" and we haven't
worried about it before, so...
On Sat, 22 Nov 2008, Henri Sivonen wrote:
>
> [...] wouldn't testing if the cell is in the current table already go a
> long way towards the complexity of implementing getElementByIdInTable?
No, much of the complexity is in creating the hash table for the IDs.
On Mon, 24 Nov 2008, Joshue O Connor wrote on behalf of the PFWG:
>
> - general agreement that it is desired to improve ease of authoring from
> the current state of affairs. Currently only @headers and not @scope and
> @scope-related algorithms are implemented widely enough on the client
> side.
>
> Due to the poor support for @scope, its use may impact negatively on the
> user experience for PWDs, when they interrogate complex data tables.
> However, one can make all the necessary cell associations (using
> header/id combinations) in a way that does improve the user experience
> for PWDs, but with the draw back for authors that this process is a
> little more complex.
>
> - general expectation that if client software implements algorithms that
> use @scope, cell position, and @headers well, an improvement in
> authorability and actual-use rates can be achieved without sacrificing
> functionality.
>
> - general sense that the 'smart headers' algorithm is pretty good, and
> better than what we had in the HTML5 draft as of 23 October.
The above all seems right.
> - general agreement that multiple levels of headers are part of the
> requirements, are in common use in the wild. Note that the present
> HTML5 draft does not cope with this.
Fixed.
> - the accessibility community expects the present capability to handle
> complex and irregular tables to be maintained, no loss of functionality
> or the accessibility community will resist.
Why doesn't the accessibility community want tables to be made simpler?
> * what elements can @headers point at, or what elements can be in scope
> of @scope?
>
> - no general agreement on specifics, but general agreement that there
> needs to be some widening of the possibilities from the current spec
> draft if 'chained header cells' are to be used as the markup for
> multiple levels of headers in a table. To achieve the necessary
> connection topology, intermediate chained cells could be <th> or <td>,
> it can be made to work either way. This is an area for further
> refinement not resolved at the F2F meetings.
The spec now allows td->th and th->th, reporting one level deep.
> There has bee some concern voiced about the potential for cyclic
> references if chained headers were allowed in the specification. This
> seems to some degree to be unfounded. The relationship between a header
> and any corresponding chained/nested/ conceptual header that follows it
> is uni-directional and not bi-directional. This also follows if the id
> of a <td> cell is to be referenced from a chained header.
The worry was of a uni-directional cycle. I have side-stepped the issue by
not going more than one level deep.
On Tue, 25 Nov 2008, Robert J Burns wrote:
>
> One thing I've recommended before is that we require the headers
> attribute to only reference cells before themselves (the referenced cell
> has to make sense as a header cell for the referencing cell). In terms
> of document conformance this could be confined even tighter. In terms of
> processing conformance, UAs must only process headers attributes that
> reference prior cells in tree order. All other headers attribute values
> must be ignored (i.e., those referencing cells that follow in tree
> order). We could also add that headers cannot reference cells in the
> tfoot element for completeness.
I've seen a number of tables that have headers down the middle column
applying left and right, which would break with this idea.
On Mon, 1 Dec 2008, Ben Millard wrote:
>
> I have published my comparison of the 2 algorithms:
>
> <http://projectcerbera.com/blog/2008/11/compare>
This is extremely useful, thanks.
I have implemented most of your suggestions.
On Mon, 8 Dec 2008, Aaron M Leventhal wrote:
>
> It's true, if we implement relationship caching, then running through
> the entire table and caching all the relationships at once would allow
> the current algorithm work. Mozilla currently does not cache accessible
> relations but there is an open bug for that.
Even with the new way the spec is written (cells->headers), you can still
cache it. However, it's likely less efficient if than the old algorithm if
you're going to do the whole table at once ahead of time.
TABLE SUMMARY
On Thu, 21 Aug 2008, David Poehlman wrote:
>
> Were I reading a text book full of complex tables online, I'd need
> summaries to guide me.
So would a sighted user, surely. I mean, when I'm reading a regular
printed text book, I need help to guide me to the right table. I use the
caption, generally, or the table index.
Why is this any different for other users?
Can you give an example of an actual Web page that uses summary="" in a
way that is actually useful to users of accessibility tools but is _not_
useful to visually-able users?
> The fact that bad summaries can be and are often written and that one
> blind person said they were useless does not constitute a reason for
> dropping summary from the spec.
It's one of the data points we have. I'm basing decisions on research, not
on opinions. Some of the other sources of data:
http://projectcerbera.com/web/study/2007/tables
http://projectcerbera.com/web/study/2008/tables
http://canvex.lazyilluminati.com/misc/summary.html
If the problem we're trying to solve is "users with visual disabilities
need help to understand what tables are about", then we can study the
current uses of summary="" to evaluate if it solves the problem. The
research I've seen so far pretty convincingly says it does not.
On Thu, 21 Aug 2008, Sailesh Panchang wrote:
>
> The summary attribute serves a very important function for non-visual
> users and could indeed be important to several sighted persons if it
> were rendered visually by user agents.
I agree, but how does this differ from the <caption> then?
> Certainly things like summary="This is a layout table" is the equivalent
> of alt="space".
I agree, such summaries seem highly irritating at best. Yet they appear to
be the most common summaries by orders of magnitude, if Philip's data is
any guide.
> The summary attribute is really useful:
> i. for complex data tables that use multiple level of column / row
> headers, where rows are grouped like in financial tables or statistical
> tables etc. A well written description of the table's structure that
> tells a user how the data is organized in the table helps a screen
> reader user quickly comprehend it and use the appropriate navigation
> style. If not well written say, by authors who do not know its purpose,
> then they will be anecdotal / frustrating depending on ones perspective.
Do you have any examples of people using it this way, in a way that would
not also be helpful for sighted users?
> ii. for revealing key trends or cell values that can be discerned
> visually or to direct attention to particular rows / columns of values.
> This could be useful in complex tables as well as for large
> 2-dimensional tables
Wouldn't this be useful for all users?
> The summary attribute is in the HTML4 specs for a purpose and until
> there is an alternative feature by which user agents and assistive
> technology can expose that info to users for whom it is required, the
> attribute should not be shown the door.
It seems there are at least two alternatives: <caption> and <p>. That is,
show the helpful text to all users, either as a table caption or in prose
before the table.
On Fri, 22 Aug 2008, Ben Boyle wrote:
>
> is this an opportunity to suggest <summary> again? it is proposed in
> XHTML2 as a child element of tables (like caption), as opposed to the
> attribute from HTML4.
>
> I see two key benefits in a summary element for authors:
>
> 1. it's a way to associate summary information that you want to be shown
> (visually) with the table (as opposed to having summary information
> contained in a sibling of the table). caption works this way. this is
> accessible to all. I have concerns that using @summary today is, by
> default, inaccessible to the average sighted user. I intentionally avoid
> it for this very reason and encourage other authors to do the same.
Why doesn't <caption> solve this case?
> 2. it is easier to educate authors to care about what they can see.
> Element content trumps attribute content any day (for ease of authoring,
> reviewing etc.). We can talk about the ideal professionalism of authors
> if you want, but the low barrier to authoring HTML is a huge contributor
> to its success. I'd like to embrace it.
I agree that making accessibility aids visible to all users is the way to
go. I don't see that it needs a <summary> or summary="" feature though;
<caption> and title="" seem quite adequate for the task.
> I know a visible summary doesn't address the need to place additional
> information in an attribute that is more or less 'reserved' for screen
> readers. Personally I don't agree there is any such need. If a summary
> is useful, it's useful to everyone.
I agree -- accessibility of content to disabled users is as important as
accessibility of that same content to those without disabilities. Why
should we show content to one group but not the other?
> Simply put, I am asking for flexibility in the HTML language,
> specifically a container element for summary information. Of course, I
> can whack it in the caption:
> <caption>
> Table title goes here
> <small>A visible summary can go in here</small>
> </caption>
Why is that not good enough?
On Thu, 21 Aug 2008, Joshue O Connor wrote:
> Ian Hickson wrote:
> > It would be quite useful to see how poorly-sighted users, especially
> > those who aren't necessarily computer experts like us interact with
> > pages that are primarily intended to be about an image or another, for
> > example viewing albums and uploading photos to Flickr, Picasa, etc. I
> > wouldn't presume to request such studies, but if you are interested in
> > doing other usability studies, this is something that has the
> > potential to be quite interesting.
>
> I am glad that you interested in my doing some more usability testing
> analysis of the @summary etc. However I can't help but feel that to some
> degree I could be chasing my tail in doing so. The advise from PF is
> pretty unambiguous as are the comments of the many others who have
> expertise in the accessibility domain who feel @summary should be
> re-instated. [1] [2] [3] [4]
I understand that this flies in the face of tradition at the W3C, but for
the purposes of HTML5, I have been using, and continue to use, the results
of research and logical argumentation rather than relying on the advice of
experts. As previously noted, I am very grateful for your own research, as
well as Ben's substantial work. However, the e-mails you quote on the
whole do not consist of new data, but instead merely assert the usefulness
of the summary="" feature as a conclusion without explaining how this
conclusion was reached.
> [1] http://lists.w3.org/Archives/Member/wai-liaison/2008Aug/0009.html
Replied here:
http://lists.w3.org/Archives/Public/wai-xtech/2008Aug/0138.html
There has not been any further research done to back up the points made in
the e-mail you numbered [1].
> [2] http://lists.w3.org/Archives/Member/wai-liaison/2008Aug/0039.html
> [3] http://lists.w3.org/Archives/Public/public-html/2008Aug/0509.html
> [4] http://lists.w3.org/Archives/Public/public-html/2008Aug/0511.html
Replies to substantial points made in those e-mails are contained in this
e-mail.
> I will consider it however, time willing, as more use cases of sample
> data tables with @summary being used by a variety of AT users would I
> hope finally help resolve this issue.
Certainly it would be very helpful to have more data on this topic.
> > > I am hesitant to include a feature like summary="" when all evidence
> > > seems to point to it being widely misused by authors and ignored by
> > > the users it intends to help.
>
> It's not ignored by the users it intends to help.
How do such users deal with the broad mis-use of the attribute? What do
these users, upon first navigating to this site, hear?:
http://www.frontlinesourcegroup.com/
> It is a very useful attribute that has helped people access and
> understand data tables easily without having to interrogate them deeply
> - only to discover the table may contain data they don't need. In my job
> I have seen @summary help people in their work and have a positive
> impact on their lives.
Would such cases have been equally helped by including that information in
a <caption> instead?
On Thu, 21 Aug 2008, Karl Groves wrote:
> >
> > I am hesitant to include a feature like summary="" when all evidence
> > seems to point to it being widely misused by authors and ignored by
> > the users it intends to help.
>
> The notion that the decision to keep or eliminate an attribute based on
> whether it gets misused by authors is amazingly illogical. I would
> challenge the author to eliminate every element and attribute which is
> "widely misused" by authors.
By and large, we have, at least for the features where misuse results in
the feature being effectively useless. If you have a counter-example,
please do let us know.
> For example, I am currently developing a tool which crawls web pages and
> performs an automated accessibility check on each page. During recent
> unit testing, I set the crawler to test 1345 URLs on major websites.
> This resulted in the discovery of 200,298 errors.
Indeed, this is in line with data we have seen in other studies.
It would be quite useful to see aggregate numbers from this data, as it
might help us determine other changes we should make. If you could make it
available, that would be great!
> Admittedly, neither of these systems test *only* for validity of markup
> and are primarily focused on accessibility, but they do indicate quite
> clearly that the misuse of markup is rampant. So rampant, in fact, that
> "markup misuse" is a wholly irrelevant measure and should not be used as
> a criteria for whether or not an attribute or element should be kept or
> eliminated from the spec.
Markup misuse is rampant, indeed, but the key thing to consider in each
case is whether the misuse can be "routed around" or not. For example,
syntax errors can be detected and worked around, by defining how to handle
them (as we have done). Other errors, e.g. the wrong value in the title=""
attribute, aren't serious, as they tend to only happen on elements that
users generally aren't going to request the title="" for, and thus
title="" as a whole remains useful in spite of those errors. For
summary="", however, if the majority of uses are wrong in a manner that
cannot be detected by the UA, then it makes the feature as a whole less
useful, as it reduces the chance that the user will even attempt to access
the information in the cases where it _would_ be useful.
http://esw.w3.org/topic/HTML/SummaryForTABLE says:
>
> Vision impaired screen reader users listen to outputted information,
> without any visual cues, and HTML 5 currently lacks a mechanism that
> gives an overview of complex tabular data or a brief explanation of that
> data. [...]
There is an example given:
> "This table presents traveling expenses. In rows, you will find
> destinations and traveling dates, as well as grand total. In columns,
> you will discover expense categories as well as a total. Note that the
> first column contains merged table cells."
I have never seen a table with such a detailed summary (the examples of
sites using this in the wild back this up), but besides that, I am
concerned that I actually don't even understand the summary! For example,
I don't know if this means that the grand total is given as the last row
or the last column. It seems that as a blind user, I would find it more
helpful to have a caption and then to just walk around the headers of the
top row and the first column to see what kind of data is really there.
> Tables are an inherently visual way to display information of a fairly
> high density: especially with the use of borders, background colors and
> text/font attributes, particular relations of the data in the table can
> be quickly gleaned from a cursory glance at the table. For tables which
> possess these aspects, a summary is crucial for users who cannot
> visually consume the table as a 2-dimensional grid.
Such tables aren't accessible to visual users with style sheets disabled
either (e.g. myself when using a text browser). Using formatting in this
manner _in HTML_ is an abuse of HTML and is non-conforming. If the table
isn't a table but a graphical chart, then SVG would be more appropriate.
SVG, I am told, has much more thorough accessibility aids for this case
than <table> does, so this case is already handled.
> No set number of use cases proves a feature should be included or
> excluded from the spec. The W3C requires that technologies must be
> accessible.
_Ethical design_ requires that technologies be accessible. Accessibility
is one of the highest design priorities of the HTML5 effort.
> By definition, people with disabilities are a minority.
That's not at all correct (it's not by definition) but that's off-topic.
> Accessibility features address failure modes that are infrequent, but
> critical when they occur.
Agreed. This is not an argument in favour of summary="", though.
> The @summary technique may sometimes be used incorrectly but that is true
> of all markup.
See my earlier response to this (it's a matter of degrees).
> Failure by some to implement a standard is not in itself sufficient
> justification for getting rid of that standard.
Actually, it is, by W3C mandate (it's a requirement that all feature be
proven interoperably implemented for us to exit CR stage).
> The @summary technique provides functionality today. If it is to be
> worked out of the system, it should not be an abrupt drop. Transition it
> out with something better in an orderly and graceful manner.
HTML5 won't be a REC until 2022, according to my estimates; that should be
plenty of time for transition.
> Summary is to the visual construct table as "alt" is to the image
> element, and title and description are to SVG - necessary and required
> markup, so as to indicate to the non-visual user what is subconsciously
> absorbed by the majority of users, for whom it is merely a question of
> the ability to associate data with row and column headers.
I think this manages to simultaneously overstate the ease with which
people can read tables and understate the usefulness of a summary to
explain a table to users who don't navigate the table. Summaries as they
are written today for the few tables that have even remotely useful
summaries are not enough to understand the table, yet would be helpful for
users who can see the table. Users who can't see the table can still
navigate the headers to get their bearings; indeed that is how most such
users deal with all tables and they are quite adept at it.
> If use something outside the <table>, something other than
> table@summary, then that information isn't explicitly associated with
> the table (and it becomes more difficult for AT to make that
> association). This would be a problem for the many users of older legacy
> AT.
<caption> is associated with the table.
Also, people reading tables without reading the paragraphs before and
after the tables are often going to be confused regardless of the summary
or lack thereof. This applies equally to AT users as well as fully sighted
users.
> Summaries are especially useful for non-visual users. A summary of the
> relationships among cells is especially important for tables with
> complex relationships and may also be helpful for simple data tables
> that contain many columns or rows of data.
This is an assertion similar to the others I have already responded to.
> A summary makes it inexpressibly easier for someone processing a TABLE
> non-visually to get an over-view of a table, for what is a table, other
> than a visual means of displaying related data sets, and what the
> sighted user sees at a glance - the spatial relationships between cells,
> rows, and columns. In the absence of a summary, however, the aural user
> must investigate the table carefully and fully, merely in order to
> ascertain whether or not it is the correct table, what information the
> table contains, if the information in the table is germane, how many
> rows by how many columns to expect, the flow of the table, etc.
The list of things that this point asserts can be found in a summary is
longer than most summaries! I think again this is massively overstating
the benfits that summary="" brings in the real world.
> The summary attribute is essential to a non-visual end user who is
> interpreting the visual canvas with an aural renderer. It is to the
> non-visual or low vision user -- who is often forced to use a small highly
> magnified view port -- what the gestalt view is to a sighted user capable
> of making the correct spatial associations: an instant familiarity with
> the layout and flow of the table, which is constantly reinforced by
> visually interacting with the table. Obviously, this type of overview is
> impossible for a speech or refreshable Braille display user to obtain
> without entering and inspecting every table, whether or not that table
> contains the information for which the user is seeking. Without a summary,
> every table will entail extensive, tedious work on the end user's part
> because she: 1) has no foreknowledge of the table's layout; 2) has no
> foreknowledge / is unaware of the relationships conveyed by the table, for
> table-ized data (as well as layout tables) have meaning only insofar as
> one can visually and cognitively correctly correlate column and/or row
> headers, even if not they are incorrectly marked up (for example,
> indicated by a font-weight change or color change only).
This is the same as the previous point.
> @summary is very useful for inexperienced users of screen readers as it
> is announced as soon as the table has focus. The user therefore does not
> need to use complex keystrokes to interrogate the table in order to get
> an overview of whether it is useful or not.
The complexity of walking around the table is a bug in ATs, and not an
argument for summary="". It's not an issue intrinsic to HTML, so an HTML
feature is not a solution.
> Sometimes for visual effect an author wants to keep a page simple for
> visual users and still provide a mechanism for other non-visual users to
> consume content. The @summary mechanism is a simple way of achieving
> this.
Media queries in CSS are the way to solve this. summary="" only provides
one tiny way of addressing this, and cannot really be considered a
solution for the problem described here.
> @summary removes an obstacle to accessibility advocates promoting the
> use of HTML5. @summary will remain in use for accessible web pages until
> something better is available. Removal undercuts the HTML5 "use it now"
> story if what HTML5 authoring advice and the omnipresent
> accessible-authoring advice are in conflict. HTML5 doesn't need this bad
> press for a change from HTML4 that doesn't solve a real problem.
The alternatives being proposed don't rely on any new features, so they
can be used now too.
> Removing @summary was not solving a real problem. There is no browser
> savings from removing it; browser still puts it in the DOM if it's there
> and AT takes advantage.
This is correct, but again, not an argument for summary="".
> If a table is complex enough to require a description to understand it,
> then that description should be available to everyone (not only screen
> reader users).
Indeed.
> Summary is explicitly invisible metadata and therefore is more likely to
> be missing or inaccurate than data that is visible to all UAs.
Indeed.
> In many cases pages already include text that summarizes the contents of
> a table to the extent needed to identify whether the table is of
> interest; in order to allow non-visual browsers to easily scan a page, I
> would provide a mechanism to associate this text with the table. Authors
> wishing to provide extra information hidden from visual UAs (e.g.
> because it describes the table in a level of detail not required by
> sighted users) could use CSS to explicitly hide that information.
Indeed.
> A disability constituency currently uses and depends on this feature:
> anyone offering to remove it should be expected to demonstrate that the
> replacement works better and is in service.
I disagree with the premise of this statement -- if a feature is shown to
be flawed, then we should remove it regardless of whether we have a
replacement. However, in this case, that's moot -- <caption>, SVG, and the
other proposed alternatives all work find and are in service today.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
ISSUE-20
ISSUE-32
Received on Saturday, 20 December 2008 09:22:34 UTC