Disposition of comments for the Accessibility Guidelines Working Group

Submitter's Name: Susan Verhoef
Submitter's Email: susan.verhoef@co.travis.tx.us

Technique ID: UNKNOWN
Short Name: providing descriptive link text in spacer gif alt tag
Technique Category: HTML and XHTML Techniques
Success Criterion Reference: UNKNOWN

Applicability:
Use with link text which is not sufficiently descriptive

UA Issues:
This technique will ALWAYS work

Description:
The object of this technique is to provide meaningful text when the text itself is not meaningful. There are times when a client insists upon a "click here" link, or a "more..." link. We use this technique to allow screenreaders to provide meaningful text to users.

Example 1 Head: Using image alt text with links
Example 1 Description:
<a href="..."><img border=0 src="spacer.gif" alt="Passport Application Information " />More...</a>

Screenreaders can ignore the title attribute. Different browsers deal with the css attributes "visibility" and "display" differently. This technique ensures that no matter what changes and modifications happen with css and html our links will always provide meaningful text.

This technique will NEVER FAIL.



Related Techniques:
G53

Test Procedure:
add the single pixel gif at the beginning of the link text.

We actually have a server-side vbscript function included in our script file to cut down on the drudgery.

<%
dim altText
Function writealttext(altText)
response.write("<img src='/common/images/spacer.gif' border=0 alt='" & altText & "' />")
End Function
%>

Now you simply write on the page:
<a href="..."><%writealttext("Passport Application Information ")%>More...</a>

Expected Result:
The screen reader will read the text.

Test File 1:
http://www.traviscountytx.gov/commissioners_court/agendas/2012/06/ssi/120612.asp

Test File 1 Pass/Fail: pass

Additional Notes:
I work for the government and we cannot override the dictates of elected officials. Some let us adapt their copy for the web, but many do not. Much as I like plain language and lean text, I do not have the power to impose these standards on my clients, so the meaningful text maybe nowhere near the link text.

This technique is impervious to ill-conceived stylesheet edits or deprecated css/html methods.

No guidelines reference was submitted!
No example 2 header was submitted!
No example 2 description was submitted!
No resource 1 title submitted!
No resource 1 URI submitted!
No resource 2 title submitted!
No resource 2 URI submitted!
No test file 2 was submitted!
No test file 2 pass/fail was submitted!


------------------------------------------------

<technique id="UNKNOWN">
<short-name>providing descriptive link text in spacer gif alt tag</short-name>
<applies-to>
<guideline idref="" />
<success-criterion idref="UNKNOWN" />
</applies-to>

<applicability>
Use with link text which is not sufficiently descriptive
</applicability>
<ua_issues>
This technique will ALWAYS work
</ua_issues>
<description>
The object of this technique is to provide meaningful text when the text itself is not meaningful. There are times when a client insists upon a &quot;click here&quot; link, or a &quot;more...&quot; link. We use this technique to allow screenreaders to provide meaningful text to users.
</description>

<examples>
<ex_head_1>
Using image alt text with links
</ex_head_1>
<ex_desc_1>
<a href=&quot;...&quot;><img border=0 src=&quot;spacer.gif&quot; alt=&quot;Passport Application Information &quot; />More...</a>

Screenreaders can ignore the title attribute. Different browsers deal with the css attributes &quot;visibility&quot; and &quot;display&quot; differently. This technique ensures that no matter what changes and modifications happen with css and html our links will always provide meaningful text.

This technique will NEVER FAIL.


</ex_desc_1>
<ex_head_2>

</ex_head_2>
<ex_desc_2>

</ex_desc_2>
</examples>

<resources>
<resources_title1>

</resources_title1>
<resource_uri1>

</resource_uri1>
<resources_title2>

</resources_title2>
<resource_uri2>

</resource_uri2>
</resources>

<related_techniques>
<related_technique>
G53
</related_technique>
</related_techniques>

