RE: Discussion: Accessibility Issues Procedure

On Sun, 26 Jul 2009, John Foliot wrote:
> Ian Hickson wrote:
> > 
> > Maybe I missed an important e-mail. Could you point me to the e-mail 
> > that shows the reasoning and data behind the idea that including and 
> > continuing to encourage authors to use the summary="" attribute would 
> > improve overall accessibility of the Web beyond the status quo?
> 
> While we are ferreting out misplaced crucial emails, can we also see 
> where it was 'decided' to make @summary obsolete, and to further counsel 
> content authors *NOT* to use @summary

No such decision has been made. (No decision to the contrary has been made 
either.) There is no formal working group text regarding summary=""; in 
the context of this thread:

   http://lists.w3.org/Archives/Public/public-html/2009Jul/0745.html
   http://lists.w3.org/Archives/Public/public-html/2009Jul/0766.html

...we are talking about changes to my draft proposal:

   http://www.whatwg.org/specs/web-apps/current-work/

...which currently has no normative status within this working group other 
than being called "HTML5", being edited by me, and having been published 
as a TR-page WD a few times.


> even though by W3C Charter this counseling is the responsibility of the 
> WAI?

That is not what the charter says.


> (And while you looking, can you also point me to the official consensus 
> note that suggested that deferring a captioning solution with video to 
> 'the next version' was met with approval? 
> http://lists.w3.org/Archives/Public/public-html/2009Jun/0667.html | 
> http://john.foliot.ca )

No such consensus exists at this time. (No consensus to the contrary 
exists either.)


> > The position argued, in detail, with data [1] to support the current 
> > text in the specification is that encouraging the summary="" attribute 
> > to be used actually harms the overall accessibility of the Web.
> 
> Can you point to WHAT WG / HTML5's definition of 'harm' and supporting 
> evidence that this harm is being inflicted?

In this context I used the word "harm" in its metaphoric sense meaning "to 
reduce" or "to lower". The supporting evidence was cited in the e-mail to
which you were replying:

   http://lists.w3.org/Archives/Public/public-html/2009Jul/0148.html


> > To my knowledge, nobody has provided a sound counter-argument to this. 
> > If I have missed such a counter-argument, please send me a link.
> 
> [...] http://esw.w3.org/topic/HTML/SummaryForTABLE
>
> I count no less than 27 different bullet points addressing why @summary 
> should be retained as a fully recognized attribute.

| Rationale: Why Summary Should Be Provided
|
|  1. 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.

This argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion.


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

The reasoning for believing that the five alternative proposals are 
expected to result in a more accessible Web are detailed here:

   http://lists.w3.org/Archives/Public/public-html/2009Jul/0148.html


|  3. A sighted person can see how table rows and columns are laid out and
|     where the cells merge by a quick scan or glance. They typically
|     wouldn't need an explanation.

Summaries are useful for far more people than just those who are not 
sighted, including many who are quite capable of seeing the tables in 
question. (Even if that were not the case, IMHO the benefits of getting 
authors to regularly see their summaries are likely to far outweigh any 
disadvantages to them being visible to all.)


|  4. Providing a summary visually would be extra verbiage that most
|     authors/designers would be reluctant to include visually on a page
|     because of redundancy.

Most authors appear even more reluctant to add a summary="" attribute of 
any use, so that would be an even stronger argument against summary="".


|  5. 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. By definition, people with disabilities are a minority.
|     Accessibility features address failure modes that are infrequent, but
|     critical when they occur.

These sentences seem to all be non-sequiturs, so I will respond to them 
individually:

|  5. No set number of use cases proves a feature should be included or
|     excluded from the spec.

This has no bearing on summary="", since it is not a feature, but a small 
component of a feature. (The feature is "complex table layout".)


|     The W3C requires that technologies must be accessible.

Whether it does or not, we have a moral imperative to ensure that we do 
not discriminate against segments of our population in designing the Web's 
language.


|     By definition, people with disabilities are a minority.

This isn't true (people with disabilities are a minority mostly because of 
a combination of luck and good medical practices, not by definition).


|     Accessibility features address failure modes that are infrequent, but
|     critical when they occur.

Accessibility features don't address failure modes at all, they address 
design mistakes that caused feature to not be intrinsically universally 
accessible in the first place.


|  6. The @summary technique may sometimes be used incorrectly but that is
|     true of all markup. Failure by some to implement a standard is not in
|     itself sufficient justification for getting rid of that standard.

Failure by an overwhelming majority to the point where the feature is 
essentially unusable by its target audience _is_ sufficient justification 
for readdressing the use cases of that feature.


|  7. A summary provides a reasonable accommodation. It enables a person
|     with a visual disability to have an equal opportunity. Not providing a
|     summary mechanism excludes people solely on the basis of disability.
|     Removing it would be discrimination.

This argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion.


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

The specification does not remove the feature. It remains conforming and 
user agents (specifically ATs) are expected to continue to support it.


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

This argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion.


| 10. If something outside the <table> is used, 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.

This argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion, which all have a clear and 
unambiguous semantic link to the table.


| 11. If something is intended to help non-sighted users comprehend a
|     complex structure, it's unlikely to help anyone else. The fact it
|     doesn't help anyone else doesn't detract from its usefulness.

This is a duplicate of point 3.


| 12. If something useful is misused, the solution would be to take steps to
|     ensure it is used properly, rather than removing it completely.

If something useful is misused for ten years even in the face of _legal_ 
requirements that it be used, we must consider whether taking steps to 
ensure it is used properly may in fact be a naive an ineffective approach.


