<janina> We can, can you call again?
tzviya: help the publishing community navigate the objection and improve the situation
we work closely with the orgs that have objected and would like to navigate this peacefully
<janina> Rich, there's pstn dialin: 1 617 324 0000; 641 181 126#
ivan: the publishing industry is interested in something that works. <details> is probably sufficient to serve the purposes the describedat supports
michael: my concern is that details is not really made for this, and it overloads details
ivan: details is in html 5.1, not 5.0
<ivan> The first summary element child of the element, if any, represents the summary or legend of the details. If there is no child summary element, the user agent should provide its own legend (e.g. "Details").
<ivan> The rest of the element's contents represents the additional information or controls.
michael: it's technically valid, but it's too generic and requires a system to look for the part/specific element that is an image description
markus: it is also not invisible, so publisher has to hide it. IF we put a role on details to specify that this is an image desc, it would take us a step closer to clarifying that this is an image description
<ivan> The open content attribute is a boolean attribute. If present, it indicates that both the summary and the additional information is to be shown to the user. If the attribute is absent, only the summary is to be shown.
maichael: this is default hiding, so exposing would be a little complicated
<MichaelC> AAPI guidance on details
ivan: UA should allow user to request access to details
... <details> did not make it into html5, so it is still open to change
michael: still agree that details/summary may not be sufficient and may be overloaded
tzviya: what is purpose of meeting next week?
janina: we need publishers to support the requirements. Whether this is describedat or another mechanism can be left to spec writers
ivan: yes, we want to acheive this. I am not in a position to choose between any of these elements because i do not have the experience
rich: do you just want a mechanism and require additional semantics?
markus: I am not the best person to turn to. There are people who have more experience than I do.
... We are recognizing that annotations is a better solution becuase the pointing direction is reversed,
ivan: we need 6-7 months for functional spec, 1 - 1.5 years for implementation
<Zakim> MichaelC, you wanted to say we need to identify that the requirements are complete and agreed to; and second how the various approaches meet, or don´t, the requirements - the
Michael: we need to make sure that reqs are complete and see what is missing from documented use cases
... and see if we are happy with cobbled solution of longdesc here and details there
janina: what about web components?
ivan: i think that web components is even further away than anno. It would enable any element within the component.
... Relies heavily on JS, so we need to be cautious for a11y
tzviya: DPUB to re-assess note provided and include describedat examples and explain why it needs to be longdesc
so, at the meeting next week, publishing will be endorsing requirements, not necessarily a specific element
janina: it would be helpful to have a table of requirements vs. elements
michael: it might be useful for a11y to create the heads and DPUB to create the rows as an output for the meeting
tzviya: will follow up on list about role with abstract superclass
... reminder that we need to discuss role="math" in ARIA
rich: will we add new roles to draft?
markus: we do have a few roles to add
... we also have roles on links and their future. Should we explore role or rel?