W3C

Disposition of comments for the Accessibility Guidelines Working Group

Single page view

1-20 21-27

Not all comments have been marked as replied to. The disposition of comments is not complete.

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-2562 Andrew Arch <andrew.arch@finance.gov.au> on behalf of Australian Government Information Management Office
Readers may interpret this list as Ëœonly these versions and later" support PDF accessibility.

Proposed Change:
AGIMO requests urgent clarification on the versions of the assistive technologies (AT) that fully or partially support PDF accessibility through the proposed Techniques. This is already done, in part, for WindowEyes.

To assist organisations and governments establish when PDF is suitably "Accessibility Supported" (http://www.w3.org/TR/WCAG20/#accessibility-supporteddef) for their audience, a table of AT version by PDF techniques is highly desirable. This table may only require a few versions older than the current release, where applicable (i.e. support is available in those releases).

It will be difficult for the Australian Government to determine the use of PDF as a WCAG 2.0 conforming technology, under the definition of Accessibility Support for our jurisdiction, without this clarification.
As with our other techniques, we have attempted to describe known user agent and AT support issues with current versions of those tools. Maintaining an accessibility support database is outside the scope of the WCAG WG charter (http://www.w3.org/WAI/GL/2010/06/charter), particularly given the wide variance in available user agents and assistive technology in different parts of the world. We hope an effort could emerge to share accessibility support information among authors, to relieve the burden of assuring that they are using techniques that are supported for their users. The examples in the PDF techniques link to PDF files that may be used for testing the techniques. tocheck
LC-2568 Andrew Arch <andrew.arch@finance.gov.au> on behalf of Australian Government Information Management Office
PDF Techniques - The examples with the illustrations are very useful, but we note they are exclusively from Word, OpenOffice Writer and Acrobat, and not necessarily the latest versions.

Proposed Change:
The W3C may like to consider including examples and illustrations from other common PDF authoring tools such as WordPerfect and InDesign.

The guidance would greatly benefit the use of a hide/reveal option (or link to a separate URI), displaying only examples and illustrations that are of particular use to the reader. This functionality is already available in other portions of the W3C site, to great value, such as the "How to Meet WCAG 2.0 Quick Reference" and "Diversity of Web Users".

In regards to Acrobat, the examples and illustrations refer exclusively to Acrobat 9 Pro. Acrobat X Pro is available and may need to be included in examples and illustrations. We are aware of many organisations that are also still using Acrobat 8 Pro, so examples with this version would also make a welcome addition if there are any differences in the capabilities or processes from Acrobat 9.

Similarly in regards to Microsoft Office Word, examples and illustrations refer mostly to Word 2007 and sometimes to Word 2003. In other places Word seems to be used generically with no version indicated. With Word 2010 in common usage, this needs to be included in the examples and illustration. Where Word is just referred to, it would be useful to indicate the version that the discussion is relevant for. Word versions for Mac OSX should also be included.
Thank you for your comments.

As noted in the technology notes for PDF techniques, the techniques use a snapshot of tools in fairly wide use when the techniques were reviewed. In addition, each PDF example notes that other tools may provide similar functions. It is not possible or practical for the WCAG Working Group to maintain an exhaustive list of tools that can be used. Future versions of techniques will continue to emphasize tools in common, current use (but not exhaustively) and consider ease-of-use features.
tocheck
LC-2536 Devarshi Pant <devarshipant@gmail.com> (archived comment)
Dear Editors – Thank you for the feedback. I have a few comments.



1. This is not a sufficient technique for SC 2.4.6, which requires
that headings
and labels be descriptive, but does not require that they be present on the
page. As such, SC 2.4.6 addresses the text used for the heading or label.



Devarshi: Agreed. This should probably be listed as an advisory to Guideline
2.4. Any suggestions are welcome.





2. This could be an advisory technique, that is, a technique that is
not sufficient
for one of the success criteria, but which may make the contents more
accessible. However, it is still not clear which success criteria this
should be advisory to. Possibly to Success Criterion 2.4.10 (Section
Headings are used to organize the content) or to Guideline 2.4 (Provide ways
to help users navigate, find content, and determine where they are).



Devarshi: It can be an advisory to Guideline 2.4.





3. We have some concerns about using invisible text in CSS, especially with
ARIA landmarks on the horizon. The CSS for hiding them is not 100% stable.
Especially in right-to-left layouts, there are problems which left-to-right
layouts don't have. There are also ever changing decisions by screen readers
about what patterns they support. This technique would need to include the
technical details for how to hide the text using CSS.



Devarshi: Use of landmark roles and what this technique proposes are two
different things. Landmark roles are great, but their presence should not
undermine this technique.



I am not clear why this instability of text hidden using css is pointed out
here. Please note that the current w3 and wai pages use a h2 header called
<Site Navigation> hidden via css; refer to http://www.w3.org/ and
http://www.w3.org/WAI/. So far, it has worked, and more importantly without
users even noticing that this header was hidden.



Regarding the technical details needed, I will only be able to provide the
basic CSS required to hide the text.



Regarding issues with rtl layouts, I am not in favor of this technique
encompassing multiple design styles. This technique is for ltr layouts, and
if not including rtl will be a concern, a note stating this could be made in
the technique. I personally feel the most fundamental idea should be
conveyed, and then it is upon the designers and developers to supply a CSS
that hides text in an rtl layout, based on their understanding of this
technique.



Regarding differing screen reader patterns, I am not aware of this, not
since I started using them, though I cannot rule out changing user
patterns. Please clarify this point.



4. We also have concerns with requiring level 3 headings, rather than whatever
heading element works in the context of the page structure.



Devarshi: Agreed. This should be open to any header element.





5. The related techniques do not seem relevant to this technique, in that they
are not presenting alternative techniques for addressing this requirement.



Devarshi: G148 seems to be the most relevant. Any suggestions are welcome.



6. The test procedure should describe what needs to be true of the coding,
not how to test operationally. While we find it necessary to provide
operational tests for general techniques, they are less reliable than tests
that focus on the underlying technology. See the published CSS techniques
for examples of how to describe CSS tests.



Devarshi: Agreed.



Basically, except 3, the rest is fine with me.



Thanks,

Devarshi

Response from WG:
This could be an advisory technique for Guideline 2.4.

If you want to limit this technique to left-to-right layouts, please make that clear in the description.

Differing screen reader patterns would surface as accessibility support notes. You may wish to include a note similar to Note 1 in "C7: Using CSS to hide a portion of the link text". The technique of using CSS to hide text are very similar in C7 and in your proposed technique, and you may be able to borrow from other parts of that technique.

Fesponse from commenter:
1. This is not a sufficient technique for SC 2.4.6, which requires that headings and labels be descriptive, but does not require that they be present on the page. As such, SC 2.4.6 addresses the text used for the heading or label.

Devarshi: Agreed. This should probably be listed as an advisory to Guideline 2.4. Any suggestions are welcome.

2. This could be an advisory technique, that is, a technique that is not sufficient for one of the success criteria, but which may make the contents more accessible. However, it is still not clear which success criteria this should be advisory to. Possibly to Success Criterion 2.4.10 (Section Headings are used to organize the content) or to Guideline 2.4 (Provide ways to help users navigate, find content, and determine where they are).

Devarshi: It can be an advisory to Guideline 2.4.


3. We have some concerns about using invisible text in CSS, especially with ARIA landmarks on the horizon. The CSS for hiding them is not 100% stable. Especially in right-to-left layouts, there are problems which left-to-right layouts don't have. There are also ever changing decisions by screen readers about what patterns they support. This technique would need to include the technical details for how to hide the text using CSS.

Devarshi: Use of landmark roles and what this technique proposes are two different things. Landmark roles are great, but their presence should not undermine this technique.

I am not clear why this instability of text hidden using css is pointed out here. Please note that the current w3 and wai pages use a h2 header called <Site Navigation> hidden via css; refer to http://www.w3.org/ and http://www.w3.org/WAI/. So far, it has worked, and more importantly without users even noticing that this header was hidden.

Regarding the technical details needed, I will only be able to provide the basic CSS required to hide the text.

Regarding issues with rtl layouts, I am not in favor of this technique encompassing multiple design styles. This technique is for ltr layouts, and if not including rtl will be a concern, a note stating this could be made in the technique. I personally feel the most fundamental idea should be conveyed, and then it is upon the designers and developers to supply a CSS that hides text in an rtl layout, based on their understanding of this technique.

Regarding differing screen reader patterns, I am not aware of this, not since I started using them, though I cannot rule out changing user patterns. Please clarify this point.

4. We also have concerns with requiring level 3 headings, rather than whatever heading element works in the context of the page structure.

Devarshi: Agreed. This should be open to any header element.

5. The related techniques do not seem relevant to this technique, in that they are not presenting alternative techniques for addressing this requirement.

Devarshi: G148 seems to be the most relevant. Any suggestions are welcome.

6. The test procedure should describe what needs to be true of the coding, not how to test operationally. While we find it necessary to provide operational tests for general techniques, they are less reliable than tests that focus on the underlying technology. See the published CSS techniques for examples of how to describe CSS tests.
Devarshi: Agreed.

Basically, except 3, the rest is fine with me.
At a discussion in the working group concerns about hidden text, we are planning to draft a general technique about hidden text, both to document the technical details and the concerns that have been raised about the use of hidden text.

We don't have a schedule for this work, but when it is finished, you could combine that technique with this proposal for using hidden text to provide headings and create an advisory technique to Guideline 2.4.
tocheck
LC-2549 Shawn Henry <shawn@w3.org> (archived comment)
G140: Separating information and structure from presentation to enable different presentations says: "Following this technique allows user agents to:... Modify the presentation of content by substituting alternate presentation rules attached to structural features."

There is a problem with Example 2 and I think it should be deleted. Currently with PDF users cannot substitute alternate presentation rules to structural features.


Proposed Change:
Delete Example 2.
[DONE] Change last sentence of Example 2 to The information in these tags can be used by assistive technologies or different viewers to perform meaningful structure transformations (e.g., generating a list of sections) or to support interaction with content based on structural characteristics (e.g., jumping to the start of forms). For example, ClaroRead displays PDF by transforming it to an HTML document, using the PDF tags as the basis for the structure of the HTML.

[DONE] Change "Following this technique allows user agents to:" ->
"Examples of ways in which user agents can use structural information to transform the presentation of the content include:"
The technique applies to PDF (tags providing semantics etc..), apart from this particular bullet point.

[DONE] Add ClaroRead (http://www.clarosoftware.com/index.php?cPath=355&s=bgrrjpjkvotks1d4lcgccgnkq1) to the resources for G140.

Response: We feel that Tagged PDF is an appropriate example of this technique, and have reworded the example to make it clearer.
tocheck
LC-2538 Sylvie Duchateau <sylvie.duchateau@snv.jussieu.fr> (archived comment)
This note talks about older screen readers and browsers: jaws 7, window-eyes 5, firefox 1... It also only refers to windows compatible technologies. Could this part be more general and indicate that older UAs do not behave properly?
We tested explicit labels and titles on form fields with Voiceover with safari, jaws 11 and the open source screen reader NVDA, as well as Window-eyes 7.2 and it worked fine.

Proposed Change:
Reword this section to invite on caution inusing this and include newer technologies and user agents.
The community badly needs a database of information about accessibility support for different OS/UA/AT combinations. We wish we could refer people to an actively maintained source of this information. Unfortunately, the WCAG WG does not have the resources to produce that information.

The user agents notes reflect the status of known user agent support at the point at which the technique was written. We do not expect to be updating user agent information in older techniques.
tocheck
LC-2539 Sylvie Duchateau <sylvie.duchateau@snv.jussieu.fr> (archived comment)
This applies to all pdf techniques explaining how to proceed with ms office

The examples only talk about Ms office 2007. May be add microsoft office 2007 and greater?
The examples list MS Office 2007 specifically so that they will continue to be correct as MS Office evolves. We cannot predict how the user interface will change in MS Office, and we do not want people to be confused if they try to follow this example with a different version of MS Office.

We cannot commit to updating these examples as new versions of the authoring tools are released. These are examples meant to demonstrate how to generate content that conforms to this technique in a specific version of the authoring tool.
tocheck
LC-2511 Detlev Fischer <fischer@dias.de> (archived comment)
Our screen reader tests of Technique G167 has shown that it is currently not sufficiently supported by Assistive Technology and therefore should not appear in the list of WCAG techniques. In our tests (compare http://testcases.bitvtest.de/index/html/form/g167.html ), it surfaced that currently only NVDA interprets the button as label of the input field before it.


Proposed Change:
Remove G167.
Success criterion 3.3.2 does not require programmatic determination. Therefore, even though most screen readers may not support G167, using an adjacent button to label the purpose of a field, the technique may still satisfy the success criterion, as it does provide instructions which help sighted users understand the form control, and may also help screen reader users who may comprehend the relationship between the button and the field via their reading-order proximity to one another. As stated in the technique, a programmatically determined name must also be present to fulfill success criterion 4.1.2, thus providing additional information to screen reader users about the field. tocheck
LC-2510 Guy Moreau <guy.moreau@hrsdc-rhdcc.gc.ca> (archived comment)
The draft adds: "[begin add]This failure would apply equally in a case where the background image was declared in the HTML style attribute, as well as in a case where the background image declaration was created dynamically in a client script (see example 3 below).[end add]" but the title does not reflect this significant and wonderful addition.

The proprose change makes the naming more general and applicable to all ways to provide an non-decorative img and also give a subtle hint what solution.

Proposed Change:
Modify name to:
Failure of [...] due to not using the img tag for images that [...]
CSS, in our estimation, can refer to both of the newly added styling methods mentioned in the description. Even when added via script, the background image property is still a CSS property, as are properties included in the style attribute.

We would prefer to include CSS in the title, as opposed to the more generic title suggested in the comment, so that readers will quickly understand which specific methods of adding images are in fact a failure.

The suggested title in the comment, i.e. not using the img tag, might then have to be expanded to include input elements of type image at the very least, perhaps other elements as well, thus rendering the title verbose.
tocheck
LC-2569 Makoto Ueki <makoto.ueki@gmail.com> (archived comment)
The note reads "Even though this is currently invalid, it is provided as a transitional technique to make this function work."
Was this technique used before? This example looks very strange because none of WAIC working group members have used this technique before. We would simply use <a> element for this. This example is not useful.

Proposed Change:
Could you tell us the reason why this example is needed?
In our opinion, this example should be deleted.
[DONE] Change first sentence of example to "This example shows a custom image control for which both the mouse and the keyboard can be used to activate the function."

[DONE] Add to end of note: "Custom controls like this should also use WAI-ARIA to expose the role and state of the control."

Proposed response:
Using and manipulating non-semantic elements does happen increasingly in self-styled widgets, mostly because designers don't want the default appearance of semantic elements (think of checkboxes) and sometimes because they want extended functionality (for example, to express 'partly checked' above a group of checkboxes). To the extent that self-styled widgets have become more popular, we provide this example to demonstrate how to add keyboard access. As we add WAI-ARIA techniques, we hope to provide better examples of custom controls.
tocheck
LC-2563 Andrew Arch <andrew.arch@finance.gov.au> on behalf of Australian Government Information Management Office
Generating PDF Files - http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110621/pdf.html#pdf_notes_acc-sup_files_generating

The final paragraph of this section appears unnecessarily complex, and its level of technical advice may not be appropriate to a general audience. It states "the resulting PDF files may not make the best use of the high-level PDF imaging model". If this means that some PDF generators may create image-based PDF files or PDF files with no semantic structure, then we suggest that these situations be included as examples. If the paragraph has another meaning, examples are still recommended to help clarify for readers what the issue means in practice.

Proposed Change:
Clarify the last paragraph of this section; possibly include examples.
[DONE] replace "the best use of the high-level PDF imaging model" -> "the best use of the high-level PDF imaging model relied upon to expose the semantics of the document"

[DONE] Add to the end of "Generating PDF Files":

For example, since the printer driver or translator targets correct visual output, information about the semantics of the document may not be sent at all or may be ignored when creating the PDF output. As a result, headings may not be tagged as such, or link text may not be associated with its link object. Check with the vendor of any PDF authoring tool to be understand how to use the tool in a way that produces the best tagged output.

Response: We have added additional explanation to this section and hope that the issue is clearer.
tocheck
LC-2564 Andrew Arch <andrew.arch@finance.gov.au> on behalf of Australian Government Information Management Office (archived comment)
PDF Authoring Tools that Provide Accessibility Support - http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110621/pdf.html#pdf_notes_acc-sup_files_applications

Many PDF generators do not allow creation of accessible PDF files.

Proposed Change:
Consider adding a statement (or warning) in this section to indicate that many of the (inexpensive) PDF creation tools do not enable authors to create accessible tagged PDF files. Furthermore, there has been, or perhaps may still exist, an issue when people print to PDF from their word processing software and in the process create untagged files. Readers should also be warned about this issue if it remains unresolved.
Proposed response: The WG thanks you for your comment. We tried to address this topic in the introductory paragraphs to this section (PDF File Production and Accessibility) and would welcome suggestions for how to make that material clearer.

We have also added the following statement to the end of this section:
[DONE] Note: Care should be taken when choosing PDF creation tools from the many available, as some may not support creation of tagged PDF files.
tocheck
LC-2565 Andrew Arch <andrew.arch@finance.gov.au> on behalf of Australian Government Information Management Office
PDF Technology Notes -http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110621/pdf.html#pdf_notes

Applicability of techniques that aren't specific to PDF may be missed by authors just interested in PDF techniques and only reading the page "PDF Techniques for WCAG 2.0".

Proposed Change:
Include a statement in the Technology Notes that the general techniques from WCAG 2.0 must also be followed in preparing PDF files, for example, techniques for sufficient contrast and providing abbreviations.

Such a statement about general techniques could possibly be placed in the paragraph preceding the H1 before the Table of Contents where there is a link to "other technologies", though repeating it within the Technology Notes with examples is also recommended.
ABSTRACT (http://www.w3.org/WAI/GL/WCAG20-TECHS/#abstract)

##Add a sentence to the 1st para:

"Techniques for WCAG 2.0" provides information to Web content
developers who wish to satisfy the success criteria of Web Content
Accessibility Guidelines (WCAG) 2.0 [WCAG20]. Techniques are specific
authoring practices that may be used in support of the WCAG 2.0
success criteria. This document provides "General Techniques" that
describe basic practices that are applicable to any technology, and
technology-specific techniques that provide information applicable to
specific technologies.<ADD> Technology-specific techniques do not
supplant the general techniques: content developers should consider
both general techniques and technology-specific techniques as they
work toward conformance.</ADD> Use of the techniques provided in this
document makes it easier for Web content to demonstrate conformance to
WCAG 2.0 success criteria than if these techniques are not used.


##INTRODUCTION TO TECHNIQUES(http://www.w3.org/WAI/GL/WCAG20-TECHS/intro.html)

Add the following as the 2nd para in the Introduction:

Techniques are specific authoring practices that may be used in
support of the WCAG 2.0 success criteria. This document provides
"General Techniques" that describe basic practices that are applicable
to any technology, and technology-specific techniques that provide
information applicable to specific technologies. Technology-specific
techniques do not supplant the general techniques: content developers
should consider both general techniques and technology-specific
techniques as they work toward conformance.


##QUICK REFERENCE (http://www.w3.org/WAI/WCAG20/quickref/)

Add as a 3rd para (above the <b>Note</b> para):

Technology-specific techniques do not supplant the general techniques:
content developers should consider both general techniques and
technology-specific techniques as they work toward conformance.



INTRODUCTION TO TECHNOLOGY-SPECIFIC TECHNIQUES (e.g.,
http://www.w3.org/WAI/GL/WCAG20-TECHS/pdf.html):

##Add a sentence to the para above the Table of Contents, and create 2 paras:

This Web page lists PDF Techniques from Techniques for WCAG 2.0:
Techniques and Failures for Web Content Accessibility Guidelines 2.0.
<ADD>Technology-specific techniques do not supplant the general
techniques: content developers should consider both general techniques
and technology-specific techniques as they work toward
conformance.</ADD>

For information about the techniques, see Introduction to Techniques
for WCAG 2.0. For a list of techniques for other technologies, see the
Table of Contents.
tocheck
LC-2566 Andrew Arch <andrew.arch@finance.gov.au> on behalf of Australian Government Information Management Office
PDF6 - http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110621/pdf.html#PDF6

Word cannot indicate cells as row headings

Proposed Change:
Add a note to the Description (or to the Word example) indicating that Word can only indicate cells as column headings and not as row headings which has to be done another way (e.g. with Acrobat) if applicable. This issue may, or may not, apply to other authoring tools – if it does apply, then clarifications needs to be added to those examples also.
[DONE] Add Note to the end of Example 1: "Microsoft Word can only mark up cells as column headings, not as row headings. Only the first row can be marked as heading for all table columns. When the table has row headings or a more complex heading structure, this mark-up must be added in a PDF editor such as Acrobat Pro."

[DONE] Add Note to the end of Example 2: "OpenOffice.org Writer can only mark up cells as column headings, not as row headings. Only the first row can be marked as heading for all table columns. When the table has row headings or a more complex heading structure, this mark-up must be added in a PDF editor such as Acrobat Pro."

Response:
Thank you, we have added this clarification to Examples 1 and 2.
tocheck
LC-2567 Andrew Arch <andrew.arch@finance.gov.au> on behalf of Australian Government Information Management Office (archived comment)
User Agents - http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110621/pdf.html#pdf_notes_ua

This section only mentions Acrobat Pro, Adobe Reader, and Kurzweil 3000.

Proposed Change:
Many other PDF readers are available (e.g. http://en.wikipedia.org/wiki/List_of_PDF_software) and if any of them can reveal PDF tags they should also be listed in this guidance. Name and version of tools would be highly useful. Conversely, if no other PDF reader (apart from the three listed) are capable of revealing PDF tags, then this should be stated if known (noting information is current at time of publishing only). Additional guidance would be useful in this area.
Proposed Response: To our knowledge, there are no other PDF readers that expose PDF tags via the accessibility APIs. We had previously gone through the Wiki artcle on PDF and assessed those, and our document reflects our findings as of earlier this year when we did so.

We do not want to say there are no others in this document because of the changing pace of technology. New tools can be released at any time, and this document is updated infrequently.
tocheck
LC-2533 Earl Cousins <earl@automatedculture.com> (archived comment)
The techniques described in FLASH17 regarding keyboard access to a Flash object, and the working example, only work in Firefox and IE for Windows. They don't work in Chrome (Win/Mac) or either Firefox or Safari for Mac.

The technique makes no mention of these limitations, which seem unreasonable (doesn't seem to work in any webkit browsers at all).

Proposed Change:
Short term: Update the technique to reflect the current level of browser support.

Long term: Modify the techniques to increase the supported set of browsers (especially webkit).
[DONE] See changes in http://trace.wisc.edu/wcag_wiki/index.php?title=Preventing_a_keyboard_trap_in_Flash_content&diff=39599&oldid=36115

Proposed response:
Thanks you for suggesting these User Agent notes for this technique. We have both updated the technique so that it works with more User Agents and updated the User Agent Notes to reflect the current level of browser support and to note the dependence on Javascript.
tocheck
LC-2534 Roberto Scano <r.scano@webprofession.com> (archived comment)
Hi, an issue that comes out here in Italy (where in the next month we will
have approved the government law upgrade for follow WCAG 2.0) about the
audio captcha.

http://www.w3.org/TR/WCAG20-TECHS/G144.html

a lot of audio captcha are in English language so there is need to put
something in techniques / examples regarding that an alternative audio
captcha for visual captcha should (I prefer must) respect the primary
language of the page.
The WCAG WG thanks you for your comment. For clarification, we have decided to add "Some CAPTCHA tasks rely on understanding written or spoken language. Such CAPTCHAS should use the same language as the main language of the page." at the end of the "description" section of the referenced technique (G144). We are also filing this issue with the Protocols and Formats Working Group to request that this issue be further explored in the document "Inaccessibility of CAPTCHA" <http://www.w3.org/TR/turingtest/>. tocheck
LC-2537 Sabastien Delorme <sdelorme@atalan.fr>
Example 4: Checking the reading order using Reflow in Adobe Acrobat 9 Pro
Example 5: Checking the reading order using the Order panel in Adobe Acrobat 9 Pro

Theses two examples explain how checking the reading order with the reflow mode and the order panel.
But I encountered many problems with these features and the reader order.

The Order navigation panel in Acrobat Pro is designed for checking and correcting the reading order of tagged content on a page. However, in Acrobat Pro 10 (and previous versions), this tool is very difficult to use as it manages both the reading order of content and the order objects visually overlay each other on the page.

The numbering used on the Order navigation panel does not correspond to the reading order but to the order the different content layers on the page overlay each other. So, when you want to check the reading order of content by a screen reader, the displayed numbering may be inaccurate.

For example :
** Document 1 http://www.pdf-accessible.com/IMG/pdf/test-ordre-14.pdf
In this document :
- reflow order is "ordre matus balatum belli"
- Order panel shows the order is "ordre matus balatum belli"
- and the reading order is well "ordre matus balatum belli"

** Document 2 http://www.pdf-accessible.com/IMG/pdf/test-ordre-15.pdf
In this document :
- reflow order is "ordre matus balatum belli"
- Order panel shows the order is "ordre matus balatum belli"
- BUT the reading order is "balatum belli ordre matus"

So, it is disturbing to test the reading order with Order panel or reflow mode.
Because the reading order is only testable with certainty on the Tags panel.

I tried to explain this in a better way on AcceDe PDF manual (page 46) :
http://www.pdf-accessible.com/IMG/pdf/making-PDF-accessible-Acrobat.pdf

Proposed Change:
It is difficult to delete theses two examples because in many cases the reading order, reflow mode and the Order panel will be the same.

But for example with inDesign documents it's could totally different.

I propose a new example
"Checking the reading order using the Tags panel in Adobe Acrobat 9 Pro"
[DONE] 1. Add the following text at the end of Example 6:

Note: Reordering content with the Order panel is most appropriate for
simple text content within a PDF since modifications made with the
order panel can affect not only the reading order but the underlying
structure of content contained within the PDF. This may impact the
z-order for content on a page, including making some content become
hidden behind other content. Authors should save their work before
using the order panel and verify that the changes do not have adverse effects on the document.

[DONE] 2. Add the following 2 items to the Resources section:

- Adobe Acrobat 9 Pro Help:
http://help.adobe.com/en_US/acrobat/pro/using/WS58a04a822e3e50102bd615109794195ff-7ce6.w.html

- Making PDF documents accessible with Adobe Acrobat Pro:
http://www.pdf-accessible.com/IMG/pdf/making-PDF-accessible-Acrobat.pdf

[DONE] 3. Add Example 7:

Example 7: Repairing the reading order using the Tags panel in Adobe
Acrobat 9 Pro

This example is shown with Adobe Acrobat Pro. There are other software
tools that perform similar functions. See the list of other software
tools in PDF Authoring Tools that Provide Accessibility Support
(http://trace.wisc.edu/wcag_wiki/index.php?title=PDF_Technology_Notes).

To correct the reading order in Example 5, use the Tags panel:

1. Either:

o Drag-and-drop the <H1> tag to precede the required-field text
(tagged <H2>), or
o Cut-and-paste the <H2> tag to follow the <H1> tag.

In the following image, the reading order is correct for the text and
header. That is, the content elements <H1> and <H2> have been switched
into the correct reading order.

Image: tab-order-PDF3.jpg (attached)
alt text: Image showing the corrected reading order In
Adobe Acrobat Pro. The tags <H1> and <H2> have been switched and are
now in the correct order.
tocheck
LC-2540 Sailesch Panchang <spanchang02@yahoo.com> (archived comment)
Right, it is meant to be used to define a term like in a glossary. But it can be used effectively to represent content of the type LABEL: DATA. ... I mean not form controls but just text like:
<dt>Name</dt> <dd>xyz i.e name of person</dd>
<dt>Phone #</dt> <dd>person's phone#</dd> and so on.

Often there is such content displayed on the page either one below the other or horizontally and the label is styled / boldfaced so that it is visually distinct. So DL-DT-DD works fine in these instances if one chooses not to use a 2-col data table. The DL may be styled as needed.
Proposed Response: The WG thanks you for your input. This potential new use of definition list elements in this other context will be investigated for relation to a possible new/other technique and/or other SC. This is tracked in our ACTION-144 <http://www.w3.org/WAI/GL/track/actions/144>. The use proposed in your suggestion does not seem appropriate for the description of H40 and for SC 3.1.3. tocheck
LC-2554 Shawn Henry <shawn@w3.org> (archived comment)
Thank you very much for addressing objections to the phrase "accessible PDF documents" in previous edits. I've found it again in Resources listings: "Creating accessible PDF documents" (also the link is broken <http://www.adobe.com/accessibility/pdf>)

This is throughout http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110621/pdf.html -- I didn't find a way to comment at that level using the comment form.

Proposed Change:
Delete "Creating accessible PDF documents" throughout http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110621/pdf.html
Proposed response:
Thanks for pointing this out. We are changing the link text to "PDF and Accessibility" throughout our documents.

@@Action:
Change the link to "PDF and Accessibility" in all PDF techniques and Resources.
tocheck
LC-2512 Detlev Fischer <fischer@dias.de> (archived comment)
Example 3 does not fit the technique which relates to fixed-size containers, because here, the text container *does* resize (size defined in em).
Actually, I think what is *really* meant would have to be called "G179: Ensuring that there is no loss of content or functionality when the text resizes and text containers do not <del>resize</del> <ins>change width</ins> - at least this is what examples 1 and 2 refer to.

Proposed Change:
* Delete example 3
* Change name of technique to make it clear that the topic is *fixed width* containers that expand at the bottom through reflow of text when the text size is increased to 200%
Example 3 does not fit the title of the technique as you suggested, since the width of the container in this example is defined in em units. C28, specifying the size of text containers using em units, provides relevant examples for using em units.
Furthermore, the title of the technique is not appropriate for example 2, since in that example the container does resize its height.

[DONE] Proposed resolution: Remove example 3 and change title of technique to "G179: Ensuring that there is no loss of content or functionality when the text resizes and text containers do not change their width"
tocheck

1-20 21-27


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:40:29 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org