<tests>
<procedure>
add the single pixel gif at the beginning of the link text.

We actually have a server-side vbscript function included in our script file to cut down on the drudgery.

<%
dim altText
Function writealttext(altText)
response.write(&quot;<img src=&#039;/common/images/spacer.gif&#039; border=0 alt=&#039;&quot; &amp; altText &amp; &quot;&#039; />&quot;)
End Function
%>

Now you simply write on the page:
<a href=&quot;...&quot;><%writealttext(&quot;Passport Application Information &quot;)%>More...</a>
</procedure>
<expected_result>
The screen reader will read the text.
</expected_result>
<test_file_1>
http://www.traviscountytx.gov/commissioners_court/agendas/2012/06/ssi/120612.asp
</test_file_1>
<pass_fail_1>
pass
</pass_fail_1>
<test_file_2>

</test_file_2>
<pass_fail_2>

</pass_fail_2>
</tests>

</technique>

Additional Notes:

I work for the government and we cannot override the dictates of elected officials. Some let us adapt their copy for the web, but many do not. Much as I like plain language and lean text, I do not have the power to impose these standards on my clients, so the meaningful text maybe nowhere near the link text.

This technique is impervious to ill-conceived stylesheet edits or deprecated css/html methods.

an example is http://www.ottawapolice.ca
there is a search form in the top left. The input tag is inside a div. The input gets focus... and when someone hits the enter key from there the containing div fires the go button and does the search. It technically fails because it is an onkeypress on a non focusable element... but it didn't seem to fail ... it accepted tab focus, showed up as a form, and responded to a keypress
<div id="ctl00_Header1_Panel1" onkeypress="javascript:return WebForm_FireDefaultButton(event, 'ctl00_Header1_ib_go')">
<input name="ctl00$Header1$queryText" type="text" value="search" id="ctl00_Header1_queryText" class="sf_searchText" onFocus="clearSearchBox(this)" />
<input type="image" name="ctl00$Header1$ib_go" id="ctl00_Header1_ib_go" title="Go button for Search field" Text="Search" alt="Search" class="sf_searchSubmit" src="/App_Images/navigation/primary/go_en.png" style="border-width:0px;" />

</div>

Proposed Change:
Recommend, amend the language of example number 4.

In the body of the technique insert a line that says.
"If there is a focusable element inside a div that has an onkeypress, such as an input, which is recognized by Assistive technology, then it would NOT be a failure because the containing DIV will respond to the focusable, recognized element.

Add the following example or something like it to SCR35:

<div id="ctl00_Header1_Panel1" onkeypress="javascript:return WebForm_FireDefaultButton(event, 'ctl00_Header1_ib_go')">
<input name="ctl00$Header1$queryText" type="text" value="search" id="ctl00_Header1_queryText" class="sf_searchText" onFocus="clearSearchBox(this)" />
<input type="image" name="ctl00$Header1$ib_go" id="ctl00_Header1_ib_go" title="Go button for Search field" Text="Search" alt="Search" class="sf_searchSubmit" src="/App_Images/navigation/primary/go_en.png" style="border-width:0px;" />
</div>

Refer to examples 1 and 2 (G73:
http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/G73), especially the
sentences:
"The image links to the bottom of the page where there is a section titled
"Description of charts on this page". The link points to this specific
description: "Sales for October show Mary leading with 400 units. Mike
follows closely with 389. Chris rounds out our top 3 with sales of 350.
[end of description]," in example 1,
and,
"The image links to another page titled "Description of charts in October
Sales Report". The description link points to this specific description:
"Sales for October show Mary leading with 400 units. Mike follows closely
with 389. Chris rounds out our top 3 with sales of 350. End of description.
<link> Back to Sales Chart </link> ]," in example 2.
In both the examples, note the fact that an image links to the bottom of
the page where there is a section titled 'XYZ.' This is understood but the
following sentence that states the link points to a specific description is
not clear enough. What does a 'section' mean in the sentence? What and
where is the 'specific description'? Which link points to what in the page
is unclear after reading the two sentences together.
Furthermore, note the loner bracket ] at the end of the second example.

