See also: IRC log
https://mit.webex.com/mit/j.php?MTID=m6e3f82ceee1b44268fd496d928c40001
<scribe> scribenick: Tzviya
JF: any news items?
RS: On tech AB for Samsung US.
They are shifting to all EPUB
... for internal documentation
LW: Web Platforms WG announced that copy of HTML 5 spec is available in GitHub. All are invited to fix bugs, add issues, comments
<LJWatson> HTML plan http://lists.w3.org/Archives/Public/public-html/2016Jan/0008.html
LW: in advance of next iteration
of next iteration of HTML5
... Also looking for editors
MG: In ongoing EPUB 3.1 revision,
we have encapsulated transition of @role. Within one year, we
will have outlined transitioned to @role.
... This means that we have to have a method to capture all
things that are currently in EPUB using @role
... One area that is still a little unclear is the matter of
links.
... Several options were put forward. Link natures in ebooks
are twofold.
... One is inline, to trigger behavior. For example link to a
footnote might trigger a pop up functionality, and this will
also trigger certain behavior footnote
... It is also important for a user to know what is at the
other end of a link before activating a link.
... The other use case is for global navigation. An EPUB is
made up of multiple documents bound together, and the user
needs to be able to navigate to the components
... One of the things that we have in EPUB is what is
unfortunately called landmarks, a list of "hotspots" in a book,
example where a book starts, the index, the glossary.
... These are not a set pre-defined terms, but author defined
hot spots
... In DPUB-ARIA we have *ref to point to particular elements
(e.g. noteref)
... We are looking for one stable mechanism. It could be @rel.
It could be a new attribute. We are neutral, but we want to
stick with it once we have it.
LW: What is the visual equivalent of knowing where the link goes? What are providing to AT?
MG: There is not always an equivalent. Sometimes it's a popup. It may have to do with the horrific experience of using the back button for a non-sighted reader. We should not ignore if it's just an enhancement for AT
TS: As a reader, I use the tool tip that is supplied
MattG: Often the links are styled in different ways. This gets lost to AT
Rich: are you considering using @rel for other things? e.g. DC metadata?
MarkusG: We do have one other use case - using SMIL
RS: @rel is not currently mapped
to AT
... and it is not in SVG
It is not a small undertaking to expose this to AT.
MG: This is our problem with *ref. We don't see how this will scale. In extreme case, we will end up duplicating our work.
RS: This is almost like a
sub-roles.
... We could have role descriptions, which can be any string.
Nothing will prevent people from colliding with them.
MG: Pretty compelling reasons not to use @rel, but what are the alternatives
RS: We can add attributes to the
DPUB-ARIA spec
... some people are concerned about scope creep for ARIA
1.1
IH: That would mean having a solution that is DPUB-specific
<fesch> s /creep/creep/
IH: This problem seems fairly
general. @rel has all kinds of problem, but it would provide
many solutions
... If we do something DPUB specific, it is not tragic, but it
seems to put the issue in a corner
RS: I will post the issue to the
list and see how people respond
... All EPUB readers are web-based, so this doesn't really
restrict to DPUB
LW: Is Rich suggesting looking at subroles or a new attribute?
RS: I think subroles was pushed to ARIA 2 because of ramifications
<mgylling> Rich’s email to dpub-aria re @rel: https://lists.w3.org/Archives/Public/public-dpub-aria/2016Jan/0003.html
RS: The value of the subrole is that we still know it's a link, which is important
<Zakim> LJWatson, you wanted to ask whether we're proposing a sub-role or another new attribute?
rs: We could definitely do a link
sub-role
... UI Automation does not have a concept of sub-role, but it
does have object attributes
LW: Is there more of a challenge introducing new attribute or connecting @rel to APIs?
RS: @rel is harder because there
are all the other taxonomies
... we can add sub-role but limit scope for 1.1
... what is timeframe for HTML 5?
LW: no official time line
<Zakim> joanie, you wanted to say if the new attribute is a link type, I can make a case for it being more general
JD: sub-roles are awesome
... there will likely be from objections from some people
... the link type attribute might be easier to swallow
... link type is already a thing. There are samepage, mailto,
etc links
... The use case exists already
CS: sub-roles is a non-starter
for us
... We have been thinking of doing a hyperlink pattern
... a hyperlink pattern could have a link type
... The ARIA property is there for UIA, but I would rather
add
RS: I'm not a big fan of
sub-roles
... We could introduce link type attributes in DPUB with
assigned values
... When ARIA 2.0 comes out, we could move it from DPUB to
2.0
... I recommend against prefixing
... Keep it lightweight
JF: Don't we want to keep it lightweight anyway? We want to make sure that this works before rolling this out all over
RS: Cynthia, would you support putting this in 1.1?
CS: if it's really limited and it will shift to a pattern in 2.0, maybe (need to see samples)
JF: We will have a discussion
with the ARIA WG and update HTML TF
... @rel is not something to address at this point
<Zakim> joanie, you wanted to volunteer to draft something non-dpuby for the group to review as a general feature
JD: I am willing to draft out core ARIA for link types
RS: Willing to take on proposal
TS: Reach out to me for DPUB perspective
JD: I'm envisioning writing up something that is not DPUB-specific, and DPUB adds some additional types
MG: That sounds ideal for us
ACTION joanie write link type proposal for ARIA 1.1
<trackbot> Created ACTION-2004 - Write link type proposal for aria 1.1 [on Joanmarie Diggs - due 2016-01-27].
FE: if there is a link type for someplace that seemed safe, and it takes the user to someplace dangerous, isn't it a security concern?
JS: We do have to trust the security of the provider to some extent
IH: Doesn't the answer to
security question depend on the specific values of the
attribute?
... I don't see a security issue arising if the value is
footnote. If we had something like interactive-widget, we would
need to be more careful.
FE: If someone put the footnote type, but it leads to a dangerous website. Isn't this a security issue?
TS: How is this different from the link to the footnote without the link type?
JS: There is always an abuse
vector, and people have to assess what they trust
... We do not need to meet with HTML TF tomorrow
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/no code// Succeeded: s/for webex// Succeeded: s/creap/creep/ Found ScribeNick: Tzviya Inferring Scribes: Tzviya Present: janina Tzviya LJWatson fesch mgylling Joanmarie_Diggs MichaelC Regrets: MichielBijl WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 20 Jan 2016 Guessing minutes URL: http://www.w3.org/2016/01/20-apa-minutes.html People with action items:[End of scribe.perl diagnostic output]