SummaryForTABLE

From HTML WG Wiki
Jump to: navigation, search

Mechanism to Summarize a Table

This document is the deliverable for ACTION 66, ACTION 76, ACTION 104, ACTION 111, and ACTION 126 which are all bound to Tracker ISSUE 32.

Issue

Vision impaired screen reader users listen to outputted information, without any visual cues, and HTML 5 currently lacks a programmatically-determined mechanism that gives an overview of complex tabular data or a brief explanation of that data. In HTML 4 this often much needed information is provided via the summary attribute.

HTML 5 lacks a nonvisual explicitly associated, programmatic mechanism to provide a table with a summary for users who are can not see the visual rendering of the table. This feature provides an overview of tabular data or a brief explanation of how to navigate a data table for Blind/Non-Visual Users who use assistive technology (AT). This is because an AT user needs to easily form a mental image of a table's contents in order to better understand its structure, or semantic relationships. The mechanism needs to be explicitly associated with the table or it becomes more difficult for AT to make that association. A summary mechanism may seem irrelevant or redundant to those with good eyesight because they have access to content relationships at a glance. However for users with visual impairments, additional semantics are often needed as a vital aid to comprehension. These useful semantics, such as those supplied by @summary, are often the difference between "seeing" or "not seeing" the table as a whole. A summary mechanism therefore provides a 'quick scan' feature for non-sighted users that requires no complex user interaction beyond giving the table element focus.

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

Summary Example

<table summary="This table lists the 32 most significant floods
of the 20th Century grouped into 6 types of floods: Regional, flash,
ice-jam, storm-surge, dam-failure, and mudflow. The majority of the
floods (20) are listed as Regional floods. There are between one and
four floods in each of the other 5 categories. ">
<!-- Remainder of table -->

(Source: Significant Floods of the 20th Century)

A survey of existing web content showed that this attribute was rarely used, and, when it was, it was frequently misused, leading to the conclusion that it should be removed from HTML 5.

On the other hand, the attribute has been in HTML since HTML 4, there are sites that use it correctly, and the WAI community has provided advice in support of inclusion. Some long term solutions have been offered for growth to better practice.

Latest Published Draft

The current editor's draft

  • Discusses alternative mechanisms for providing a visible caption of the table.
  • Recommends against using @summary.
  • Makes it an obsolete attribute.

It says:

"The attribute on table elements was suggested in earlier versions of the language as a technique for providing explanatory text for complex tables for users of screen readers. One of the techniques described above should be used instead. "

  • The draft text applies table summary functionality universally, and in a such way that it is not possible to distinguish the summary from a caption.
  • Most of the debate around providing a summary mechanism has been about misunderstanding its purpose, so trying to merge its purpose with other elements' purposes may be problematic leading to more confusion.
  • The purpose of a caption element and the summary attribute historically have been completely different (caption titles the table, summary describes how the table should be read by people who cannot see how the table has been rendered).
    • HTML 4 states: "Each table may have an associated caption (see the CAPTION element) that provides a short description of the table's purpose. A longer description may also be provided (via the summary attribute for the benefit of people using speech or Braille-based user agents."
    • WCAG2's H73 Technique states: that a summary provides "a brief overview of how data has been organized into a table or a brief explanation of how to navigate the table."
  • Providing summary information visually by default would be extra verbiage that most authors/designers would be reluctant to include visually on a page because of redundancy. (For more info see sighted use case).

Status


Contents

Use Cases

Blind/Non-Visual Users

A programmatically-determined summary mechanism serves a very specific and most critical use for blind and non-visual users. It provides an affordance equivalent to the visual user scanning a table for spatial structure, orientation, and relevance. A summary mechanism provides a reasonable accommodation. It enables a person with a visual disability to have an equal opportunity.

A textual summary enables this user group to get an overview of a table without seeing the relationships between the rows and columns implied by its spatial structure. It is an essential aid to comprehension for the visually impaired. It provides the AT user a way to easily form a mental image of a table's contents in order to better understand its structure, or semantic relationships. When a screen-reader user in JAWS navigates in table mode, he can hear the summary of each table in a document with one key press.

In the absence of a summary, the non-visual 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 is a very tedious and time consuming process.

