W3C home > Mailing lists > Public > public-html-a11y@w3.org > October 2011

Text Subteam Teleconference Minutes for 25 October

From: Janina Sajka <janina@rednote.net>
Date: Tue, 25 Oct 2011 14:20:12 -0400
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20111025182012.GI2816@sonata.rednote.net>
Minutes from the HTML-A11Y Task Force Text Subteam teleconference of 25 October are provided below in text and are available as hypertext at:

http://www.w3.org/2011/10/25-text-minutes.html


   W3C

                                                           - DRAFT -

                                                        SV_MEETING_TITLE

25 Oct 2011

   See also: IRC log

Attendees

   Present
   Regrets
   Chair
          SV_MEETING_CHAIR

   Scribe
          Léonie Watson, janina, leonie

Contents

     * Topics
         1. Favicons
         2. longdesc: progress on JS-response to Matt's updated proposal?
         3. meta name=generator: updates?
            +<http://www.w3.org/html/wg/wiki/ChangeProposal/meta_name%3Dgenerator_does_not_make_missing_alt_conforming>
         4. table summary: expanded use cases? <http://www.w3.org/html/wg/wiki/ChangeProposals/ReinstateTableSummary>
         5. generated content: progress on discussions? <http://www.w3.org/Bugs/Public/show_bug.cgi?id=13668>
         6. resuming work on document location for alt guidance Definition of "accessibility" (WG 6)
         7. generated content: progress on discussions? <http://www.w3.org/Bugs/Public/show_bug.cgi?id=13668>
     * Summary of Action Items
     __________________________________________________________________________________________________________________

   <Joshue108> Hi all

   <Joshue108> I can monitor on IRC

   <LeonieWatson> scribe: Léonie Watson

