User Agent Accessibility Guidelines Working Group Teleconference -- 23 Jan 2014

<trackbot> Date: 23 January 2014

Longdesc review

<allanj> https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html

<allanj> greg preliminary comments - http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0017.html

<kford> acribe: kford

<kford> Scribe: kford

JA: So we have the new longdesc proposal.

JA and JS talk briefly.

GL: Have people had a chance to read my draft?

JA: Yes, I read it and was going through it.

GL: Do you want me to read all or what?

JR: I've read but would be good to go one by one to hear if people have feedback.

GL goes over his items.

<allanj> gl: comment1

<allanj> *1. Use Case keywords seem random:* In the section on Use Cases, the Requires and Helped By keywords (which link to appropriate entries in "Requirements for an Image Description Functionality") are a nice touch. However, I can't understand the choices made as to which keywords are listed for each use case. For example, why would Discountability be important for "Identifying a well-known...

<allanj> ...image", but not for "Describing a complex diagram", or why would Simple Return be useful for the latter but not the former?

GL: Neat idea in theory but in practice a challenge.

JA and JR agree as does kford.

<allanj> gl comment: *2. Contrast with ARIA DescribedBy:* The use case "Referring to an existing description" sounds like exactly what ARIA DescribedBy is used for, so it might be good to clarify why longdesc is also needed, and whether you're recommending one or both be used.

JR explains that ARIADescribedBy has to be on the existing page.

JS: Keep in mind that ARIA applies to more than HTML.

JR: I know that CG has a activity looking at where ARIA should apply.

<allanj> @@ comment 1 is mostly editorial

<Greg> "Consider adding some acknowledgement that longdesc is functionally equivalent to ARIA DescribedBy (for in-page links) and the proposed ARIA DescribedAt (for interpage links)." ?

Group has concerns about some items missing.

JS: Given how late in the process this document is I think w4e need to focus our comments.
... We need to focus on items we are not able to live with.

Some discussion on how to structure comments back.

GL: I don't think it makes sense for this document not to explain why they are creating something that on the surface seems it is duplicating something that already exists.
... It is like if someone came and proposed something that seemed to duplicate ARIA. Wouldn't we ask what's up?

JA: This is a much-discussed topic.
... At onepoint longdesc was considered gone but has been recently revivied.

<allanj> gl comment *3. Other image types:* I don't understand the decision to allow the new longdesc to apply only to img elements, as it seems to be just as appropriate for things like groups of images (which may make up one whole image as far as the user is concerned), svg elements, objects, and even tables or arrangements of colored divs. Can you please explain the rationale for not allowing it...

No real issues heard with GL item 2.

<allanj> ...on other elements?

<allanj> @@ comment 3 !important

Group talking about how it would be helpful to have this ability on other elements.

<Greg> "3. Other image types: I don't understand the decision to allow the new longdesc to apply only to img elements, as it seems to be just as appropriate for things like groups of images (which may make up one whole image as far as the user is concerned), svg elements, objects, and even tables or arrangements of colored divs. We recommend allowing longdesc to apply to other elements such as svg."

<Greg> "3. Other image types: We don't understand the decision to allow the new longdesc to apply only to img elements, as it seems to be just as appropriate for things like groups of images (which may make up one whole image as far as the user is concerned), svg elements, objects, and even tables or arrangements of colored divs. We recommend allowing longdesc to apply to other elements."

<allanj> gl comment: *4. Provide UI guidance:* The document should really provide some guidance or examples of how user agents could implement linked images with longdesc. Section 3.0.3 says "If the longdesc value is valid, User agents must make the link available to all users through the regular user interface(s)." but that's ambiguous as to whether it means "through the user agent's own UI (rather...

<allanj> ...than relying on assistive technology)" or "through the user agent's normal clicks and keystrokes for activating links". It's clear that the user agent can't simply provide a single standard hyperlink when the img is inside an anchor and also contains a longdesc unless that pops up a choice of jumps, but it could instead apprend a separate hyperlink to the longdesc, or it could provide a...

<allanj> ...separate command on the link's context menu and/or on a menu bar menu when the element has focus, etc. Of course, any guidance should be suggestions, rather than prescriptive, as we don't want to prevent user agent

<allanj> developers from providing new, innovative UI or UI that's appropriate for their product and its platform.