Submitter's Name: Andrew Buckeridge
Submitter's Email: andrewb@bgc.com.au

Technique ID: UNKNOWN
Short Name: Including and playing dialogue only subtitles encoded in the closed caption stream of video
Technique Category: General Techniques
Success Criterion Reference: UNKNOWN

Applicability:
Signing is used in small communities and is not understood by others.
Like other natural languages completely different forms emerge. For
example some deaf people in Australia understand Auslan, but do not
understand US (ASL) or UK (BSL) signing. They all understand written
English as used in subtitles. Signing is only used for face to face
communication within those small communities. If an Auslan
&lt;http://www.auslan.org.au/&gt; speaker goes to the US or UK then they
are in the same position as an English only speaker in East Germany.
They have to write down notes too.

UA Issues:
Signing is an issue for User not their Agent.

Many broken video players do not play closed captions which is a
User Agent issue.

Description:
Subtitles for with dialogue alone should be sufficient.
We don&#039;t need &quot;Loud bang&quot; when is obvious that some one has been
startled. It is such overload that makes subtitles hard to follow.
The option of selecting dialogue only subtitles should be a requirement.
This can be including in the existing video closed caption stream.

Related Techniques:
G54

Test Procedure:
Turn your speakers off or like many people your computer
already does not have speakers or the OS boots up with sound off
(-inf dB rather than 0 dB) so the speakers won&#039;t work anyway.
(There is no sound in GNU/Linux by default. Blinkies hate this.)

Expected Result:
Does the video make sense without audio? Yes=PASS
No
Did you have to make the speakers work and then did it make sense? Yes=FAIL
No
NORMAL

Test File 1:
Grab any video and try and get subtitles to display.

Test File 1 Pass/Fail: fail

Test File 2:
Yet to find one, but some make some sense even when dialog is not known.

Test File 2 Pass/Fail: pass


No guidelines reference was submitted!
No example 1 header was submitted!
No example 1 description was submitted!
No example 2 header was submitted!
No example 2 description was submitted!
No resource 1 title submitted!
No resource 1 URI submitted!
No resource 2 title submitted!
No resource 2 URI submitted!
No additional notes were submitted!


------------------------------------------------

<technique id="UNKNOWN">
<short-name>Including and playing dialogue only subtitles encoded in the closed caption stream of video</short-name>
<applies-to>
<guideline idref="" />
<success-criterion idref="UNKNOWN" />
</applies-to>

<applicability>
Signing is used in small communities and is not understood by others.
Like other natural languages completely different forms emerge. For
example some deaf people in Australia understand Auslan, but do not
understand US (ASL) or UK (BSL) signing. They all understand written
English as used in subtitles. Signing is only used for face to face
communication within those small communities. If an Auslan
<http://www.auslan.org.au/> speaker goes to the US or UK then they
are in the same position as an English only speaker in East Germany.
They have to write down notes too.
</applicability>
<ua_issues>
Signing is an issue for User not their Agent.

Many broken video players do not play closed captions which is a
User Agent issue.
</ua_issues>
<description>
Subtitles for with dialogue alone should be sufficient.
We don&#039;t need &quot;Loud bang&quot; when is obvious that some one has been
startled. It is such overload that makes subtitles hard to follow.
The option of selecting dialogue only subtitles should be a requirement.
This can be including in the existing video closed caption stream.
</description>

<examples>
<ex_head_1>

</ex_head_1>
<ex_desc_1>

</ex_desc_1>
<ex_head_2>

</ex_head_2>
<ex_desc_2>

</ex_desc_2>
</examples>

<resources>
<resources_title1>

</resources_title1>
<resource_uri1>

</resource_uri1>
<resources_title2>

