Public document·View comments·Disposition of Comments·
Accessibility Guidelines Working Group Other specs in this tool Accessibility Guidelines Working Group's Issue tracker
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.
| Commentor | Comment | Working Group decision | Commentor reply |
|---|---|---|---|
LC-2791
Laura Carlson <laura.lee.carlson@gmail.com> (archived comment) |
|
Thank you for your comment. The WG agrees that an example detailing this method may help people understand how this works and what limitations exist. We will add an additional paragraph to the description and example 2 will be added as follows: [DONE] description new second paragraph: 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. An advantage of providing the description within the same page as the image is that all users can access the description. A limitation of this method, as well as in providing multiple descriptions on a single separate page, is that current implementations supporting longdesc read all text on the page that follows the start of the long description. 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. [DONE] Example 1: Using longdesc to refer to a long description contained on a separate resource. (title of example changed to clarify) [DONE] Example 2: Using longdesc to refer to a long description within the same page. <img longdesc="thispage.html#desc" alt="Line graph of the number of subscribers" src="http://www.company/images/graph.png"> <div id="desc"> <!-- Full Description of Graph --> <div> |
tocheck |
LC-2826
david10 <0@sympatico.ca> (archived comment) |
|
Thank you for your comment. The working group agrees and will remove this technique. | tocheck |
LC-2810
harry.loot <s@ieee.org> (archived comment) |
|
Thank you for your comment. According to our testing, onkeypress is not redundant to onclick for non-native HTML controls, that is, for HTML elements that are not natively focusable. If a developer makes an image clickable with onclick that item does not respond to keyboard events unless onkeypress is provided. It is accurate that the author does need to control the script so that the appropriate keypress is accepted and other keypresses are ignored, but this is detailed in the example's description. We would welcome an onmousedown/onkeydown example if you or others wish to provide one to be added to this technique. The description of the technique does not currently draw the distinction between native and non-native HTML controls, which is confusing. We have updated the technique to make this clearer: [DONE] Change Note 1 to: "Although click is in principle a mouse event handler, most HTML and XHTML user agents also process this event when a native HTML control (e.g. a button or a link) is activated, regardless of whether it was activated with the mouse or the keyboard. In practice, therefore, it is not necessary to duplicate this event when adding handlers to natively focusable HTML elements. However, it is necessary when adding handlers to other events, such as in Example 2 below. |
tocheck |
LC-2792
Laura Carlson <laura.lee.carlson@gmail.com> (archived comment) |
|
Thanks for your comment and suggested text. This information is useful, and will be incorporated into the 'User Agent and Assistive Technology Support Notes' found on http://www.w3.org/WAI/GL/2013/WD-WCAG20-TECHS-20130711/H45.html#ua2.19.1 to read: [DONE] User Agent support for longdesc varies, but overall support is improving. Screen readers such as JAWS, NVDA, and Window-Eyes support longdesc, but Voiceover 4.0, Orca 2.32.0, and screen magnifier Zoomtext 10.0 do not yet support the longdesc attribute. Browsers including Internet Explorer, Firefox, Opera, and Chrome (planned) all support longdesc. |
tocheck |
LC-2799
Devarshi Pant <devarshipant@gmail.com> (archived comment) |
|
Response to Commenter: Thank you for his suggestion. We have added the following information to the Description for PDF17: A more direct way of going to a page is to use the shortcut for the View > Page Navigation > Page menu item. On Windows, this shortcut is "Ctrl + Shift + N"; on Mac OS, it is "Cmd + Shift + N". This brings up a dialog box to go to a specific page number. |
tocheck |
LC-2809
harry.loot <s@ieee.org> (archived comment) |
|
Thank you for your comment. Since this is representing an equivalent of the video your latter suggestion with the colon makes more sense and we will make the change. | yes |
LC-2800
jonathanmet <z@gmail.com> (archived comment) |
|
Thanks for the comment. We understand that at this time PDF/UA requires that lists are constructed with Lbl and LBody tags inside each LI tag, but we also understand that current technologies do not distinguish between LI tagged elements with this internal tag structure from those that do not. The changes that you propose are reasonable but given that there is no difference for the end user we will defer this work until there is a difference. If you are interested in contributing the changes you suggest then the working group will be able to review that submission to be included. It is also worth noting that techniques assume that users are familiar with the technology spec, and that the techniques contain a reference to the PDF spec to provide more details for people who need them. | tocheck |