JR: This sounds good to me.

<Greg> We could add per Jim's suggestion "We also recommend you explicitly state that the longdesc link be actionable rather than allowing the user agent to merely display the URI (as is done by Firefox's View Image Info command)."

JA goes over how Firefox works here.

<allanj> +1

JA: I think we need to say that images that have longdesc be easily discoverable. That is you do not have to check each image.

<Jan> "User agents should enable users to discover when images in a page contain a long description."

<allanj> jr: 'should' change to 'must'

group working on some wording changes.

<allanj> a mechanism to reveal images with @longdesc, rather than discover

<Greg> Per Jim's suggestion, we could add something like:

<Greg> 7. Discoverable by users: Section 3.0.03 says 'User agents should enable users to discover when images in a page contain a long description.' but we believe that the spec should make this a requirement (must instead of should), and also ensure that the user does not need to try clicking on every element to find which have longdesc properties. Suggested wording, "User agents MUST enable users...

<Greg> ...to discover when images in a page contain a long description without having to query each element individually."

It works but expect pushback on the must part here.

<allanj> do we want a statement about UA should not require AT to have @longdesc revealed

JA and JR says it works.

kford goes over comment a bit more. Not blocking for us at all in submitting comments.

<allanj> gl comment: *5. Delimit blocks in the document:* As a purely editorial/formatting issue, the document should not convey information by graphical formatting alone. The problem is that the blocks starting with "This section is informative" are indented and have a differently colored background, but there is nothing textual to denote where the block ends. Thus, if one is reading or listening to...

<allanj> ...the text that reads "This section is informative Best practices for full descriptions of images are beyond the scope of this document, but there are many resources available. Authors should not rely solely on longdesc where standards exist to provide direct, structured access." it is not immediately clear whether the third sentence is inside or outside the informative block. The reader...

<allanj> ...may be able to infer it out from context in some cases, but that should not be required nor relied upon.

<allanj> @@comment 5 is editorial

<allanj> gl comment: *6. Web page contains insecure content:* FYI, when loading the page https://www.w3.org/WAI/EO/wiki/UAAG_review, my copy of Firefox 26.0 generates a warning saying "Firefox has blocked content that isn't secure. Most websites will still work properly even when this content is blocked." It links to the following page for details: https://support.mozilla.org/en-US/kb/how-does-content-isnt

<allanj> -secure-affect-my-safety.

<Greg> That should have been https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html

<Greg> 6. Web page contains insecure content:* FYI, when loading the page https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html, my copy of Firefox 26.0 generates a warning saying "Firefox has blocked content that isn't secure. Most websites will still work properly even when this content is blocked." It links to the following page for details: https://support.mozilla.org/en-US/k

<Greg> b/how-does-content-isnt

<allanj> @@comment 6 editorial

<Greg> Under the requirement "Structured Markup" they have "A user should be able to determine that there is a description available for a given image." This is not really related to structured markup, so should be under the requirement "Discoverability".

<allanj> We suggest moving "A user should be able to determine that there is a description available for a given image. " to the definition of Discoverability

<allanj> We suggest moving "A user should be able to determine that there is a description available for a given image. " in the definition of Structured Markup to the definition of Discoverability

<allanj> @@comment 7 is !important

<Greg> ...to discover when images in a page contain a long description, without having to query each element individually." A similar change should be made in the Requirements section where it currently says "A user should be able to determine that there is a description available for a given image." This should also be changed from SHOULD to MUST.

seems fine to me.

<allanj> +1

