Accessible Platform Architectures Working Group Teleconference

20 Jan 2016

See also: IRC log


janina, Tzviya, LJWatson, fesch, mgylling, Joanmarie_Diggs, MichaelC


preview agenda with items from two minutes


<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

To rel, or not to rel -- Discussion with ARIA-Dpub TF

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

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/01/20 18:01:57 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]