As the late John Slatin observed,

The <caption> provides a title for the table and is available to everyone. The summary makes it possible for blind users to gain information about the table organization or content that is readily available to people who can see the table - blind users often have to listen to the table for quite a while in order to gain the same understanding.

Source: Sailesh Panchang

Sighted Users

For the majority of sighted users a summary is not needed. For instance:

<table summary="Rows contain destinations, traveling dates, 
and grand total. Columns contain expense category and total. 
The first column contains merged table cells.">
<!-- Remainder of table -->

(Example based on Denis Boudreau's May 2007 Email)

A sighted person can see how the rows and columns are laid out and where the cells merge by a quick scan or glance. They typically wouldn't need an explanation. Providing it visually would be extra verbiage that most authors/designers would be reluctant to include visually on a page because of redundancy.

However, a summary could be of use to a sighted user with cognitive disabilities or lower-literacy populations. It might also aid universal design.

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.
  2. Assistive technology users who use shortcuts to jump straight to a table would miss information if the table summary information is provided in paragraphs not programatically associated with a table.
  3. 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.
  4. 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.
  5. Providing a summary visually would be extra verbiage that most authors/designers would be reluctant to include visually on a page because of redundancy.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. If something outside the <table>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.
  12. 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.
  13. If something useful is misused, the solution would be to take steps to ensure it is used properly, rather than removing it completely.
  14. A combination of training and better tools can address poor authoring of the attributes value.
  15. 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.
  16. 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.
  17. 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).
  18. @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.
  19. 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.
  20. Including @summary solves a real problem.
  21. 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.
  22. 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.
  23. A table summary isn't of help other disability groups except the blind.
  24. 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".
  25. @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.
  26. 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.
  27. Ian Hickson wrote: "I think it's clear that summary="" could solve the problem if used right." - February 24, 2009.
  28. 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."
    • 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."
    • Pave the cowpaths: "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."
    • 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."
    • 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."
    • Priority of Constituencies: "In case of conflict, consider users over authors over implementors over specifiers over theoretical purity."
    • 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."

Rationale: Why Summary Should Not Be Provided

  1. @summary was not solving a real problem. There is no browser savings from removing it. The browser still puts it in the DOM if it's there and AT takes advantage.
  2. 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).
  3. Summary is explicitly invisible metadata and therefore is more likely to be missing or inaccurate than data that is visible to all UAs. It is too media-specific.
  4. @summary hurts users who don't have access to it, hiding information that they might find useful. A summary could be of use to a sighted user with cognitive disabilities or lower-literacy populations. Ian Hickson wrote: "It seems like it would fail to help users that don't get access to it (like users of visual browsers)." - February 24, 2009.
  5. @summary attribute fails to improve accessibility in practice, despite being promising in theory.
  6. 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, 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.
  7. @summary is too difficult to author. PFWG charter injunction seeks technologies that are 'authorable' - conducive to getting good content within the defined markup, high usability and easy to author based on the formulation of content formats and service protocols.
  8. A survey of existing web content showed that this attribute was rarely used, and, when it was, it was frequently misused, leading to the conclusion that it should be removed from HTML 5.
  9. We should investigate any and all solutions that would help users (all users) understand the Web better.
  10. 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."
    • 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."
    • Pave the cowpaths: "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."
    • 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."
    • 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."
    • Priority of Constituencies: "In case of conflict, consider users over authors over implementors over specifiers over theoretical purity."
    • 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."

Advice Requests to PFWG

Advice From PFWG

August 6, 2008

Here is a summary of how PFWG sees the situation as regards @summary on <table> in HTML:

  1. @summary should stay
  2. It provides a needed service.
  3. Element content providing this info, *if linked by markup to the table* offers growth to even better practice.
  4. Don't have the linking markup yet; is a developmental item.
  5. Evolution not revolution says: keep @summary at least until alternatives are deployed and stable.

Source: RE: Request for PFWG WAI review of @summary for tabular data - Al Gilman, August 6, 2008.

June 4, 2009

The following consensus was reached by Protocols and Formats Working Group during its teleconference of Wednesday, 4 June 2009:

We request the table summary tag be restored in HTML 5 as per previous communications.

