See also: IRC log
<trackbot> Date: 28 August 2014
<janina> Meeting: HTML-A11Y Task Force Teleconference
<janina> I hear you
<janina> Yes, I'm speaking
I had almost zero volume :(
<janina> I wasn't sure whether it was you or me. Zakim only responds on IPv4
<janina> I hear you, do you hear me?
<janina> It might be me
<janina> IPv4 only on Zakim means NAT for me, and that can be a problem.
<plh> zaop, drop plh
scribenick chaals
JS: What do we do with teh Formal objection, what do we do with the implementor experience, [scribe missed something]
… Formal Objection, Haven't seen any TF participation in that conversation.
… Do we need to engage in a direct response, if so, how?
… Or should we just go forward and let the Director deal with the objection
CMN: I think, personally, that the objeciton is nonsense, and that it would be useful to write up an explanation of why. Whether we seek consensus from the TF/HTML on a refutation, or simply pass it to the director, I don't have a strong opinion.
Liam: Having an objection demonstrates we don't have formal consensus, but when the thing goes forward we will have to have an explanation of why the director doesn't uphold the objection, if that is what happens.
JS: I would rather not get into the same debate we have been in and have another round of it. I don't think the objection is sound, but don't want to characterise it strongly. Someone - either apple, or those who think they are wrong, is going to be upset by the outcome of a director's decision.
… I also think we have achieved consensus, without having unanimity. It seems the process lets us say "Yes, we have consensus". I am not sure of the value of jumping into a response on-list.
… I think we should try to reach out and see if there is anything we can do get resolution other than the director deciding.
<Zakim> liam, you wanted to say I think we should just move forward and to note that Joannie's comments do need resolution, although I don't believe normative changes are needed
<Zakim> ShaneM, you wanted to ask about the process of resolving a FO
JB: My initial reaction to the objection was to try and write a clear response.
… I am not clear that responding to everything on list would be productive; and we have the opportunity to ask them a few questions. One interesting issue from my POV was their significant misunderstanding on epub; LD would not be damaging to epub, it is necessary..
scribe: there seem to be some misunderstandings in the Formal Objection of approaches to @@@
SM: My question is: if we don't respond (and I agree we shouldn't), and it goes to the director, what happens next?
PLH: It's pretty straightforward, the director looks at the objection and decides what to do - agree with it, disagree with it, or look for something in the middle.
… So we can go to PR, and the director will have to decide.
SM: There is nothing new in there
PC: I thikn that's subjective.
JS: I think the qustion "does anyone se anything new" is an important question to how we deal with it.
PLH: I think it is great that Apple agreed to put the formal issue on the record, it's better to have it than having them stay silent.
<Zakim> chaals, you wanted to say I don't think an ongoing debate will be productive - we should have a director's decision
… The director will take the objection seriously and look into it. We are interested in as much information as we can get.
Chaals said what he wanted to say there…
PC: As someone who had to attend the decision meeting, who will walk the director through the arguments that are in the objection?
… Do they have the data to present the objection?
JB: I outlined their FO as soon as received, no new info, but some notable misunderstandings for instance LD & epub; Paul we would be prepared with a detailed walk-through of data for dir's review; in the meantime though hope to ask a few questions.
<janina> Liam, can you backup Charles?
… I would be one of the people at the meeting. I believe Janina would be available, don't know if Chaals will.
<janina> Liam, that's the next subtopic
… We want to ask Apple clarifying questions.
<janina> OK
<liam> janina: agreement here, we need to organize our presentation to the director but not get back on list
JS: Seems we need to present information to the director but it isn't useful to start another on-list discussion.
… Are people happy for the coordinators to take on the preparatory work.
JS: We will talk to Apple, and move forward.
… Apple ahs done a favour to the community making sure this gets high-level attention. So this is probably a good thing to ensure there really is detailed review.
JS: I think all the suggestions she made, I see one that would benefit from clarifying language in the spec. My thought was this may be a normative change.
… I believe that I had misunderstood the nature of the changes required, and they are editorial clarifications not normative changes.
PLH: In terms of CR changes, if you make substantive changes you have to go back to Last Call. So the Director will look at whether the changes actually affect confromance of implementations out there, where is the change, …
… Is this new information, or just a clarification? If you introduce new things, you would have to go back to last call, not just for potential new comments but also for a new call for exclusion on IPR.
… If all the changes are clarification and don't affect implementations etc we can argue that there is no reason to return to Last Call.
<Zakim> ShaneM, you wanted to ask if this change could be done as part of *instant* errata instead of going back to last call
JS: The item in quesiton is 3.0.3, second provision. Currently says User Agents MUST *expose* the link to Accessibility APIs.
… the question is what does "expose" mean here? And it turns out that browsers do different things here, because clients need different info (string vs action, roughly).
… So expose should mean "you need to give the API the right information to work with that API.
… We know that these things are different. Is this a clarfication or a substantive change?
SM: Can we do this as an erratum?
<Zakim> liam, you wanted to note that Joannie's comments do need resolution, although I don't believe normative changes are needed, it's a clarification by renaming something
<liam> liam: we need a "yes" from Joannie; a clarification in terms of what's exposed to the API would I think suffice
<liam> [liam, paul, both note it's not desirable to publish with an erratum]
LQ: I think the answer to Shane is no.
… we want to publish specs with issues resolved, not produce errata. But I think this is a clarification, not a normative change. Implementors in IE anf Firefox won't need to change, it doesn'taffect the way people are using this now.
… I would be happy to argue that it isn't a substantive change. It might be useful to have an informative note that platforms work differently and "expose" needs to be done appropriately for each platform.
CMN: What Liam said.
[I don't want to do this as an erratum either, BTW]
PC: I don't think it makes sense to publish an erratum on something that hasn't even gone to PR yet.
… You should file bugs when you find them
JB: What Joanie did was exactly waht CR is for. She did an independent implementation from the spec, and reported what she found out.
… I think it is useful to address this directly in the spec. Te question to consider is whether this is substantive - i.e. does it change what other implementers would have done in their implementations, or is it just a clarifcation. My sense is the latter - we shouldmake the editorial change, check it makes sense to Joanie, and can move forward.
… So we should get agreement to proceed in that way.
JS: I think it is useful to note for the record that NVDA implemented recently, it's a windows screen reader that implemented on top of Firefox and IE, and had to use two different APIs to get the data - DOM and IA2.
… Because they had to handle both situations it is appropriate. I asked them and they said the clarification would be useful.
JB: My understanding is the change may be normative but is not substantive.
CMN: My understanding is that this implementation was completely independent, done in days at most, and was completely correct.
JB: Yes. It was black box -- she not been following the spec. She said it just took a few hours, easy.
JS: Sounds that the change is not
substantive. We should make the proposed clarification, and put
it in the CfC.
... There are other comments in the feedback, that have been
discussed on list, and I think the sense is that we aren't
going to make more changes
… are there any suggestions that we need to make other changes based on her feeedback?
JS: She is very concerned with the user experience when the descripiton is a fragment of another page. There is no way to ensure that the reader doesn't read beyond the end of a fragment….
… not sure to what degree this is a problem for other implementations. Should we say more about what we should do here?
… I asked for clarifying comments and didn't get any, but want to check.
<Zakim> ShaneM, you wanted to talk about extracting a 'fragment'
CMN: THink there might be value in an informative note, but not a requirement. THis is a problem for all linking, not just longdesc
SM: This isn't unique to longdesc, and people using longdesc are aware of it. If you wanted to handle fragments correctly, coudn't you just use the DOM?
JS: The problem is whether there is access to that DOM in linux?
CMN: Because there is a legacy, and HTML isn't historically "contained" in the way XML documents are, trying to enforce the enclosure and then rely on user agents to pick that out will actually cause problems if done too strictly.
LQ: What chaals said.
JS: So it sounds like we need to look at the spec, propose text for editorial changes.
JB: Would be a good idea to propose the text on list first.
JS: The proposed changes would be on list, so the entire TF can look at it.
… Does anyone disagree that this is how we should proceed? Can we start a CfC with a new spec, based on having the text accepted informally, or do we need a formal Call for Consensus on changes before we put up an editied document?
JS: Then let's make that the plan.
… and do it...
… Hopefully we can start a CfC early next week
JS: If we continue sequential CfCs we will fall behind schedule. Do we want to consider requesting parallel CfCs in the TF and WGs?
CMN: It's tricky to ask the HTML WG a question when we aren't clear that we have consensus on it. But when we have a reasonable expectation of consensus, it seems reasonable to expedite process work.
JB: just confirming that there were not objections to doing a CfC to PR; I heard none
JS: It seems that we are ready to go to CfC, when we have the documents ready.