- From: Ralph Swick <swick@w3.org>
- Date: Tue, 28 Oct 2014 08:12:47 +0000
- To: Edward O'Connor <eoconnor@apple.com>, David Singer <singer@apple.com>
- CC: James Craig <jcraig@apple.com>, public-html-admin@w3.org, public-html-a11y@w3.org, Tim Berners-Lee <timbl@w3.org>
Dear Ted, David,
Thank you for advising us of Apple's concerns regarding the HTML Image
Description ("longdesc") specification. These comments have received
Director's consideration consistent with W3C Process regarding review of
formal objections [1].
All points in Apple's formal objection [2] have been considered on their
technical merits and impact on the Web after thorough examination of
evidence presented. Some issues raised in this formal objection had
previously been raised by you in an objection [3] sent to the HTML
Accessibility Task Force and addressed by the Task Force Co-Facilitators
[4]; other issues have been responded to previously in the extensive
record of discussion on longdesc. After exhaustive analysis we have
found no information that had not previously been addressed.
Nevertheless, given the long history of debate on this topic, the formal
objection has been re-analyzed and responded to here in detail. Findings
and determinations are provided on a section by section basis below,
with a decision provided at the end.
At 08:30 PM 8/20/2014, Edward O'Connor wrote:
> The longdesc attribute is not appropriate for implementation, so we
> object to advancing the HTML5 Image Description Extension document along
> the REC track. This feature is technically deficient in numerous ways.
> We believe that longdesc is flawed:
> * architecturally,
> * historically,
> * functionally,
> * procedurally,
> * and strategically;
> and longdesc has not, does not, cannot, and therefore will not perform,
> but instead harm, its only purported function - providing better
> accessibility.
>
> Fortunately, the Open Web Platform already provides accessible
> mechanisms for describing images which do not suffer from the many
> technical deficiencies of longdesc.
>
> The following sections provide details of these points.
>
> # Longdesc is fundamentally, architecturally flawed
>
> The approach we prefer for accessibility at Apple is to make the primary
> interface accessible, rather than relying on lower-quality fallback
> interfaces. This approach serves users well. It is the foundation for
> successful accessibility not only at Apple but in other companies and
> standards. It is recognized as a best practice by accessibility experts
> both at Apple (consulted while drafting this response), and generally in
> the industry.
>
> Just so, we should be designing features for the Web that are inherently
> accessible. For instance, the <button> element can be naturally exposed
> to users of assistive technology without the author needing to do
> anything special. This is often referred to as "built-in" accessibility.
> Universal access is best achieved when, like <button>, content is
> inherently accessible without additional author effort. The best
> accessible solutions keep the accessible content embedded in the source
> document so things can't get separated.
>
> However, longdesc relegates accessibility to secondary, alternative
> content. This is called "bolt-on" accessibility. When authors update the
> primary content (in this case, replace the image), they often fail to
> make corresponding updates to this secondary content. This bit-rot
> problem is inherent to any bolt-on solution. Longdesc will always be a
> sub-standard approach to accessibility given its bolt-on nature. At
> Apple we take accessibility very seriously, yet we firmly believe that
> longdesc is not the right solution to this problem.
1. Architectural Considerations
* Universal design: The formal objection asserts that
"universal access" (not a broadly-defined term, and here replaced with
the more well-defined term "universal design") is recognized as a best
practice by accessibility experts, and implies that longdesc is not
universal access/design and that it is therefore a lower quality solution.
Since its inception the concept of Universal Design has included
the caveat "to the greatest extent possible" [5], which does not
preclude provision of accessibility through other mechanisms where user
needs cannot otherwise be met effectively.
Similarly, the HTML5 Design Principles expressed a preference
for "universal access" but did not exclude the use of alternative
solutions in cases where not all users could benefit from a given
solution. Specifically it stated:
"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." [6]
* Alleged inferiority: The formal objection asserts that the
longdesc mechanism is secondary, alternative, content, and calls this
"bolt-on" accessibility. However, from the perspectives of Web users
with visual disabilities, and content authors needing to provide
equivalents for complex visual information that is available to sighted
users, rather than being inferior, longdesc provides a reliable
mechanism to make information available where needed. It does so without
requiring users to acquire more advanced assistive technology skills,
and without forcing uninterested users to read it.
* Author effort: The formal objection cites "button" as an
example of how content can be "inherently accessible without any
additional author effort." However, in the given example the "button"
function to be communicated is simple and does not require an equivalent
to the visual information conveyed in a complex image, so it is not a
clear analogy to longdesc.
Additional author effort is typically needed to convey equivalent
visual information of complex images regardless of the mechanism used. A
more appropriate analogy than "button" would be captions for audio
content, which generally require some additional author effort to ensure
accessibility of audio information. Like images, it is not necessarily
the case that audio captions and content are part of the source of the
page in which they are presented to the user. The nature of the Web
includes many instances of linking to relevant resources.
The HTML5 Design principles further noted in the "priority of
constituencies" that user needs should be weighted ahead of other
constituencies, including authors:
"In case of conflict, consider users over authors over
implementors over specifiers over theoretical purity. In other words
costs or difficulties to the user should be given more weight than costs
to authors; which in turn should be given more weight than costs to
implementors; which should be given more weight than costs to authors of
the spec itself, which should be given more weight than those proposing
changes for theoretical reasons alone." [7]
* Keeping content up to date: The formal objection asserts that
authors often fail to make updates to longdesc content. Though longdesc
does not require the description to be contained in an external
resource, with regard to the necessity to keep information outside of a
given web page up to date this issue alone does not intrinsically lead
to inferior web quality. For instance in responsive design, repositories
of images of varying sizes are served according to different parameters
of device displays, and must be kept up to date. Similarly, captions or
transcripts for audio and video are sometimes carried off-page, and as
part of good web content management practices need to be kept up to
date. Captions are also often kept as a separate resource to support
simpler re-use in content management. Where such off-page resources with
variants exist, maintaining a single accessible description of the
resource in the same repository makes the description itself reusable in
multiple references to the same resource.
SUMMARY: The argument that there is a fundamental architectural
flaw in longdesc remains unconvincing. While a Universal Design approach
is favored where possible, this principle has never precluded other
solutions where necessary to more directly address otherwise unmet user
requirements. The Design Principles for HTML5 support the use of more
direct accessibility mechanisms in cases where universal design does not
meet user needs; and also support the prioritization of user
requirements ahead of author effort and architectural considerations.
Even with state of the art technology there is some Web content that
cannot yet be made inherently accessible. Additional author effort for
such content cannot be avoided and longdesc provides a needed direct
approach. The characterisation of longdesc as "bolt-on" is not relevant
since suggested alternatives for providing appropriate equivalents for
complex visual information would similarly require additional author
effort. The need to keep off-page data up-to-date is not unique to
longdesc. Good web content management practices should direct authors to
maintain accuracy of accessibility information, regardless of the
resources in which the contents are stored.
> # The extant longdesc corpus is polluted beyond recovery
>
> Over the 15 years since HTML 4 went to REC with longdesc included, what
> we've seen on the web is that authors by and large do not use longdesc
> and-when they actually try to-they almost always fail to us use it
> correctly.
>
> The result is that longdesc content in the web corpus is so poor that
> assistive technology tools and browsers would actually *reduce* the
> accessibility of pages by exposing longdesc to their users. Less than
> one percent of images on the Web have a longdesc attribute, and of
> those, less than one percent of the longdesc values are useable.
> <http://blog.whatwg.org/the-longdesc-lottery> When HTML ISSUE-30
> (longdesc) <http://www.w3.org/html/wg/tracker/issues/30> was first
> decided in the HTML WG (decision at
>
<http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html>),
> one of the uncontested observations was that "current usage often
> contains bogus values." No evidence has been offered that the situation
> has improved since then, or that the documentation of longdesc in HTML 4
> was so inadequate as to cause this.
>
> In
> <http://lists.w3.org/Archives/Public/public-html-a11y/2014Jul/0047.html>,
> the A11Y TF co-facilitators declared that the task force "is already
> aware that longdesc can be and is often misused on the Web today." They
> then point out that the longdesc spec contains some advice to authors
> which may improve longdesc content written in the future by authors
> aware of the new specification. It's possible that future authors could
> follow such advice (though it seems unlikely, given authors'
> demonstrated inability to follow the HTML 4 spec today), but this fails
> to address the fact that the existing corpus is heavily polluted with
> invalid content. Providing a new specification with new advice can't
> drain the swamp of its existing mud. To think otherwise is a triumph of
> hope over experience.
2. Existing Corpus
The formal objection asserts that the existing body of longdescs is
sufficiently poor that exposing it would reduce the accessibility of
pages by exposing longdesc to their users, based on the following points:
* Prevalence of images with longdescs: The first statistic
offered, that less than one percent of images on the Web have a longdesc
attribute, is not relevant since the great majority of images do not
need and should not have an associated longdesc.
* Prevalence of useable longdescs: The next statistic asserted,
that less than one percent of longdesc values on the Web are useable,
and the accompanying assertion that exposing longdesc values would
therefore reduce accessibility, is not persuasive in the context of the
longdesc requirements for optional consumption, the existence of
informed user choice, and provisions for authoring guidance. Considering
these three in more detail:
** Optional consumption: The assertion that the poor quality
of some existing longdescs is problematic disregards the requirement
that browsers and other user agents allow for optional consumption of
longdesc, which allows users to select whether they want to read a given
longdesc value, and ensures that they are not impeded by non-useful
longdescs.
** Informed user choice: The assertion that the poor quality
of some existing longdescs is problematic also assumes that a user is
not capable of making an informed choice about what they consume. The
majority of non-useful longdescs appear to have been auto-generated by
poorly configured authoring tools and occur in clusters on websites.
Users can choose to view longdescs on trusted sites (such as educational
sites that may have good accessibility practices) or conversely not to
view longdescs on sites that have poorly-made longdescs.
** Authoring guidance: In response to comments during
development, the HTML Accessibility Task Force added implementation
guidance for content authors and conformance checkers [8] which should
improve the quality of new longdescs.
* Possibility of filtering: Many auto-generated longdescs
contain predictable markup that should allow the development of
approaches to flag or filter sites with a concentration of these
specific types of non-useful longdescs.
* Analogies: By analogy, the existence of a substantial volume
of inaccurate auto-generated captions for audio content on the web has
not supported, and should not support, an argument for ceasing to use
well-made captions, since inaccurate captions on some audio do not
degrade the utility of well-made captions for people who are deaf or
hard of hearing. Likewise, the existence of poorly built ramps in the
built environment has not, and should not, lessen the necessity for and
utility of well-made ramps for people with mobility impairments.
Similarly, the existence of areas of poor content on the Web does not
diminish the usefulness of higher quality content elsewhere. Even the
alt attribute was argued against on similar grounds but its usefulness
for accessibility has become accepted -- and the quality has
correspondingly improved.
SUMMARY: The existence of auto-generated misuses and poorly
authored uses of a given feature should not preclude use of that feature
where it will serve a useful purpose in predictable environments, and
where users have a choice about what they consume as in the case of
longdesc. The existence of areas of poor content on the Web does not
diminish the usefulness of higher quality content elsewhere. Statistics
about the limited use of longdesc in the current Web corpus overlook an
important detail: the proportion of images that legitimately require a
longer description is itself very small. Those cases are, however, very
important to the target audience.
> # Existing alternatives
>
> Fortunately, the Open Web Platform already provides several mechanisms
> for providing extended image descriptions today. Here are three examples
> of techniques authors can use.
>
> ## Self-describing images (e.g. SVG)
>
> Images in some formats can contain their own accessible description in
> the image itself. For example, SVG can contain its own description,
> which can be enhanced with WAI-ARIA attributes. There are non-a11y
> benefits to this as well-for instance, self-describing images can be
> saved offline and not lose the association with their descriptions.
> Also, real text context in a vector image lends itself to localization
> much better than any raster format. SVG accessibility is well supported
> today, while it was not a decade ago.
>
> <http://cookiecrook.com/longdesc/svg/>
> <http://www.sitepoint.com/tips-accessible-svg/>
>
> ## <figure> with <details>
>
> If the image cannot carry its own description, by far the best option is
> to simply describe the image in prose adjacent to it. Such a description
> is accessible by anyone. If presenting such a description would
> interfere with the design goals of the author, the image and its
> description may be marked up with <figure> and <details>, as my
> colleague James Craig demonstrates on his website at
> <http://cookiecrook.com/longdesc/details/>. Such markup does not force a
> visual encumbrance; <figure> and <details> may be used in conjunction
> with CSS and WAI-ARIA to make the description available while not
> affecting the visual presentation of the page.
>
> <http://cookiecrook.com/longdesc/details/>
>
> ## <img> with <a>
>
> Alternately, the <img> can be placed inside an <a> element linking to
> the description elsewhere, or an <a> element can be placed next to the
> <img> in the document. Links like these are also accessible by anyone.
>
> <http://cookiecrook.com/longdesc/figure_link/>
>
> ## Other better techniques
>
> This is by no means an exhaustive list of alternative techniques; my
> colleague James Craig has documented several other techniques on his
> website: <http://cookiecrook.com/longdesc/> All of the above techniques
> can be combined with other features of the existing platform, such as
> WAI-ARIA, CSS, and JavaScript, to achieve many design goals and
> interaction patterns. Many of these techniques are already included in
> the HTML specification: see
>
<http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#graphical-representations:-charts,-diagrams,-graphs,-maps,-illustrations>
3. Possible Alternatives:
The formal objection asserts that several existing solutions are
available that meet the requirements specified in longdesc. However,
each alternative mechanism fails to meet one or more of the requirements
specified in longdesc, especially unambiguous discoverability. The
alternatives proposed all share with longdesc the need to create an
alternative representation of the visual content. Additionally, in many
cases the possible alternative solutions introduce more complexity
either by the requirement for the author to create, and the user to
understand, a custom method for discoverability, or by the nature of the
solution (e.g. the iframe-plus-javascript approach), or both. Failures
to meet longdesc requirements are as follows:
* Self-describing images (e.g. SVG): While we expect the tooling
will improve, authoring support for SVG images and particularly for
accessibility of SVG images, is less advanced than for non-vector
images. Accessible SVG requires authors to master several new
techniques, which is more complex than adding an attribute to an image.
Large numbers of images on the Web are not SVG, and while it is possible
to wrap them in SVG to describe them, the adoption of this practice has
been very limited even compared to the use of longdesc. Additionally,
the state of the art for rendering self-describing images does not yet
meet all accessibility needs, one of the reasons that an SVG
Accessibility Task Force is currently under development [9].
* <figure> with <details>: The proposed <details> element did
not achieve consensus for the HTML 5.0 specification. It remains under
consideration as a generic disclosure widget to permit any kind of
information, including information not addressing the needs of a user
who is seeking an equivalent to visual information that a sighted user
would perceive. For instance the <figure> with <details> example on the
cookiecrook website [10] presents the user with 48 types of EXIF data
pertaining to digital photography, none relevant as supplemental
accessibility information. A user needing a visual equivalent cannot
determine in advance whether any particular <details> element contains
useful information, so this mechanism is neither pre-identifiable nor
uniquely discoverable. Operational concerns include that some
implementations render the hide/unhide controls inoperable for some
screen reader users.
*<img> with <a>: Embedding the image in a link to a description
fails to account for the case where an image is used as a link to
something else already, and in all cases fails to provide unambiguous
discoverability for the user. Changing the convention that an image can
be generic link content would impose a significant constraint on
authors, and is unlikely to be successfully implemented across the web.
*Other techniques: Each of the other techniques listed on the
cookiecrook site fail to provide for unambiguous discoverability. The
recently updated iframe-plus-javascript approach imposes an additional
burden on authors beyond the existing work required to do the same using
longdesc.
SUMMARY: The intent of the requirements enumeration in the
specification was that a successful single solution should address all
of the requirements. No alternative solution asserted in the formal
objection currently addresses all of the requirements listed in the
longdesc specification, and several substantially fail to meet the
specified requirements, particularly unambiguous discoverability.
> # Functional flaws: the operation of longdesc
>
> ## User Interface problems of longdesc
>
> The expected UI of longdesc is to load a separate page, which interrupts
> the user's current task and disrupts flow.
>
> It's not clear how longdesc UI could sensibly work in contexts such as
> ebook readers, where both popups and wholesale replacement of the
> current view would not fit standard UI patterns.
>
> ## Network considerations
>
> The performance of longdesc is worse than alternatives, since a page
> load has to be performed to get an external description.
>
> In self-contained contexts like ebooks, longdesc is problematic because
> a book may be read offline. Therefore, encouraging use of a technique
> that may place critical accessibility information on the network is
> actively harmful to accessibility.
4. Operational Considerations
* Workflow considerations: The formal objection asserts that
the expected user interface for longdesc loads a separate page,
interrupts the users' tasks, and disrupts flow. However, there is
deliberately no specified user interface for longdesc and
implementations to date provide diverse user interface options. User
agents implementing longdesc generally do not load a separate page
unless a user elects to consume the information offered in a longdesc.
To assert that this mode of optional consumption interrupts the user's
current task and workflow is analogous to saying that captions interfere
with the workflow of someone who is deaf or hard of hearing -- rather
than that captions provide necessary accessibility information that a
user can elect to view when needed.
* Network performance: The formal objection asserts that
placing critical accessibility information on the network is actively
harmful to accessibility, and that it does not conform to the standard
user interface. In fact the user interface can and frequently does
provide for pre-loading of information directly related to page
contents. To optimize a given UI, a browser vendor could offer the user
a choice to configure their consumption preference to preload longdescs
for a given website. The standard visual user interface is unlikely to
be the primary concern for users with visual disabilities who may be
using substantial magnification, or user style sheets with changes in
color contrast, or an audio or tactile interface.
* Necessary for eBooks: The formal objection suggests that
longdesc is particularly harmful for eBooks, and that the eBook
interface cannot handle popups or replacement of a page with a new tab.
In actuality, the American Publishers' Association has been on record
for three years with a request that longdesc be restored to HTML [11].
Packaging of materials needed for reading a given eBook has already been
addressed in ePub. Popups are a feature of current standard UI patterns.
Wholesale replacement of the page with a new tab is a nearly ubiquitous
feature of UIs developed in the last decade.
SUMMARY: The operational flaws asserted for longdesc in terms of
workflow considerations, network performance, or eBook operation do not
accurately reflect the specification nor current implementations.
Additionally, they presume that developers of browsers and ebook readers
will not choose to optimize the user experience of longdesc. We do not
support this pessimism. However, even if some developers do not
optimize, the result still provides better accessibility for those users
who require it.
> # Procedural flaws: the Use Cases and Requirements
>
> When ISSUE-30 (longdesc) was first decided in the HTML WG (decision at
>
<http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html>),
> the decision stated that ISSUE-30 could be reopened if people provided
> evidence of:
>
> * use cases that specifically require longdesc,
> * evidence that correct usage is growing rapidly and that that growth is
> expected to continue, or
> * [or] widespread interoperable implementation.
>
> The issue was reopened on the basis of use cases which, it's claimed,
> specifically require longdesc. But as this section illustrates, the
> existing web stack already meets the use cases and requirements found in
> the Image Description extension. No identified use case or requirement
> specifically requires the longdesc attribute, or documents a case where
> longdesc is the only or best solution.
5. Procedural Considerations
* Earlier WG decision: The formal objection asserts that the
conditions under which Issue 30 (longdesc) was re-opened in August 2010
[12] are still relevant. However, Plan 2014 [13] when it was accepted by
consensus in the HTML WG, superseded the restrictive terms of the
earlier WG decision. Plan 2014 stated, with regard to longdesc, that the
HTML Accessibility Task Force should have the authority to produce an
extension specification that defines a longdesc attribute. The Task
Force consequently proceeded to do so.
* Original terms: The formal objection cites the earlier terms
from the Working Group's re-open decision even though these have been
superseded. As discussed above, longdesc is the only proposal that
currently meets the documented use cases and requirements. Additionally,
the HTML Accessibility Task Force has documented implementations of
longdesc to address the candidate recommendation exit criteria. The Task
Force considered it unrealistic that the use of longdesc should have
been expected to grow rapidly during a period when a cloud remained
around the question of whether work on longdesc could proceed. Feedback
from developers has indicated interest in using the feature if it is
stabilized, and the requests from e.g. the American Publisher's
Association suggest that growth in correct usage is likely.
SUMMARY: The manner in which the HTML Accessibility Task Force
has continued to develop longdesc is procedurally consistent and
appropriate according to the stipulations of (HTML WG) Plan 2014 which
superseded the terms of the HTML WG Chairs' earlier decision.
> ## Requirements
>
> ### Backwards Compatibility
> > It should be possible to use existing tools and techniques to
> > associate an image with its description.
>
> The Open Web Platform meets this requirement without the addition of
> longdesc. The above techniques all rely on features already present in
> the web stack. That said, even in cases where not all existing browsers
> support a feature, like for example <details>, the features used are
> polyfillable for older browsers, and are designed to degrade gracefully
> in such browsers.
>
> ### Discoverability
> > It must be simple for a user agent to automatically discover a
> > description provided for a given image.
> > A user should be able to determine that there is a description
> > available for a given image.
>
> The Open Web Platform meets these requirements without the addition of
> longdesc. Self-describing images handle this themselves, and for
> out-of-image descriptions, native host language semantics can provide
> the programmatic association that is implied by the words "simple" and
> "automatically" in the text of this requirement. Where the host language
> lacks such semantics, WAI-ARIA attributes can be used to provide the
> association.
>
> ### Inline
> > It must be possible to associate a description in the body of a page
> > with an image in that page.
>
> The Open Web Platform meets this requirement without the addition of
> longdesc, as illustrated with the above techniques.
>
> ### Maintenance
> > It must be simple to maintain a library of images and descriptions for
> > dynamic assembly, or dis-assembly and re-assembly, of content.
>
> The plethora of tools and publishing workflows which people use today to
> assemble web content clearly meet this requirement regardless of the
> technique chosen, including longdesc.
>
> ### No Visual Encumbrance
> > It must be possible to provide a description for an image without
> > forcing the description to be rendered on the page.
>
> The Open Web Platform meets this requirement without the addition of
> longdesc. The above techniques may be used in conjunction with other
> platform features such as CSS and WAI-ARIA to prevent the description
> from appearing by default. Longdesc does not meet this requirement, as
> in the case of offline EPUB with online out-of-flow longdesc content.
> The Platform solutions discussed are a better solution whether in EPUB
> or standard HTML pages.
>
> ### Optional Consumption
> > A user must be able to choose not to read the long description of a
> > given image.
>
> The Open Web Platform meets this requirement without the addition of
> longdesc, as illustrated by all three of the techniques described
> above.
>
> ### Reuse
> > It must be possible to re-use a single description for multiple
> > occurrences of an image.
>
> The Open Web Platform meets this requirement without the addition of
> longdesc. A self-describing image carries its description with it
> into each occurrence. Mulitple <a> elements or aria-describedby
> attributes can be used to re-use a single out-of-image description with
> multiple occurrences of its image.
>
> ### Simple Return
> > A user must be able to return from the description to the image.
>
> The Open Web Platform meets this requirement without the addition of
> longdesc, as illustrated by all three of the techniques described
> above.
>
> Longdesc does not meet this requirement, as in the case of offline EPUB
> with online out-of-flow longdesc content. The Open Web Platform
> solutions discussed are a better solution whether in EPUB or standard
> HTML pages.
>
> ### Structured Markup
> > It must be possible to include rich markup (e.g. HTML5) in the
> > description of the image.
>
> The Open Web Platform meets this requirement without the addition of
> longdesc, as illustrated by all three of the techniques described
> above.
6. Requirements:
* Combined Requirements Consideration: The formal objection
asserts that the Open Web Platform already meets each longdesc
requirement by virtue of one or more alternative solutions meeting the
requirements on a one-by-one basis. Though some of the alternatives do
meet multiple requirements, the relevant question is whether any given
mechanism of the Open Web Platform meets all of requirements of longdesc
collectively [14]. To date, only longdesc does so. Failures of the
alternative solutions suggested by Apple have already been described in
"3. Possible alternatives" above.
* Longdesc Conforms: The formal objection additionally asserts
that longdesc fails to meet its own requirements in the case of
providing a simple return from a long description to an image in an
eBook context. While the specific implementation is a user interface
choice, there are multiple ways this can be met in implementations of
longdesc; for example simply by using the "back" button in the case of
moving to a new page. In the case of opening a tab with a description,
the requirement is met by closing the tab; and similarly in the case of
popups or providing information through the browser UI somewhere other
than replacing the content on the page.
SUMMARY: The longdesc specification addresses the collection of
requirements specified. No other feature, or combination of features, of
the Open Web Platform besides longdesc has been shown to meet the full
collection of requirements.
> ## Use Cases
>
> The existing web stack handles all of the use cases identified in the
> HTML Image Description extension document. Simple illustrative examples
> follow. In all cases, other Open Web Platform features such as WAI-ARIA,
> CSS, and JavaScript may be used to achieve various design goals.
>
> ### Identifying a well-known image
>
> <figure>
> <img src="wctd.jpg" alt="Washington Crossing the Delaware">
> <figcaption>Washington crossing a river, standing heroically in a boat,
> while soldiers do all the paddling</figcaption>
> </figure>
>
> ### Describing a complex chart, diagram, or graphic
>
> The example of a SVG map of Africa including the country borders shows
> fully described graphic content in context. This example includes
> individually accessible UI elements and can be explored by touch using
> VoiceOver on iOS and Macs. See
> <https://www.webkit.org/blog/3302/aria_and_accessibility_inspector/>.
>
> The vector SVG content included as inline HTML, and is made accessible
> using the role attribute. Each country's name can be included as the
> <title> element of a path, or by using ARIA as shown below:
>
> <!-- Each country's vector path equates to touchable, accessible image.
> -->
> <path role="img" aria-label="Algeria" d="M190.6276,112.125 L191.2396,
> ..." />
> <path role="img" aria-label="Angola" d="M372.1636,574.6182 C372.0328,
> ..." />
> <path role="img" aria-label="Benin" d="M272.3596,284.2338 C272.7702,
> ..." />
>
> The <foreignObject> element can be used to embed HTML as appropriate.
>
> ### Teaching accessible development
>
> This use case has no technical requirements that favor one technique
> over another, but naturally all of the above techniques are teachable.
>
> ### A self-describing artistic work
>
> The existing web stack without longdesc provides a rich set of features
> that can be used to create self-describing artistic works.
>
> ### Referring to an existing description
>
> <a href="http://en.wikipedia.org/wiki/Washington_Crossing_the_Delaware"
> id="wctd"><img src="wctd.jpg" alt="Washington Crossing the Delaware"
> aria-describedby="wctd"></a>
>
> ### Linking to a description included within the page
>
> This can be done in HTML today with
>
> <a href="#wctd-desc"><img src="wctd.jpg" alt="Washington Crossing the
> Delaware"></a>
>
> or with HTML and WAI-ARIA like so
>
> <img src="wctd.jpg" alt="Washington Crossing the Delaware"
> aria-describedby="wctd-desc">
>
> <p id=wctd-desc>Washington crossing a river, standing heroically in a
> boat, while soldiers do all the paddling</p>
>
> ### Localizing descriptions
>
> <a href="http://conneg.example.com/Washington_Crossing_the_Delaware"
> id="wctd"><img src="wctd.jpg" alt="Washington Crossing the Delaware"
> aria-describedby="wctd"></a>
>
> As an aside, we don't think content negotiation is a good way to publish
> multilingual content. That said, this example illustrates that the
> existing web stack, without longdesc, addresses this use case at least
> as well as longdesc does.
>
> ### Image search
> ### Describing images
>
> Both of these use cases are addressed by previous examples.
7. Use Cases:
* Existing features: The formal objection asserts that each of
the use cases in the longdesc specification is addressed by an existing
feature of the Open Web Platform. However, each of the proposed
alternative solutions fails to meet one or more requirements for
longdesc as already described above. In particular, they nearly all fail
to meet the requirement for unique discoverability given that they
dual-purpose features intended for other purposes rather than providing
information that is clearly pre-identifiable as an equivalent to visual
information available to sighted users.
* Complex charts, diagrams, and images: In particular, the
formal objection asserts that self-described SVGs can sufficiently
address the use case of complex diagrams, charts, and images. The task
of putting a rich description (i.e. a structured HTML description of a
complex image) in a desc element in SVG, and rendering it in an
accessible user agent, currently involves multiple steps. The use of
longdesc to describe complex images is one of its most significant
use-cases, for instance encompassing complex infographics which can
convey many different types of critical information in educational and
employment settings. However, the lack of tooling and author familiarity
with SVG authoring techniques, as well as the sheer number of images
that would need to be converted to SVG, currently make longdesc a more
realistic solution for many websites.
SUMMARY: None of the alternative solutions proposed in response
to longdesc use-cases meets all of the defined requirements,
particularly the use-case for complex diagrams, charts, and images.
> # Strategic flaws: The opportunity costs of longdesc
>
> There is a tremendous opportunity cost to longdesc as well. Longdesc is
> an attractive nuisance; by making longdesc available to authors, we risk
> them using it instead of directly improving the accessibility of their
> primary content. For instance, take an author tasked with making
> accessible a site with mathematical content represented by bitmapped
> images. A colleague of hers recommends that the author use longdesc.
> Suppose the best case scenario, where the content pointed to by longdesc
> consists of useful, accurate descriptions of the equations on the page.
> By spending her time on creating the content pointed to by longdesc
> instead of replacing the raster images with MathML, the author has
> missed an opportunity to make her mathematical insights reflowable,
> resizable, and available to the widest possible audience.
>
> The authoring opportunity cost is not the only opportunity cost of
> longdesc. Consider that the technology defined at the W3C is used by a
> number of other standards bodies, for instance by the EPUB folks at the
> IDPF. Blessing longdesc in a W3C-branded REC encourages downstream use
> in other standards, which is a strategic blunder. We should instead be
> encouraging such groups to consider the existing alternatives, including
> (to provide a specific example) the use of EPUB's existing footnotes
> feature to provide extended descriptions of raster images in books.
>
> Finally, there is the opportunity cost of working on this old, flawed,
> technique at the W3C, when time spent on better alternatives would be
> time better spent.
8. Opportunity Cost:
* Improving content accessibility: The formal objection asserts
that making the longdesc mechanism available to authors distracts
authors from making their primary content accessible. This assertion
assumes that the accessibility need for providing an equivalent to
visual information for complex images can always be addressed by
dual-purposing some other content or feature. To make complex images
accessible, Web users with visual disabilities need optional access to a
detailed equivalent of the visual information that a sighted user gets.
Sighted users on the other hand generally do not need or want detailed
equivalents of visual information for complex images since it would be
redundant with information that they can get through visual perception.
This is one reason for the longdesc requirement to not force a visual
encumbrance. The availability of the longdesc mechanism, rather than
distracting authors from making their primary content accessible, can
help focus authors' task of doing so. And once they have done so, that
accessibility content can be repurposed through other mechanisms as
those become available, so that their authoring effort is not "lost" to
this particular mechanism.
* Accessibility of MathML. The formal objection asserts that
availability of the longdesc mechanism means that an author of math
content would not take the opportunity to make their content accessible
through MathML. However, the longdesc specification already explicitly
recommends using MathML where viable [15]. Given a few pending issues
with MathML accessibility, in practice the production of an alternative
in addition to MathML for math content remains necessary in some
settings for now.
* Other standards bodies. The formal objection asserts that by
adopting longdesc as a specification, W3C would be leading other
standards organizations including International Digital Publishers'
Forum (IDPF) participants astray. On the contrary, the American
Publishers' Association, which cooperates closely with the IDPF members
on matters relating to accessibility and has carefully studied available
options, has been on record since 2011 requesting that the HTML WG
please restore longdesc to HTML since they have multiple needs for it
across the publishing space. W3C continues to hear from other
organizations involved in publishing and accessibility that they have
specific need for this feature for accessible equivalents of complex images.
* Unsuitability of footnote mechanism: The formal objection
asserts that EPUB's footnotes feature could be used to provide extended
descriptions of raster images in books. This repurposing of footnotes
would run contrary to years of established use of footnotes in
literature, and establish a dual use that could create ambiguity for
authors and users, making it difficult for a user to unambiguously
pre-identify whether a given footnote were a routine footnote or
contained a detailed visual equivalent of a complex image. Using the
routine footnote mechanism for longdesc content would also force a
visual encumbrance on sighted users of the content in question, counter
to the requirements for longdesc.
* Time spent working on longdesc: The formal objection asserts
that time spent working on longdesc could have been spent working on
better alternatives. Possible alternatives proposed by the Objector
failed to gather any consensus nor did a more comparably effective
solution emerge during this time. Most platforms now have longdesc
support as shown in the implementation report for exiting Candidate
Recommendation [16]. Reported implementation efforts have ranged from a
few hours for a black box implementation done without prior involvement
in, nor detailed knowledge of the specification, to a few days.
SUMMARY: The assertions in the formal objection of an
opportunity cost from making longdesc available are not persuasive. In
some circumstances authors need to provide detailed equivalents of
complex images regardless of the mechanism. Dual-purposing other
information associated with complex images does not necessarily provide
adequate accessibility. The longdesc specification directly advises
authors to use MathML in situations where it is viable. The digital
publishing community has actively requested longdesc and laid out
specific use cases. The suggested alternative solution, of creating dual
use footnotes in ePub as an alternative to longdesc in ePub, fails
longdesc requirements on several grounds including unambiguous
discoverability and not forcing a visual encumbrance.
> # Actions which whould partially or fully address our concerns
>
> The Process document states that Formal Objections should propose
> changes that would remove the Formal Objection. In this section we
> outline possible steps that would partially or fully address the
> concerns that have contributed to our decision to file a Formal
> Objection.
>
> ## Change the abstract of the document to
> reflect the historic nature of the attribute
>
> We suggest changing the first sentence of the abstract from
>
> "This specification defines a longdesc attribute (based on the longdesc
> attribute of HTML 4) to link descriptions to images in HTML5 content.
>
> to
>
> "This specification defines how the historic longdesc attribute,
> originally defined in HTML 4, may be used to to link descriptions to
> images in HTML5 content. However, it is rarely, if ever, best practice
> to use the longdesc attribute to describe images.
>
> (We don't think an abstract is the place to describe the alternatives.)
>
> ## Make the focus of the document clear from the title
>
> Since the document only discusses longdesc, not all image descriptions
> or even all image description extensions, change the title from
>
> "HTML5 Image Description Extension (longdesc)
>
> to
>
> "The 'longdesc' Image Description attribute in HTML5 content"
>
> ## Take it off the Recommendation track
>
> Since this technique is not, in fact, recommended we suggest it be taken
> off the Recommendation track and published as a Note.
>
> This outcome is preferred to the one below, from our perspective.
>
> ## Remain on the Recommendation track with an author-level SHOULD NOT
>
> Despite longdesc's fundamental unsuitability as part of the platform,
> there is a small amount of content that makes correct use of it, and
> there may be specific, non-Web contexts (such as carefully curated
> intranets or the like) in which longdesc is used.
>
> If the document does remain on the Recommendation track, the
> recommendation should be clear: use better, more structured,
> alternatives that do not suffer from the problems we outline above. The
> document should state clearly:
>
> "In the vast majority, if not all cases, there are alternatives to
> this attribute that provide better accessibility and better overall
> behavior. The longdesc attribute SHOULD NOT be used; it is documented
> here for historical compatibility, not as a recommendation for new
> adoption."
9. Requested Changes:
Several changes were requested in the formal objection:
* Revise the abstract by labeling longdesc as an "historic"
attribute.
Revising the abstract to advise people that they should not use the
specification would discourage developers from using an unambiguously
pre-identifiable means of providing detailed accessibility information
for complex graphics.
* Remove the longdesc specification from Recommendation track.
Removing the specification from the Recommendation track would mean that
an unambiguously pre-identifiable specified means of providing detailed
accessibility information for complex graphics would not be available
within the Open Web Platform.
* Rename the specification.
The proposed name change would result in a longer and more unwieldy name
without contributing to a clearer designation of the spec.
* Remain on the Recommendation track with an author-level SHOULD
NOT.
Inserting an author-level SHOULD NOT would discourage developers from
using an unambiguously pre-identifiable means of providing detailed
accessibility information for complex graphics.
* SUMMARY: The requested changes would substantially alter the
longdesc specification such that it would no longer fulfill the user
requirements for which it has been developed.
> # Conclusion
>
> The many technical shortcomings of longdesc, both those inherent to its
> design and those that have been demonstrated in practice since it was
> first proposed, have been repeatedly brought to the attention of this
> Working Group over many years. Given these shortcomings, and the
> widespread support in web content engines for better alternatives, we do
> authors a disservice by encouraging them to rely on longdesc to make
> their images accessible.
>
> We've been debating longdesc for years. I've heard from a few people
> that they just don't have the time or energy to argue about this
> anymore, and I fear that there are many others like them. We're facing
> the real risk of consensus by exhaustion. I believe that there is no
> consensus within the community of browser engine implementors in support
> of longdesc. If the longdesc document continues to proceed along the REC
> track, I believe the credibility of this WG and the W3C will be
> materially harmed.
>
> Given all these problems, why then does longdesc continue to have
> support? Others have speculated about our motives in opposing its
> further development and promotion, but we don't think a discussion of
> assumed or imputed motives is helpful, nor is it in place in a formal
> objection; we are passionate about providing quality accessibility, and
> continuing to promote longdesc actively harms that goal. Many people
> feel that there are some entrenched positions involved, and indeed, to
> avoid being in one ourselves we stepped back from this specification
> development for a while to see if the problems we and others had
> previously identified could and would be addressed, whereupon we would
> have changed our mind. Unfortunately, we don't believe the problems have
> been addressed.
>
> We would therefore like the decision to be made not on the basis of
> motives, nor the backgrounds of participants, nor the origins of the
> proposals, but on technical merits that will give the best platform for
> online accessibility. Longdesc does not and will not do that.
>
> Ted, with colleagues
10. [Objector's] Conclusion
Addressing only those points mentioned in the Objector's conclusion and
not already addressed in preceding sections of this formal objection:
* Repeated debate: The formal objection states that the asserted
flaws have been brought to the working group repeatedly. While true, the
assertions have also been repeatedly addressed during this time.
* Browser support: The formal objection asserts that there is no
consensus within the community of browser engine implementors in support
of longdesc. On the contrary, implementation support of longdesc has
increased in major browser platforms as evidenced in the candidate
recommendation exit report [16].
* No credibility risk: The formal objection asserts that there
would be a credibility risk to the working group and to W3C for allowing
this specification to proceed. However, the assessment here does not
support a conclusion that there are adequate alternative solutions that
meet the combination of requirements described in longdesc, nor does it
support a finding of harm to accessibility from longdesc, but it does
find a user need. We therefore find no basis for the asserted
credibility risk.
11. DECISION:
On the basis of careful consideration of all points raised, the
Director does not find sufficient basis to uphold this formal objection
and it is hereby overruled.
The Joint HTML Accessibility Task Force, and the two Working Groups
under which the Task Force operates, may therefore continue to progress
this specification per W3C Process.
We encourage all parties to apply their creative energies and
design capabilities constructively towards improved solutions for
accessible image descriptions in the future.
Best regards,
Tim Berners-Lee, Director
Ralph Swick
Judy Brewer, Web Accessibility Domain Lead
Philippe Le Hégaret, Interaction Domain Lead
References:
1. http://www.w3.org/2014/Process-20140801/#WGArchiveMinorityViews
2. http://lists.w3.org/Archives/Public/public-html-admin/2014Aug/0028.html
3. http://lists.w3.org/Archives/Public/public-html-a11y/2014Jun/0115.html
4. http://lists.w3.org/Archives/Public/public-html-a11y/2014Jul/0047.html
5. http://www.ncsu.edu/ncsu/design/cud/about_ud/about_ud.htm
6. www.w3.org/TR/html-design-principles/#accessibility
7. http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
8. http://www.w3.org/TR/html-longdesc/#authors-and-conformance-checkers
9. http://www.w3.org/WAI/PF/svg-a11y-tf/work-statement
10. http://cookiecrook.com/longdesc/details/
11. https://www.w3.org/Bugs/Public/show_bug.cgi?id=13461
12.
http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html
13. http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#ISSUE-030
14. http://www.w3.org/TR/html-longdesc/#requirements
15. http://www.w3.org/TR/html-longdesc/#authors
16. http://w3c.github.io/test-results/html-longdesc/cr-report.html
Received on Tuesday, 28 October 2014 17:01:48 UTC