<JF> scribe: JF

Agenda review; identify scribe.

JB: reviewing agenda
... noting the low turn-out, may not make sense to discuss in depth
... question on how/if we continue to use text sub-team and related calls

Longdesc & longer description mechanisms, possible emerging consensus in discussion?

JB: looks like longdesc thread indicating some progress being made over the weekend
... may be worth bringing people's attentio to that

appears that some progress happening over multiple postings and threads

JB: how far has the conversation gone beyond what Chaals has offered?

<Judy> JF: very little, though progress still being made in discussions

<Judy> JS: summarize?

<Judy> JF: his proposal states that longdesc must be exposed to accessibility APIs, and that it should also have user interface mechanisms for the end-user, without being overly prescriptive for the end-user

<Judy> scribe: Judy

JS: so the existing LD mechanism isn't API-based...

JF: not exactly true. In Firefox, it is being exposed to the user
... AFAIK, wrt supporting screen readers, there are only 2 SRs providing standalone access

JS: so Charles thinking that it would be relatively easy to expose these through AAPIs?

JF: seems to be his (prior-hat) implementer experience
... [looking at his draft]

JB: notes that his draft is available from this message http://lists.w3.org/Archives/Public/public-html-a11y/2012Sep/0478.html

<JF> JF: Chaals has presented a draft Spec Extension which is working its way to the CVS

JF: reading from draft spec

<scribe> scribe: John

<JF> scribe: JF

JB: understand that it isn't necessarily a compromise version yet

doesn't yet, then? fully address all concerns

<Judy> scribe: Judy

JF: seems that one of the primary goals is to specify what is on the ground today, so that there is better support for the conformance requirement, e.g. a conformable attribute
... might be moving forward into other forms (lists questions relating to co-existence of, or evolution into, newer solution
... and David Bolter is suggesting that longer description mechanism should stick closer to longer description mechanism model

<JF> scribe: JF

JB: wondering if we can extract open questions for discussion, perhaps on Thursday's call, or on-list??

<Judy> ...ARIA provides more fluidity to remap the intent, though others may feel it should be more prescriptive

<Judy> JB: can we summarize the current concerns about this approach?

<JF_> from Chaals' draft:

<JF_> The longdesc attribute must contain a valid URL potentially surrounded by spaces. The URL is a hyperlink to a description of the image that its parent img element represents.

<JF_> Authoring requirement: the link is to part of a document, the description should be contained within an element which is the target of the link.

<JF_> User agents should make the link available to users, and should expose the link to relevant APIs, especially accessibility-oriented APIs.

<JF_> User agents should allow users to determine when images in a page contain a long description.

<JF_> If a longdesc attribute has invalid content, user agents may make that content available to the user, since a common error is to include the text of a description instead of a URL as the value of the attribute.

<Judy> scribe: Judy

JF: one concern seems to be the problem of potential pollution of content.
... another seems to be the concern about potentially requiring the browsers to implement a visual indicator -- but I am not sure on this.
... would be helpful to have confirmation or clarification.
... and there seems to be different perspectives about who longer descriptions are for
... for instance, whether they are mainly for screen reader users, or other users as well

JB: doesn't the tf-supported issue 30 cp requirements say that it is for more than screen readers users?

JC: also a matter of time and priority, not sure how necessary the longer description functionality is, there are other priorities such as MathML, accessible SVG, canvas, etc.

JF: think that most people agree that we can do better on authoring conformance
... but that the concern is that something is needed for users now, and that even where not supported by browsers, the functionality can be available via assistive technologies and plug-ins

<jcraig> JC: more important to spend development time on future technologies, because that is where the Web is going, and we need to make it so that the new types of content can be made accessible.

JF: hence the focus on removing sticky point of conformance

<JF> +1 to Jame's point - Chaals' draft appears to be a good compromise.

JC: the current compromise about using extension spec might indeed help address the conformance concerns -- e.g. allow different things to exist
... but allow of these things are gathering partial support
... and in CR, they will need implementation support
... if in CR, LD is deprecated or obsoleted, then...

<jcraig> JC: The extension spec idea is a good compromise. I have not seen Chaals' draft yet.

<JF> to clarify, I +1 to using the extension mechanism, which james appears to support as well

<JF> scribe: JF

JB: James mentioned a concern over resource allocation vis-a-vis where does implementation effort get spent. Spending time on things that may beco e obsolete takes time from working on future-forward efforts

<Judy> JB: interested in zeroing in on questions

JB: not sure if that is a major concern from those seeking conformance of LD

if others are willing to do the necessary implementations, does the resource allocation question remain a concern?

JC: this is not just an Apple resource allocation concern, could also apply to Microsoft or Mozilla, etc. Any time spent working on older tech, takes time away from newer implementation

JB: Maciej's permissive Exit CR, and the vertical stack concept that relies on down-stream/vertical support

wondering what the right framing of the question might be to help the dialog and sort the questions and clarification of concerns, e.g., what if, given the proposed permissive CR exit criteria, additional browser implementations wouldn't be needed? e.g., implementations could rely on support elsewhere in the vertical stack

JC: regarding Exit CR, both John and Chaals have looked at that. It appears that WebKit implementation would not be needed for Exit CR

JB: appreciate the resource concerns that have surfaced, and wondering if that concern is unnecessary based on the Exit Criteria

<Judy> scribe: Judy

JF: I'm very interested in better understanding this question of exit criteria
... think that some progress towards compromise on the interim draft may be visible
... but that given the exit criteria, and resourcing discussion, so far, maybe the concerns against an interim approach would go away?

JC: need to read the draft, but understand the intent, and that might be possible

<JF> scribe: JF

JB: as we appraoch top of the hour, there is one other admin item that want to surface

2 items from last weeks text minutes

it appears that the draft and final summaries that were read out in the meeting and pasted into the irc, got truncated in irc log and html min; server glitch when correcting.

there was a glitch however with the server, so that needs to be addressed

(regarding support of the CFC)

Judy wishes to adjust the minutes with an explanatory note and to also reflect a "late" response from Cyns w.r.t. Microsoft response (likely not complete the edit till tonight due to meetings)

no objection from JF

JB: given that everyone must leave the call, looking to adjourn at this point