PFWG HTML Issues Caucus -- 30 Jan 2009

<janina> muted? the d@@m phone never rang!

<oedipus> trackbot, status?

<janina> OK, I'll call in. I want to talk with ya'all!

HTML WG Call 2009-01-29

<inserted> ScribeNick: oedipus

JOC: debate over spec: what wg draft versus markup language draft -- seems that publishing a good idea by and large -- will give us a touchpoint for futher work with HTML WG; should be PWD within a month

<inserted> ScribeNick: Joshue

GJR: The big news was that GJR be restored to the issue tracker.

<inserted> ScribeNick: oedipus

GJR: sam ruby asked that i be restored to the issues team; and suggested that i log my D element suggestion as an issue
... other thing is debate over WHAT WG draft and MikeSmith's experimental draft which is simply the markup language

<inserted> scribenick: Joshue

JOC: I also think the markup draft is a good idea.

GJR: I am in favour of it being published in a normative recommendation track.
... That is Mike S's doc 'HTML: The Markup Language'.
... What not publish the declarative part and then other docs relating to the APIs and events etc.
... It come down to do we publish the inherited docs from the WHAGWG, or do we keep the markup version of the doc alive?
... A new declarative doc would give us all a common basis to work off.
... This would give a good overview of the bare bones markup language.

@alt proposal

<inserted> ScribeNick: oedipus

JS: history - only 3 of us at wai-cg call wednesday afternoon
... me, Jan Richards, Loretta G-R -- asked me ideas about moving forward, wanted to hear from them
... hashed their perspective of issues in informal conversation via phone

<Joshue> +q to ask if it was the case in HTML 4 that earlier markup languages actually needed the alt just to parse the doc correctly?