</resources_title2>
<resource_uri2>

</resource_uri2>
</resources>

<related_techniques>
<related_technique>
G54
</related_technique>
</related_techniques>

<tests>
<procedure>
Turn your speakers off or like many people your computer
already does not have speakers or the OS boots up with sound off
(-inf dB rather than 0 dB) so the speakers won&#039;t work anyway.
(There is no sound in GNU/Linux by default. Blinkies hate this.)
</procedure>
<expected_result>
Does the video make sense without audio? Yes=PASS
No
Did you have to make the speakers work and then did it make sense? Yes=FAIL
No
NORMAL
</expected_result>
<test_file_1>
Grab any video and try and get subtitles to display.
</test_file_1>
<pass_fail_1>
fail
</pass_fail_1>
<test_file_2>
Yet to find one, but some make some sense even when dialog is not known.
</test_file_2>
<pass_fail_2>
pass
</pass_fail_2>
</tests>

</technique>

Additional Notes:

Name: David MacDonald
Email: david100@sympatico.ca
Affiliation: WCAG TEAM
Document: TD
Item Number: H28
Part of Item: Examples
Comment Type: general comment
Summary of Issue: Should we remove ACRONYM examples and discussion
Comment (Including rationale for any proposed change):
Wondering if we should be preparing for HTML 5 by changing the ACRONYM examples, it is valid in earlier versions of HTML5 but I think it is confusing to leave it in, given that our techniques are usually reserved for things we think are good to do, with the goal of increasing clarity, rather than confusion

Proposed Change:
Change examples 3 and 4 to use ABBR instead of ACRONYM, and remove references to acronym.

This is some comments regarding the following: LC-2790 for Web Content
Accessibility Guidelines Working Group - found at
https://www.w3.org/2006/02/lc-comments-tracker/35422/WD-WCAG20-TECHS-2013071
1/2790?cid=2790

It is unclear on how to respond to responses, and trust that this method
will be deemed appropriate.

***************

The response to Laura's comment is pasted below, and I wish to comment on
that response. My comments are provided in-line, and prefaced with my
initials:

<-start->
Thank you for your comment. A common @longdesc implementation pattern is to
write the longdesc within a URI that has to be activated by the user
(usually on a separate page).

JF: I note that this is in fact a design feature - the ability for the end
user to consume or not consume the extended description.


It takes the general form:

<img src="richimage.png" alt="Some terse overview of the image"
longdesc="somepage/longer_desc.html">

however, as you point out in your example:

<img
longdesc="#desc"
alt="Line graph of the number of subscribers"
src="http://www.company/images/graph.png">
<div id="desc">
<!-- Full Description of Graph -->
<div>

is valid.

However, this in page method is very similar to use of aria-describedby...

JF: *EXCEPT* for the very real difference that, unlike all current
implementations of aria-describedby, @longdesc provides the ability for the
end user to consume or not consume. I believe that it is CRITICAL that
authors understand this important distinction - whether or not the longer
text is inline or on a separate page.


...and is really at the discretion of the author as to what they choose to
use.