Favicons

   <LeonieWatson> KF: Wanted to bring up an issue. Not sure there is anything can be done. Most user agents do not have a
   concept of a favicon.

   <kford> The icon keyword may be used with link elements. This keyword creates an external resource link.

   <kford> The specified resource is an icon representing the page or site, and should be used by the user agent when
   representing the page in the user interface.

   <kford> Icons could be auditory icons, visual icons, or other kinds of icons. If multiple icons are provided, the user
   agent must select the most appropriate icon according to the type, media, and sizes attributes. If there are multiple
   equally appropriate icons, user agents must use the last one declared in tree order at the time that the user agent
   collected the list of icons. If the user agent...

   <kford> ...tries to use an icon but that icon is determined, upon closer examination, to in fact be inappropriate (e.g.
   because it uses an unsupported format), then the user agent must try the next-most-appropriate icon as determined by
   the attributes.

   <kford> User agents are not required to update icons when the list of icons changes, but are encouraged to do so.

   <kford> There is no default type for resources given by the icon keyword. However, for the purposes of determining the
   type of the resource, user agents must expect the resource to be an image.

   <kford> The sizes attribute gives the sizes of icons for visual media. Its value, if present, is merely advisory. User
   agents may use the value to decide which icon(s) to use if multiple icons are available.

   <kford> If specified, the attribute must have a value that is an unordered set of unique space-separated tokens which
   are ASCII case-insensitive. Each value must be either an ASCII case-insensitive match for the string "any", or a value
   that consists of two valid non-negative integers that do not have a leading U+0030 DIGIT ZERO (0) character and that
   are separated by a single U+0078 LATIN SMALL...

   <kford> ...LETTER X or U+0058 LATIN CAPITAL LETTER X character.

   <kford> The keywords represent icon sizes.

   <kford> To parse and process the attribute's value, the user agent must first split the attribute's value on spaces,
   and must then parse each resulting keyword to determine what it represents.

   <kford> The any keyword represents that the resource contains a scalable icon, e.g. as provided by an SVG image.

   <LeonieWatson> KF: My question to the TF is, looking at 4.1.2.4.5 of the specification, there's no provision to provide
   alternative descriptions for these images?

   <kford> Other keywords must be further parsed as follows to determine what they represent:

   <kford> € If the keyword doesn't contain exactly one U+0078 LATIN SMALL LETTER X or U+0058 LATIN CAPITAL LETTER X
   character, then this keyword doesn't represent anything. Abort these steps for that keyword.

   <kford> € Let width string be the string before the "x" or "X".

   <kford> € Let height string be the string after the "x" or "X".

   <kford> € If either width string or height string start with a U+0030 DIGIT ZERO (0) character or contain any
   characters other than characters in the range U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9), then this keyword doesn't
   represent anything. Abort these steps for that keyword.

   <kford> € Apply the rules for parsing non-negative integers to width string to obtain width.

   <kford> € Apply the rules for parsing non-negative integers to height string to obtain height.

   <kford> € The keyword represents that the resource contains a bitmap icon with a width of width device pixels and a
   height of height device pixels.

   <kford> The keywords specified on the sizes attribute must not represent icon sizes that are not actually available in
   the linked resource.

   <kford> In the absence of a link with the icon keyword, for Documents obtained over HTTP or HTTPS, user agents may
   instead attempt to fetch and use an icon with the absolute URL obtained by resolving the URL "/favicon.ico" against the
   document's address, as if the page had declared that icon using the icon keyword.

   <kford> The following snippet shows the top part of an application with several icons.

   <kford> <!DOCTYPE HTML>

   <kford> <html>

   <kford> <head>

   <kford> <title>lsForums €” Inbox</title>

   <kford> <link rel=icon href=favicon.png sizes="16x16" type="image/png">

   <LeonieWatson> JF: My first thought is that this is presentational content.

   <kford> <link rel=icon href=windows.ico sizes="32x32 48x48" type="image/vnd.microsoft.icon">

   <kford> <link rel=icon href=mac.icns sizes="128x128 512x512 8192x8192 32768x32768">

   <kford> <link rel=icon href=iphone.png sizes="57x57" type="image/png">

   <kford> <link rel=icon href=gnome.svg sizes="any" type="image/svg+xml">

   <kford> <link rel=stylesheet href=lsforums.css>

   <kford> <script src=lsforums.js></script>

   <kford> <meta name=application-name content="lsForums">

   <kford> </head>

   <kford> <body>

   <kford> ...

   <kford> For historical reasons, the icon keyword may be preceded by the keyword "shortcut". If the "shortcut" keyword
   is present, it must be come immediately before the icon keyword and the two keywords must be separated by only a single
   U+0020 SPACE character.

   <LeonieWatson> KF: Is it presentational data? It's a combination of things.

   <LeonieWatson> KF: It may be that this kind of thing should be exposed programmatically.

   <LeonieWatson> JF: I support this idea.

   <LeonieWatson> KF: It's possible to drag a favicon in IE and pin it to the taskbar.

   <LeonieWatson> JF: A link element should be able to take on any ARIA attribute. Is that correct?

   <LeonieWatson> JS: Right.

   <JF> <link rel="apple-touch-icon" type="image/png"
   href="http://www.stanford.edu/dept/registrar/cgi-bin/askjane/images/jane.png" />

   <LeonieWatson> JF: Seems this would be an appropriate use case for ARIA label?

   <LeonieWatson> JF: The Apple touch icon is essentially the same as a favicon.

   <LeonieWatson> KF: Most websites use their logo as a favicon.

   <LeonieWatson> JF: Usually a png or similar.

   <LeonieWatson> JF: If i have a number of shortcut icons on my desktop, there is no way to tell what the icon looks
   like, only that it's there.

   <LeonieWatson> KF: Correct. This isn't just about shortcuts though, it's about the browser as well.

   <LeonieWatson> JF: I'm just trying to dig down into current behaviours. How do you know when you keypress on an icon
   it'll behave like a link?

   <LeonieWatson> KF: They'll have roles and labels.

   <LeonieWatson> JF: So a favicon dragged to a desktop would have a role of?

   <Joshue108> Will some kind of programattically determined label not suffice for this?

   <LeonieWatson> JS: On my desktop I'm seeing things like "Apache" "Binary". Guessing those define the shortcuts.

   <LeonieWatson> JF: Those sounds like labels.

   <JF> I agree Josh

   <Joshue108> JOC:I never thought favicons had much use beyond visual eye candy.

   <LeonieWatson> KF: Let's say you go five pages deep on CNN. Now that page title might be lengthy, but the favicon would
   still be CNN.

   <LeonieWatson> KF: At present the UA has no way to know what label to assign.

   <LeonieWatson> JF: Right. That's where I think ARIA label would solve the problem?

   <LeonieWatson> JS: We're not handling this at all at the moment. We need to.

   <Joshue108> +1 to JF, if aria-label is sufficient.

   <LeonieWatson> KF: We should work with the UA vendors. Explain we want to pay attention to this. Maybe ARIA label is
   the appropriate solution.

   <LeonieWatson> JF: ARIA label is a global state property, applicable to all host language elements. From the ARIA spec.

   <LeonieWatson> KF: I can raise this internally and see what response there is to ARIA label.

   <LeonieWatson> JF: The purpose of ARIA label is to provide the user with a description of the object. From the ARIA
   spec.

   <LeonieWatson> JF: Seems to me you're right, we need to get this captured. We should let the WCAG WG know.

   <LeonieWatson> JS: I think we need an HTML bug as well.

   <JF> http://www.w3.org/TR/wai-aria/states_and_properties#aria-label

   <LeonieWatson> KF: Let me go back internally on this and report back first.

   <LeonieWatson> JS: I'm suggesting an HTML bug is because we've created a specific mapping. ARIA is not incorporated in
   the HTML5 spec.

   <LeonieWatson> JF: There is an authors guide that's HTML5 + ARIA.

   <LeonieWatson> JS: Yes, and this should be referenced in there.

   <Joshue108> Is ARIA not mostly incorporated into HTML5 now?

   <janina> scribe: janina

   leonie, Wants to support that we need a solution here.

   <scribe> scribe: leonie

   <LeonieWatson> JS: We should touch on this during the PF face to face as well.