JS: case for leaving @alt mandatory for validation is probably ok, but shaky -- HTML4 grok showed mandatory elements have to be there for parser to work (can't make case that essential for tech to work); important for accessibility; validity doesn't prove accessibility, so what is function of @alt -- a nudge to authoring community -- you need to know what this is, how to use it, and to deploy it; if fail validation because of missing alt, and accessibility gain
... authoring tool view: what about the author who doesn't give a damn and who dismisss all popups that ask for alt values; what should the resultant markup be when author refuses to provide @alt values

<Joshue> JOC: Will the parsing of HTML 5 be dependent on alt being present?

JS: one suggestion: have @alt and caption to associate with ARIA -- either or or -- one of 3 has to be there: @alt, @noalt (author didn't do anything, error correection kicks in), ARIA binding to associate text elsewhere on page -- if one of those 3 is not there, fails validation
... will be discussed on wednesday -

<Zakim> Joshue, you wanted to ask if it was the case in HTML 4 that earlier markup languages actually needed the alt just to parse the doc correctly?

JOC: really interesting point about parsing of HTML4; is that case in HTML5?

JS: for document to be correctly parsed every attribute but alt is parsed; @alt is an isolated case

JOC: interesting
... noalt idea has value if conditions met: if useful for the user to know there has been no alt assigned; UA hueristics could repair, but have to work out what nature of repair should be
... even alt value "photo" better than nothing; need consensus on noalt -- i think ok
... if that layer is not necessary using null alt value; user experience when @noalt is used that is the question

<Joshue> JOC: The nature of the handling of <no alt> has to be worked out.

JS: my understanding is that there would trigger some special handling by UA -- signal to UA as to how it came to be in markup
... either or between @alt and aria-labelledby -- ok alternatives; what guidance do we give and how is noalt expressed

GJR: as a WG our stance is native accessibility over accessibilty overlays; so we need to attack problem so it can be fixed using tools provided by the markup language, rather than give authors an easy out by letting other accessmonkey their pages with ARIA
... use of both in the end is necessary as far as i can tell

JS: still on fence regarding third option - aria-based markup

GJR: no, i applaud the use of ARIA and acknowledge it is more fine grained that what is currently available, but i perceive that as a spur to engineering a superior terse descriptor native to HTML

<inserted> ScribeNick: Joshue

GJR: HTML is supposed to be the lingua franca of the web.
... Therefore native accessibility is the desired solution.
... ARIA etc can be used for repair and error handling.
... Focusing ARIA on the widgets that HTML cannot provide.

<inserted> ScribeNick: oedipus

JS: comfortable with ARIA-based markup
... understand hesitancy to open the door -- what don't know is how much aria will make it natively in HTML5

GJR: that is one of the things that jumped out at me about the markup language version of the spec -- there are common core attribute sets, and one of them is for ARIA

<inserted> ScribeNick: Joshue

GJR: It was clearer in the markup language of the spec that came from the PWD that was submitted to W3C.
... One of the components was ARIA.

<oedipus> GJR: will include pointer in minutes announcement

<oedipus> JS: ok

GJR: One of the concerns that I have in HTML swallowing ARIA, is the people doing the incorporation are not savvy about some of the subtleties of ARIA.
... We need to make sure that we do this correctly, inheritance and so on.

JOC: I also would be concerned about this.

<inserted> ScribeNick: oedipus

JS: don't know if reason to say no - no direct objection GJR?

<inserted> ScribeNick: Joshue

JOC: the degree to which HTML 5 will support or incorporate ARIA is still up in the air.
... To some degree ARIA does today what HTML 5 only promises to do. There is a potentially a dissonance therefore.

<inserted> ScribeNick: oedipus

JS: expect any iteration of technology that there would be enhancements -- what kind of content support in version 1.0 -- elaborate on that set in future iteration; difficulties with backwards compat with LGR's plan, but would jump out at author to the benefit of all; natural and reasonable thing to expect; mechanism aria-labelledby not available in HTML4, but now available via ARIA, might be worth allowing that in -- expect support for ARIA will grow

<Joshue> JOC: Well in order to let the uptake for ARIA increase then maybe it is a good idea to let ARIA do some of the things that HTML would do?

<Joshue> +q

JS: seemed to me a future-looking that isn't in realm of science fiction

<inserted> ScribeNick: oedipus

JS: comfortable to @noalt because similar to future looking approach for error handling

<inserted> ScribeNick: Joshue

JOC: Using <no alt> could be a good foundation then.

GJR: I don't have a problem with <no alt>. I would be more comfortable if we could get the role att into img.
... If the role is layout, I can set my AT to skip that stuff.
... I proposed to the XHTML 2 that the for att be added to the core attributes collection..

<oedipus> to the core attributes collection

GJR: Its universally available basically.
... I want to use the for/id model that was pioneered for label.
... You could use the for att to point at the element that contains a bibliographic element. I wanted low level redundancy built in.
... This is another factor to consider.

JS: Yes, if?

GJR: Yes.
... Saying you can use ARIA and ignore the accessibility features basically.
... Considering the target data is 2012, I am being a little too cautious maybe.
... Use of either an alt value or aria-labelled by? yes or no.
... I want something native, both.

JS: You may be a minority.

GJR: I know.
... Many authors complain about the burden that HTML gives to them.

JS: Will an either/or not lessen the burden.
... The more complex is the greater. Both and is loading on not taking away.

GJR: I am saying the requirement is in HTML.

<oedipus> GJR: either or if aria-labelledby is bolted into HTML natively if aria properly wired in

JS: We have to make sure that it is properly wired in, put your ideas into the caveat.

<inserted> ScribeNick: oedipus

JOC: hit on a lot of stuff; really understand GJR's point about native accessibility in markup languages, but JS made good point of either or if aria incorporated into HTML so that it is native; makes sense to give aria higher profile and get authors and developers familiar with its proper usage
... JS hit nail on head;

GJR: no problem with forward thinking but still need to attend to backwards compatibility -- it's in the HTML4 charter

JS: summarize: ok with proposal, but devil in the details

<Joshue> JOC: Sounds like a plan.

JS: goal for wednesday -- agreement on principle and then have individuals address the devil in the details; would like to have agreement on basic principle

JOC: plus 1

GJR: plus 1

JS: will put out post that agreement on basic outline; details to be worked out; discuss on wednesday, then set task of setting out the details
... think we are on a good path

JOC: agree

ADJOURNED

trackbot this is WAI_PF(HTML)

- DRAFT -

PFWG HTML Issues Caucus

30 Jan 2009

Attendees

Contents

HTML WG Call 2009-01-29

@alt proposal

Summary of Action Items

Scribe.perl diagnostic output