Rationale:

  • Summary serves a need, and serves it well. It is familiar to users. It is supported in browsers. It is properly utilized on many web sites which strive to be accessible.
  • If it didn't exist, we'd need to invent it. Indeed, such alternative approaches as have been proposed constitute a "reinvention" of summary. PF wishes to move on to address accessibility concerns in areas, such as canvas, where no good solution currently exists rather than reinventing summary.
  • We reject the argument that summary should be removed from the HTML specification because it is not implemented on most web sites. We note that accessibility is poorly supported on most web sites. The wider web is not an example of good practice.
  • We need summary for backward compatibility.
  • We note that summary is often used as a technique for accessibility support where governmental regulations require governmental web sites to be accessible. An example is the U.S. Government's Social Security Administration (SSA) pages as SSA conforms to its "Section 508." mandate:
  • If summary is removed, U.S. Government web sites, might find it more difficult to conform to HTML 5. We further note that Section 508 regulations apply to U.S. state and local governments, and that similar accessibility requirements are emerging in Canada, the U.K., the E.U., Australia, and elsewhere.
  • Restoring summary in HTML 5 would not, in our understanding, negatively impact HTML 5 in any way.

Source: PF Response: @Summary - Janina Sajka, June 3, 2009.

Steps to Implement PFWG Recommendations (Al Gilman, Nov 21, 2008)

  1. Restore @summary in HTML5.
  2. Add <summary> or equivalent in HTML5, meeting the programmatically-determined standard of WCAG (example: the proposed 'text in context' approach for providing text alternatives).
  3. Once WAI-ARIA is deployed, there is an interim solution for "summary in context" markup which uses @aria-describedby linking from <table> to an element containing the summary description.
  4. Once number 2 meets CR standard of two interoperable implementations, HTML5 authoring advice favors <summary> (or equivalent.) HTML5 document may mark @summary as "deprecated".
  5. Once number 2 meets "accessibility supported technology" standard of WCAG2, HTML5 may remove @summary (only then).

Proposed Solutions to Fulfill PFWG Recommendations

Short Term Solution

Reinstate @summary Now

Mid Term Solution

aria-descriebedby

  • Provides interim solution for "summary in context" until <summary> or equivalent is in HTML5.
  • Does not meet the programmatically-determined standard of WCAG.
  • aria-descriebedby could be used to provide a long description for the table, but that's not the purpose of the summary attribute.

Long Term Solution Possibilies

<summary> Element