<allanj> ACTION: jim to write comments and send to both groups [recorded in http://www.w3.org/2014/01/23-ua-minutes.html#action01]

<trackbot> Created ACTION-936 - Write comments and send to both groups [on Jim Allan - due 2014-01-30].

Group is good with comments after discussion.

Group thanks GL for his work on comment review.

<Jan> scribe: Jan

review comments -

KF: I have to go...I want to be here to discuss Microsoft comments

Silas Comments

<allanj> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0015.html

JA: Oh...

<jeanne> http://www.w3.org/WAI/UA/2014/LCcomments-20140122.html

<allanj> silas comments: http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Jan/0000.html

JS: I don't have everything plugged in yet...

<jeanne> http://www.w3.org/WAI/UA/2014/LCcomments-20140122.html

JS: This is the big table http://www.w3.org/WAI/UA/2014/LCcomments-20140122.html

<allanj> greg recommended response to silas - http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0015.html

JR: SSB: I'm not sure if 1.7.4 (Save Copies of Stylesheets) is really needed.
... GCL: The Implementing document explains the rationale for this. Let us know if after reading that explanation you still feel it is not needed.

<allanj> SSB1: I'm not sure if 1.7.4 (Save Copies of Stylesheets) is really needed.

<allanj> this is something that all browsers allow already.

Draft Resolution SB1 The Implementing document explains the rationale for this. Let us know if after reading that explanation you still feel it is not needed. It should be noted that many browsers already implement this success criteria.

Resolution: SB1 The Implementing document explains the rationale for this. Let us know if after reading that explanation you still feel it is not needed. It should be noted that most desktop browsers already implement this success criteria.

<allanj> SB2: SSB: 1.8.7 (Reflow Text) - I think there's a possible misunderstanding here with the wording "text content in a graphical top-level viewport". Some developer might think "oh, if it's only about text in a top-level viewport, then it doesn't apply to text in a table (or other layout device) within that viewport", which is not ideal especially if such layout device is being used unnecessarily.

<allanj> Maybe add something like "This applies even if such text is included within other structures"?

GL: Reasonable concern...

<allanj> defined in viewport http://www.w3.org/TR/UAAG20/#def-viewport

<allanj> all discussion of viewports and text vs non-text

GL: Want to give users option to try to reflow tables...
... What about a note in the applicability notes...
... When we refer to viewports or elements...
... We are also referring to their children

<allanj> we have :

<allanj> content (web content)

<allanj> Information and sensory experience to be communicated to the user by means of a user agent, including code or markup that defines the content's structure, presentation, and interactions.

<allanj> reflowable content

<allanj> Web content that can be arbitrarily wrapped over multiple lines. The primary exceptions to reflowable content are graphics and video.

<allanj> proposal

<allanj> 1.8.7 Reflow Text: The user can specify that reflowable content in a graphical top-level viewport reflows so the text forms a single column that fits within the width of the viewport. (Level A)

JS: Don't most tools already do this?

GL: We need it because some people assume zoom of the whole page is enough

<Greg> We want to avoid having the developer interpret "web content that can be arbitrarily wrapped" to not include text. We note in the comments from one reviewer that they felt zoom should be good enough, that enlarging text (with wrap) should not be required.

<allanj> old version: 1.8.12 Reflowing Zoom:

<allanj> The user can request that when reflowable content in a graphical viewport is rescaled, it is reflowed so that one dimension of the content fits within the height or width of the viewport. (Level AA)

GL: So why did it change?

JR: Maybe as part of moving it to A from AA?

<allanj> http://www.w3.org/2013/10/17-ua-minutes.html#item04

<Greg> How about enhancing the definition of reflowable content to clarify that it refers to content that is technologically reflowable, even if a user agent chooses not to support reflowing it.

<allanj> jr: table is a structural element, don't want to linearize the table

<allanj> jr: some mode where there is no horizontal scrolling

JR: What if instead of splitting hairs we should had SC...have an option for thou shalt not horizontally scroll

<allanj> what happens with iframes

<allanj> gl: 1.8.9 covers them

<allanj> words reflow, 'solid' things (images, objects, etc) don't reflow

http://my.opera.com/ODIN/blog/opera-14-for-android-is-out

By default, Opera for Android uses the same text autosizing (aka FontBoosting) mechanism that can be found in Chrome for Android. E.g. if you visit this desktop-specific Wikipedia page about artichokes, you see that some of the text is displayed bigger, making it readable without having to zoom in. However, as FontBoosting is only applied selectively and interferes with author-defined text...

scribe: size differences, we've made it possible to turn this off in Settings, and choose for automatic text wrap instead. Turning on text wrap instructs Opera for Android to wrap lines no matter how much you zoom into a page so there's no need for horizontal scrolling.

<allanj> its the words that reflow, not the containers

<allanj> gl: should be able to squeeze a table

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

23 Jan 2014

Attendees

Contents

Longdesc review

review comments -

Silas Comments

Summary of Action Items

Scribe.perl diagnostic output