| 13. A combination of training and better tools can address poor authoring
|     of the attributes value.

This is a duplicate of point 12.


| 14. 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 argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion.


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

This argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion.


| 16. 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 argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion.


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

This argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion, which all have this 
characteristic also.


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

This is a duplicate of point 3.


| 19. Including @summary solves a real problem.

This argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion, all of which solve the same 
real problem.


| 20. Including @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.

This point is moot given that summary="" is conforming in the proposed 
HTML5 draft.


| 21. A table summary is only content to the blind/nonvisual use case. To
|     everyone else it is just fluff and not needed. If others want access
|     they can use CSS.

This is a duplicate of point 3.


| 22. A table summary isn't of help other disability groups except the
|     blind.

This is a duplicate of point 3.


| 23. The attribute has been in HTML since HTML 4, there are some sites that
|     use it correctly, and the WAI community has recommended its continued
|     inclusion until at least a better replacement is deployed and stable.
|     "Evolution not revolution".

With one exception, the other proposed solutions already in HTML5 are also 
deployed and stable, and summary="" is still included in HTML5.


| 24. @summary is implemented most well known authoring tools, such as
|     Dreamweaver and Mozilla editors (SeaMonkey editor, Thunderbird, NVU).
|     Lots of text editors with syntax coloring (VIM, TextMate, BBedit etc)
|     will have to mark summary="" with a color that shows it as invalid -
|     if they want to conform to HTML 5. Some of the users of those tools
|     would complain if @summary was removed. Since the HTML5 specification
|     currently tries it's utmost to satisfy backward compatibility with a
|     wide range of junky web pages and vagaries of backward compatibility
|     with old browsers, it would seem reasonable to ask that consideration
|     also be given to users of existing authoring tools.

summary="" is not removed in HTML5.


| 25. The spec should allow for explicit associations of related pieces of
|     content if this association aids in conveying context and content
|     relationships to users, whenever implicit associations do not provide
|     this functionality.

This is unrelated to summary="", and is in any case covered by ARIA.


| 26. Ian Hickson wrote: "I think it's clear that summary="" could solve the
|     problem if used right." - February 24, 2009.

Unfortunately, as it is not used right, this is not of much use. It's also 
an appeal to authority, which is not a valid argumentation method.


| 27. Applicable Design Principles (Note: These 26 November 2007 principles
|     are only a draft. They have not gained consensus)
|        * Accessibility: "Design features to be accessible to users with
|          disabilities. Access by everyone regardless of ability is
|          essential. This does not mean that features should be omitted
|          entirely if not all users can make full use of them, but
|          alternate mechanisms should be provided. The image in an img may
|          not be visible to blind users, but that is a reason to provide
|          alternate text, not to leave out images."

This argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion.


|        * Media Independence: "Features should, when possible, work across
|          different platforms, devices, and media. This should not be taken
|          to mean that a feature should be omitted just because some media
|          or platforms can't support it. For example, interactive features
|          should not be omitted merely because they can not be represented
|          in a printed document."

This is actually an argument _against_ summary="", since it is 
media-specific.


|        * Pave the cowpaths: "When a practice is already widespread among
|          authors, consider adopting it rather than forbidding it or
|          inventing something new."

It was considered. But it doesn't work.


|        * Evolution Not Revolution: "Revolutions sometimes change the world
|          to the better. Most often, however, it is better to evolve an
|          existing design rather than throwing it away. This way, authors
|          don't have to learn new models and content will live longer.
|          Specifically, this means that one should prefer to design
|          features so that old content can take advantage of new features
|          without having to make unrelated changes. And implementations
|          should be able to add new features to existing code, rather than
|          having to develop whole separate modes."

The proposed alternative solutions are incremental changes and not 
revolutions.


|        * Solve Real Problems: "Changes to the spec should solve actual
|          real-world problems. Abstract architectures that don't address an
|          existing need are less favored than pragmatic solutions to
|          problems that web content faces today. And existing widespread
|          problems should be solved, when possible."

This argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion.


|        * Priority of Constituencies: "In case of conflict, consider users
|          over authors over implementors over specifiers over theoretical
|          purity."

This argument does not distinguish between the five suggestions listed in 
the HTML5 spec and the summary="" suggestion.


|        * Do not Reinvent the Wheel: "If there is already a widely used and
|          implemented technology covering particular use cases, consider
|          specifying that technology in preference to inventing something
|          new for the same purpose. Sometimes, though, new use cases may
|          call for a new approach instead of more extensions on an old
|          approach."

It was considered. But it doesn't work.


It seems to me that there is not a single one of those bullet points that 
comes even close to the kind of useful argument or data that I have 
mentioned would be necessary for me to change the text proposed in HTML5.



> I realize that you have a lot to read in any given day, but this document
> has been around for quite some time and is relatively stable.

I've read it several times. It does not address the points I have made.


> This is not new data.

It's not useful data either.


> Meanwhile, I respectfully request that you not impose your personal 
> opinion on @summary and restore it to a valid and current HTML attribute 
> - retaining its existing, current status as seen in both HTML4 and 
> XHTML1 (and not, instead, re-invent the wheel:  perhaps this faint cow 
> path simply needs more traffic and a coat of blacktop to be back on its 
> way)

I'm sorry, but I actually care about improving accessibility on the Web, 
and to keep summary="" conforming would, according to all the data that 
has been collected, fail in this goal.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 27 July 2009 07:08:47 UTC