Proposal by L. Carlson (based on Al Gilman's proposal)

  • Create a new <summary> element as suggested by PFWG to provide a concise table summary. Intent is to provide a brief overview of how data has been organized into a table or a brief explanation of how to navigate the table. See Gez Lemon's Purpose of the summary Attribute. "The purpose of the summary attribute is to concisely describe the structure of a data table. The summary attribute is not intended to provide a long description for data tables."
  • Require user agents to provide an option to reveal the content of the summary provides.
  • Could work alongside aria-descriebedby.
  • Restrict <summary> to only accept inline content such as abbreviations, emphasis, etc.
  • Summary attribute and summary element could be synonymous - summary as element would be preferred, but summary as an attribute would be a backwards-compatible fall-back. For backwards compatibility UAs could accept either @summary or <summary>, while the spec can encourage the use of the element in place of the attribute.
  • Related References:
Outcomes
  • Would address the Blind/Non-Visual Use Case.
  • Would provide Sighted Users who want the ability to expose the summary attribute content a way to do so via a preference or switch in browser.
  • Would solve the caption/summary confusion that one of the drafts introduced.
  • Requiring user agents to provide an option to reveal the content of the summary provides a practical method for developers who want a tool to check summary text and keep it up to date via a preference or switch in browser for testing purposes.
  • Would allow richer information.
    • The downside of that is that what was meant to be a concise overview of how the data has been organized may not remain a summary.
  • Would provide an i18n advantage. Language or text directionality can be supported in an element that allows in-line content.
  • Would meet the programmatically-determined standard of WCAG.
  • Could break existing content that uses the summary attribute unless summary attribute and summary element were synonymous.
  • Moving from an attribute to an element for a summary type mechanism would evolve an existing design rather than throwing it away. (Evolution Not Revolution design principle.)
  • Would address the other relevant design principles.

<summary> proposal Variation

Change summary from an Attribute to an Element

Media independent way to provide table info in the caption element

A media independent way to provide table info in the caption element

Make the table summary attribute valid, not obsolete, and conforming in HTML5

@summary or <caption><details>

@summary or <caption><details> Change Proposal Nov 18, 2009 by Cynthia Shelly

Details element as a replacement for summary attribute

Details element as a replacement for summary attribute, Feb 15, 2010 by Cynthia Shelly

<details> as a <child> of <caption> or <figure> <legend>

Summary Automatically Generated by User Agent

HTML 5 defines which headers apply to which cells, and obviously a user-agent knows which cells are merged, so possibly there could be an algorithmic way of generating descriptions of table structures for any (or at least a large proportion of) data tables. A user-agent could have a 'describe table structure' feature which is independent of an author providing a good (or indeed any) summary.

Outcomes
  • In terms of getting the information to those users who need it, this may have more success than engaging authors to write good summaries: user-agent developers seem on average more likely to follow the HTML 5 spec than most authors, and there are fewer of them.
  • If this were possible it would reduce the number of tables which require a handwritten summary, reducing the burden on authors.

Related Ideas to Increase Accessibility

<tdesc> or <tdescription> or <desc>

  • Create a new <tdesc> or <tdescription> or <desc> child element of <table> to provide a full description to work alongside @summary. It would be the element version of aria-describedby.
  • Would serve a different purpose than @summary. @summary would provide a concise description of the table's structure. <tdesc> or <tdescription> or <desc> would provide a long description.
  • Allow it to be a block-level element that allows block-level content.
  • Allow an "open" display attribute similar to the one on the <details> element that would allow it to be available not only to the vision impaired but also to the sighted on demand.
  • Related References:
Outcomes
  • A <desc> element could be extended beyond simply <table> and be repurposed where needed. (perhaps help with <canvas> or <longdesc> or <audio> or <video>).
  • Authors would understand a description element's purpose, increasing usability and authorability.
  • Would address the Blind/Non-Visual Use Case.
  • Because of the "open" attribute it
    • Would address a Sighted Use Case and could aid universal design.
    • Would be easy for authors (especially sighted ones) to comprehend which would lead to improved use.
    • Would be less likely to be inaccurate than data that is invisible to some UAs.
  • Would solve the caption/summary confusion that one of the drafts introduced.
  • Would meet the programmatically-determined standard of WCAG.
  • Would address the relevant design principles.

<details> as a child of <table>

  • Allow <details> as a child of a <table> to provide a full description to work alongside <summary>.
  • Would serve a different purpose than <summary> and @summary. <summary> and @summary would provide a concise description of the table's structure. <details>would provide a long description.
  • Allow "open" display attribute making content available not only to the vision impaired, but also the sighted and people with cognitive disabilities.
  • Related References:
    • details explanation from IBM
      • Each <details>element can have an "open" attribute. If it has this attribute, then the details will be initially shown to the reader. If it doesn't have such an attribute, then they will be hidden until the user asks for them. In either case, the user can click an icon or other indicator to show or hide the details. If <summary> and <desc> had something like that it could help sighted people with cognitive impairments and lower-literacy populations.
      • Explain how UAs are to update the <details>element in response to request - commit-watchers-whatwg.
Outcomes
  • <details>already has a legend so it could be confused with caption.
  • Would address the Blind/Non-Visual Use Case.
    • Because of the "open" attribute it
      • Would address a Sighted Use Case and could aid universal design.
      • Would be easier for authors (especially sighted ones) to comprehend which would lead to improved use.
      • Would be less likely to be inaccurate than data that is invisible to some UAs.
  • Would solve the caption/summary confusion that the was introdued in one of the editor's drafts.
  • Would meet the programmatically-determined standard of WCAG.
  • Is not backwards compatible. Does not work in current AT.
  • Could be capable of handling structured content (block and inline text structure, such as abbreviations, emphasis, headings, etc.)
  • Would address the relevant design principles.

Laws, Policies and Guidelines

References and Blog posts

Tutorials and Documentation

Development Tools @summary implemented in

The summary attribute 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. Some example tools:

Research and User Testing

Raw Data