longdesc: progress on JS-response to Matt's updated proposal?

   <LeonieWatson> JS: It's in my court. Has there been any discussion since your post John?

   <LeonieWatson> JS: I'm almost done with my response. I don't want to just post it, before other people have had an
   opportunity to review it.

   <LeonieWatson> JF: Not sure what else we can do after that, except let the chairs know we're ready to move forward. We
   may be able to hold off until next week and let the chairs know then perhaps.

meta name=generator: updates?
+<http://www.w3.org/html/wg/wiki/ChangeProposal/meta_name%3Dgenerator_does_not_make_missing_alt_conforming>

   <LeonieWatson> JS: I've spoken with Steve Faulkner, but the latest update is that he's swamped clearing his desk before
   TPAC next week.

   <LeonieWatson> JS: We have a couple of things stacked up, and I think TPAC will be useful to help with some of those.

table summary: expanded use cases? <http://www.w3.org/html/wg/wiki/ChangeProposals/ReinstateTableSummary>

   <kford> no objections./me I'll send a link to the mailing list. Not finding the exact link just yet.

   <LeonieWatson> JS: I haven't done anything on this I'm afraid. Lynne Holdsworth has helped with use cases. My action
   was to compare the response to the original objection.

   <Joshue108> JOC: I'm happy for any use cases that Lynn wants to add to the CP

   <JF> new @summary bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=14107

   <LeonieWatson> JS: I'm interested in people's thoughts on table summary.

   <Joshue108> JOC: Yes, its an interesting bug, that @summary being non-conforming will un-validate existing conformant
   WCAG content.

   <LeonieWatson> LW: I find it useful in some circumstances, when it describes the visual characteristics of the table.

   <LeonieWatson> JF: It isn't a perfect solution, but worth putting time into.

   <Joshue108> JOC: I've said all I have to on the issue.

   <LeonieWatson> JS: I wonder about other solutions?

   <LeonieWatson> JS: Could longdesc work perhaps?

   <LeonieWatson> JF: It could do possibly.

   <Joshue108> JOC: What would work about longdesc is its ability to reference an offpage URI.

   <Joshue108> JOC: Same as whats good about longdesc vs aria-desc

   <LeonieWatson> JS: It's worth us looking at the possibility.

   <LeonieWatson> JF: We'd need to look at longdesc and our thoughts on it.

   <LeonieWatson> LW: Longdesc would also mean people other than AT users could have access to the information.

   <LeonieWatson> JF: Is it worth getting together with some of the browser guys at TPAC and talking this through?

   <LeonieWatson> JS: Would longdesc meet the table summary use case?

   <LeonieWatson> JOC: Longdesc hooks up to a URI.

   <JF> s/ JS: Would longdesc meet the table summary use case?/

   <LeonieWatson> JS: We're going to be kicking around some ARIA ideas at TPAC that might be helpful here.

   <LeonieWatson> JF: ARIA is target at the accessibility APIs. That still leaves a gap concerning people with cognitive
   disabilities, for example.

   <LeonieWatson> JS: We'd still need something in the HTML5 spec.

   <LeonieWatson> JF: We already have details and summary in the HTML5 spec. They're visually present on the page.

   <LeonieWatson> JF: In some instances those elements don't solve the problem at hand. We might be able to solve that
   with ARIA, but that wouldn't present a solution available to non AT users.

   <LeonieWatson> JOC: To be futureproof we should try to reduce semantics, and have less dependence on solutions that
   rely on accessibility APIs.

   <LeonieWatson> JF: ARIA was only intended as an interim solution.

   <LeonieWatson> JS: No, that's not right. That's not how we see it in the ARIA camp.

   <LeonieWatson> JOC: Is it fair to say ARIA is a full citizen for markup language, today and tomorrow?

   <LeonieWatson> JS: Yes.

   <JF> http://lists.w3.org/Archives/Public/public-html/2007Jul/0903.html

   <LeonieWatson> JS: I'll finish my response to Matt regarding longdesc. After that I'll be able to look at your table
   summary response Joshu.

   <LeonieWatson> JF: Email with reference to ARIA as an interim thing is pasted above.

   <LeonieWatson> JS: I think you can interpret Al's comments in different ways.

   <LeonieWatson> LW: The trouble is that many people do believe ARIA to be an interim solution. The message has been
   interpreted that way by a large number.

generated content: progress on discussions? <http://www.w3.org/Bugs/Public/show_bug.cgi?id=13668>

   Steve will finish incorporating our comments by TPAC

resuming work on document location for alt guidance Definition of "accessibility" (WG 6)

   Michael Cooper will take this up following TPAC

generated content: progress on discussions? <http://www.w3.org/Bugs/Public/show_bug.cgi?id=13668>

   Correction. Yours truly's last comment was about something else.

   This topic most recently discussed at the Thursday TF call on 20 October:
   http://lists.w3.org/Archives/Public/public-html-a11y/2011Oct/0100.html

   No further discussion to date, perhaps at TPAC?

Summary of Action Items

   [End of minutes]
     __________________________________________________________________________________________________________________

Scribes: Léonie Watson, janina, leonie


-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)
Received on Tuesday, 25 October 2011 18:20:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:47 GMT