JF: Which is why making the distinction clear and obvious is important.
Given the years of work and effort to retain @longdesc in HTML5 (including
the WAI sponsored HTML5 Image Description Extension specification -
http://www.w3.org/TR/html-longdesc/) I would hope that any Techniques
recommendation(s) would also be 'neutral' in laying out that author
discretion.


A possible change to the technique could be:

"This is unlike longdesc, which typically required the author to create a
separate file to describe a picture, even though it does have the capacity
to point to an in page description. It is preferable to have the descriptive
text in prose so that it is readily available to all users."

JF: Proposed editorial change:
"This is unlike longdesc, <del>which typically required the author to</del>
<ins>which traditionally saw the author</ins> create a separate file to
describe a picture, even though it does have the capacity to point to an in
page description. <ins>While</ins> it is preferable to have the descriptive
text in prose so that it is readily available to all users, <ins>when this
is not possible due to design restrictions, longdesc will meet the success
criteria</ins>."

Let us know if this is agreeable. Regarding this issue:

> Additionally, with aria-describedby the description is forced upon
> screen reader users whether they want it or not.
How the @longdesc content or indeed the aria-describedby info is presented
to the user, is largely a user agent issue.

JF: While this is indeed true, we have I believe a duty to be factual and
accurate as well.

Currently all user-agent combinations that support aria-describedby do so as
part of the page flow, without the ability for the end (screen reader) user
to choose to consume or not consume. While it is true that the screen reader
user can *stop* their reader at any time, and skip past blocks of content,
the ability to proactively choose to hear the longer description, versus
having to stop and skip past that description, provides a better user
experience. I believe this fact is also important, and should be clearly
articulated.

As well, currently aria-describedby, and in fact any aria attribute, is only
being communicated to Assistive Technologies (via the AAPIs), which means
that the programmatic association of the extended text is only apparent to
users of AT. Conversely, while still having weak-ish native support from the
browsers today, @longdesc content can be found and acted upon by any user
who is using a browser or browser+extension that allows for @longdesc
discovery and activation - for example Firefox's current contextual menu
discovery/activation method - without the need for Assistive Technology.

When we present multiple possible techniques for the authors discretionary
choice, it is important that all aspects of their choices are made clear.
[/JF]


Most @longdesc implementations may not be as 'controllable' or 'on-demand'
as the comment suggests - as longdesc implementations and user experience
has largely been poor.

JF: Source? @longdesc implementations for the primary audience (non-sighted
screen reader users) has been quite good for users of JAWS for many years
now, and recent changes to both the NVDA screen reader and Firefox, as well
as nightly builds emerging from Chrome (+ Chromevox) suggest that
implementations and user experiences are actively improving. All of this has
been previously researched and documented by members of the HTML5 a11yTF,
and can be found at:
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementatio
n

The finalization of the HTML5 Image Description Extension specification will
also likely drive better implementation and experience as browsers and other
user-agent tools seek to be HTML5 conformant.


Regarding the suggested change, to remove the text:

"This is unlike longdesc which typically required the author to create
a separate file to describe a picture when it was preferred to have
the descriptive text in prose as well so that it was readily available
to all users.

JF: I have already suggested some minor editorial changes here


Yet, like longdesc, descriptive text is treated
separately from the short name you would typically provide using the
title or alt attributes in HTML.

JF: this sentence, on the surface, implies that the user-experience is also
the same, which clearly it is not today. It is not exactly true that it is
"treated separately", as in practice today, while it is indeed a separate
aria-node of content, like the @alt attribute (and unlike the @longdesc
attribute) all ATs currently announce the value of aria-describedby without
user activation - in fact many tools will concatenate both the alt text and
the describedby text into a single "string", read aloud by the screen
reader. I propose the following alternative edit:

"Similar to longdesc, descriptive content referenced by aria-describedby is
treated separately in the DOM as a discrete node of content, similar to the
short name you would typically provide using the title or alt attributes in
HTML. Unlike longdesc however, most Assistive Technologies today treat
aria-describedby content the same way that they treat @alt content: it is
read aloud by the screen reader without user activation." [/JF]


This is the preferred vehicle for
providing long descriptions for elements in your document because the
alternative is available to all, including sighted people who do not
have assistive technology."

JF: Hmmm... why is it "preferred"? Earlier you note that
longdesc="#samepage" was almost identical to aria-describedby ("However,
this in page method is very similar to use of aria-describedby"), so either
choice would be, on the surface, a wash.

Add in the fact that aria attributes are only being programmatically
associated and conveyed to the accessibility APIS today, whilst @longdesc
content is programmatically associated at the DOM and can be acted upon in
browsers without the intervention of Assistive Technology, and I would argue
that using the longdesc="#samepage" pattern is actually superior. For this
reason I have some *serious* reservations about that line. I propose the
following edit:

"Whether an author chooses to use @longdesc or @aria-describedby to
programmatically associate a complex image to its long description, the
preferred solution is one that provides that longer text description in the
same document, because the alternative is then available to all, including
sighted people who do not have assistive technology."



For ease of reading, I will recap my proposed edits here:

"This is unlike longdesc, which traditionally saw the author create a
separate file to describe a picture, even though it does have the capacity
to point to an in page description. While it is preferable to have the
descriptive text in prose so that it is readily available to all users, when
this is not possible due to design restrictions, longdesc will meet the
success criteria.

Similar to longdesc, descriptive content referenced by aria-describedby is
treated separately in the DOM as a discrete node of content, similar to the
short name you would typically provide using the title or alt attributes in
HTML. Unlike longdesc however, most Assistive Technologies today treat
aria-describedby content the same way that they treat @alt content: it is
read aloud by the screen reader without user activation.

Whether an author chooses to use @longdesc or @aria-describedby to
programmatically associate a complex image to its long description, the
preferred solution is one that provides the longer text description in the
same document, because the alternative is then available to all, including
sighted people who do not have assistive technology."


I look forward to your thoughts.

JF
---------------
John Foliot
Web Accessibility Specialist
W3C Invited Expert | Co-Facilitator, W3C HTML5 Accessibility Task Force
(Media)
Co-Founder, Open Web Camp

Thank you very much for agreeing to provide on-page longdesc syntax in order to help people understand how it works and what limitations exist. I agree with the direction you are taking but suggest helping authors to overcome any limitations by incorporating a end-point solution into H45's verbiage and example as well as pointing out the advantages of using a separate resource by changing:


H45: http://www.w3.org/TR/WCAG-TECHS/H45.html

Authors can provide a description for an image by including text in a separate resource or within the text of the page containing the image.
<ins>An advantage of using a separate resource for the description is that it is easily reusable for multiple instances of the same image, it does not add on-page visual clutter to the original document, and the description's end-point is self evident.</ins> An advantage of providing the description within the same page as the image is that all users can access the description. A limitation of <del>this</del><ins>the on-page</del> method, as well as in providing multiple descriptions on a single separate page, is that current implementations supporting longdesc <del>read all text on the page that follows the start of the long description</del><ins>do not identify the long description's end-point</ins>. <del>As a result, an end user may hear the long description and all content on the page following it, without knowing where the long description is intended to end unless authors provide text to help users identify the end-point of the description.</del><ins>Authors can solve this by providing a well-formed description, which identifies the where the description ends.</ins>

[On-page Example]
(suggested change is in addition of H3 and P inside the div#desc)

<img longdesc="thispage.html#desc"
alt="Line graph of the number of subscribers"
src="http://www.company/images/graph.png">
<div id="desc">
<h3>Long Description: Line graph of the number of subscribers</h3>
<!-- Full Description of Graph -->
<p>Long description ends.</p>
<div>


Laura also suggests various resources for inclusion, below:

Related Resources:

Description Available in a Separate Document Provides Efficiency http://www.d.umn.edu/~lcarlson/research/constriants/separate-doc.html

Forced Visual Encumbrance Adds Visual Clutter http://www.d.umn.edu/~lcarlson/research/constriants/visual-encumbrance.html

In addition WCAG WG may want to consider demonstrating to authors how to provide an actual long description by replacing the comment: <!-- Full Description of Graph --> with markup.

For example:
http://www.d.umn.edu/itss/training/online/moodle_downloads/accessibility_104/examples/pages/graph2.html#desc

More longdesc Examples:

http://www.d.umn.edu/itss/training/online/moodle_downloads/accessibility_104/examples/long.html

http://www.d.umn.edu/itss/training/online/moodle_downloads/accessibility_104/104ex1_fixed.html#browsers_stats

http://www.d.umn.edu/itss/training/online/moodle_downloads/accessibility_104/104ex1_fixed.html#painting

1. Title of the document

Using aria-describedby to provide descriptions of objects

2. Location within the document

Text that states:

"A feature of WAI-ARIA is the ability to associate descriptive text
with a section, drawing, form element, picture, and so on using the
aria-describedby property. This is unlike longdesc, which typically
required the author to create a separate file to describe a picture
when it was preferred to have the descriptive text in prose as well so
that it was readily available to all users. Yet, like longdesc,
descriptive text is treated separately from the short name you would
typically provide using the title or alt attributes in HTML. This is
the preferred vehicle for providing long descriptions for elements in
your document because the alternative is available to all, including
sighted people who do not have assistive technology."
http://www.w3.org/WAI/GL/wiki/Using_aria-describedby_to_provide_descriptions_of_objects
(16 July 2013 version)

3. Concern

This information is incorrect.

Longdesc does not require the author to create a separate file to
describe an image as explained in:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2013Jul/0012.html

Additionally, with aria-describedby the description is forced upon
screen reader users whether they want it or not. They cannot interact
with it at will. Aria-describedby is read aloud without any user
intervention, forcing the screen reader user to listen to it each and
every time they encounter the image. The user is not able to control
how they interact with the long description. None of this is a problem
with longdesc as it supplies long descriptions on-demand and not by
force. This choice is a critical user-requirement.

Forcing users to listen to long descriptions is an extremely negative
and harmful user-experience as John Foliot has explained,
“The ability to (mentally and literally) pause, step outside of the
page flow to get a description of a complex image (because you cannot
see it) and then return to the content flow AT EXACTLY THE SAME PLACE
YOU LEFT OFF is a design feature, not a flaw. The key point about
@longdesc (for screen readers) is that they are given a *choice* as to
whether or not they want to hear what some might consider extraneous
data or not - it is the difference between glancing at a sophisticated
pie chart (for example) versus studying it. You, as a sighted user,
have that choice (to glance or study), yet insisting that the full-on
textual description be inserted into the content flow because the user
is blind is tantamount to me holding your head in a fixed position and
insisting that you explain aloud to me that pie chart before I allow
you to continue reading the rest of the page.
@longdesc is about user-choice!”
http://lists.w3.org/Archives/Public/public-html/2011Mar/0736.html

The designed behavior of Screen Reading technology that supports
aria-describedby is to automatically 'read aloud' the text string
referenced by the attribute, whether or not the end-user actually
wants this information. It will introduce a "force-fed" longer
description on the Screen Reader user whether they want it or not.
This is, understandably, an extremely disruptive user-experience and
one we should be avoiding at all cost.

Aria-describedby is not a preferred method.

4. Suggested change

Remove:

"This is unlike longdesc which typically required the author to create
a separate file to describe a picture when it was preferred to have
the descriptive text in prose as well so that it was readily available
to all users. Yet, like longdesc, descriptive text is treated
separately from the short name you would typically provide using the
title or alt attributes in HTML. This is the preferred vehicle for
providing long descriptions for elements in your document because the
alternative is available to all, including sighted people who do not
have assistive technology."

Add something such as:

Screen Reading technology that supports aria-describedby is
automatically 'read aloud' forcing users to listen to descriptions
each time a user encounters an object.

5. Additional rationale for the comment

The Techniques for WCAG 2.0 document should treat ARIA and longdesc
equitably and not be biased against the new longdesc spec.
https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html

Please correct this situation.

Example 2 on H33 shows the title attribute as the sole means of indicating link opens in new window.

Title on links is not well supported - especially on mobile user agents where it's hard to see a new tab/window has opened (so problem is more severe)

The HTML 5.1 draft says:
"Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification"

Proposed Change:
Remove this example, since it conflicts with another spec, and it's hard to see many cases where this would pass the success criteria.

On http://www.w3.org/TR/WCAG-TECHS/failures.html#F42 example 2 there is code for an image that lacks the <img> element.

In H42 the resources section (http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/H42) contains a link to a non-existant RNIB blog post on headings "Quick tips for accessible headings". This resource should be removed or replaced. Also, the 2004 Eric Meyer resource seems dated and it is worth identifying better resources.

F91 (http://www.w3.org/TR/WCAG-TECHS/F91.html) is about not marking up table headers correctly.

The procedure reads:
For all data tables, check if table headers can be correctly programmatically determined by use of one of the following mechanisms:

1. headers marked up with table header (th) elements, optionally with scope attributes
2. headers and data cells associated using headers and id attributes
3. headers marked up as td elements with the scope attribute
4. headers marked up with ARIA role attributes rowheader or columnheader

Suggested changes:
"For all data tables, check if table data cells and table heading cells can be correctly associated programmatically by use of one of the following mechanisms:"

"1. headers marked up with table header (th) elements and the appropriate scope attribute, unless the table has headers only in the first row or column, in which case the scope attribute is optional."

Summary of Issue: Pause/resume controls required also when moving content initially paused?
Comment (Including rationale for any proposed change):
According to SC 2.2.2 Pause, Stop, Hide, controls or documented means to stop/pause and resume moving content is required for content that starts automatically. Does that mean that moving content that is initially paused but can be activated by the user, there is no requirement to pause it once it is running? We just have this case in a web site test).

Refer to “User Agent and Assistive Technology Support Notes” in SCR21 -
http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/SCR21

The use of the word ‘insure’ seems incorrect. 'Ensure' would be more
suitable.

-Devarshi

Refer to technique G86:
http://www.w3.org/WAI/GL/2013/WD-WCAG20-TECHS-20130711/G86.html

I hope it is only me who is getting disoriented trying to comprehend the
technique's title. The title reads, "G86: Providing a text summary that
requires reading ability less advanced than the upper secondary education
level."

However, the example and the procedure both state, "summary requires
reading ability less advanced than the lower secondary education level."
Isn’t there a disconnect between the title of the technique and its
contents therein?
Proposed Change: Modify the title to something like, "G86: Providing a text
summary that requires reading ability less advanced than the lower
secondary education level before an article," etc.

Refer to “G159: Providing an alternative for time-based media for
video-only content”-
http://www.w3.org/TR/2013/NOTE-WCAG20-TECHS-20130905/G159
The first sentence under Description uses ‘an’ before the word ‘video’ but
there is no vowel type sound in 'video.'
Change the sentence to:
The purpose of this technique is to provide an accessible alternative way
of presenting the information in a video-only presentation.

Hi,
I'm interested to know what updates were published on July 11 2013 ? I had captured the requirements on January 2013 and I'm interested to know what is new or different.

The section "User Agent Support for WAI-ARIA" is woefully out of date, and incomplete. FF3? I'm using FF20. IE8? IE11 is in Beta. What of Chrome? Safari? (Opera? Yandex?) - and what about mobile? Not trying to be overly critical here friends, but this hurts rather than helps IMHO.

Proposed Change:
1) Date-stamp any specific mention of User-Agents (and AT): ie. at Sept. 1, 2013 the support for...

2) Perhaps instead of entrenching this into the document, make that support chart a stand-alone document that is even more "living" than this. Perhaps Steve's http://html5accessibility.com/ gets rolled in-house and referenced instead?

ChromeVox does currently support longdesc - please remove "(planned)".

F91 is about tables that don't contain heading markup, but the example contains </th> closing tags (looks like copy-and-paste error).

<td>33</th>
<td>169</th>
<td>59</th>

PS Comment form needs update: can't choose items beyond F89


Proposed Change:
Change:
<td>33</th>
<td>169</th>
<td>59</th>
to:
<td>33</td>
<td>169</td>
<td>59</td>