<NickRuffilo> scribenick: NickRuffilo
<tzviya> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Dec/0061.html
<tzviya> http://www.w3.org/2015/11/30-dpub-minutes.html
Tzviya: "Comments on last week's minutes? None... Approved."
Tzviya: "Joseph does a lot of work for ARIA working group on the accessibility API."
Tzviya: "The roles in any of the ARIA document. It's a list of terms with ARIA 1.1. The DPUB we just point to ARIA for the items. We reference navigation which points to the ARIA role... What the API mappings do is say how the accessibility API mapping should utilize this. It functions as the layer between the HTML/SVG/etc and the user. So that's the broad overview of what happens here."
Joseph: "You said it's what interacts between HTML/SVG/user - it's there for the Assistive technologies. It acts as an intermediary between the document and the assistive technology."
<tzviya> http://www.smashingmagazine.com/2015/03/web-accessibility-with-accessibility-api/
Tzviya: "I have an article about how ARIA works. The posted
article explains that well. It has the accessibility object model and
where the markup language fits in, and where things that aren't ARIA fit
in. I recommend reading it."
...: "Any accessibility API mappings, they are fairly complicated
documents because there is not a specific API - Apple, Microsoft, Linux
-- ok Edge, MSAA, and Internet Explorer..."
<lrosenth> but remember that these are platform centric - not generalized
<dkaplan3> this is the best overview I've seen: https://www.marcozehe.de/2013/09/07/why-accessibility-apis-matter/
Deborah: "I posted a URL with a really good roundup of the accessibility APIs - and explains what the browsers and APIs do."
<tzviya> http://www.w3.org/TR/2015/WD-dpub-aam-1.0-20151203/
Tzviya: "Here's the link to the AAM. There's role-mapping at the bottom. If you take a look at the roles, there is a section that explains in detail what the API is supposed to do with each one of these roles."
<clown> http://www.w3.org/TR/2015/WD-dpub-aam-1.0-20151203/#mapping_role_table
Tzviya: "There has been quite a bit of work in the ARIA Github"
Ivan: "When I look at the cells in the table, I'm not sure what it is they say. Can you give a high-level overview of what's happening?"
Joseph: "Using doc-abstract as an example. If you're a
browser running on windows, and you're using i-accessable2, you take the
string doc-abstract and it'll be a role-system grouping in the
accessibility tree. We will also store xml:.abstract. It's a property of
the accessible object."
... "An accessible object is a tree-structure in the accessible API.
Similar to a DOM element, but not actually in the DOM. So it extracts
(subsets) the DOM and creates a new tree item. From there you will have
nodes in the new tree that has a role, a name, possibly a description,
and a whole bunch of states and attributes."
<dkaplan3> here's a good link for the accessibility tree: https://www.paciellogroup.com/blog/2015/01/the-browser-accessibility-tree/
Joseph: "So this note will have a grouping, xml:doc-abstract."
Ivan: "So this isn't microsoft specific?"
Joseph: "If you're using the MS-only apis then they are. There is ATK/ASPI - that's for linux. The last is for Mac OS X. "
Ivan: "So they have a different API with different items?"
Joseph: "If you're running Safari on a mac, then safari creates it's own DOM. It also creates it's own accessibility tree according to AXAPI. It doesn't create the others."
Leonard: "The thing you have to keep in mind about the APIs is that they aren't web-specific. They are on the OS level so that everything on the screen is accessible. The Accessibility DOM actually goes beyond the web itself. Only at the end of the tree is the document that you're looking at."
Joseph: "Adding to that - accessibility APIs were invented
way before the web. Browsers were initially just documents, and they fit
in to the word-processors api."
... "As web-development got more complex, there was a need to fit things
correctly, which is where ARIA comes in."
Leonard: "Going back to the content - this looks good - but what strikes me as odd, is why - for 2 of the 4 - the value is doc- and in the others you remove the doc-? Shouldn't it be consistent across APIs"
Joseph: "In the two cases that have XML roles : that's a string. The XMLroles: is not a namespace or a prefix, it's a name. In this case it's a name value pair."
Tzviya: "It's up to the API itself."
Ivan: "Leonard's question was not on the XML role it was the naming itself. We use the original term doc-aspect, but we later drop doc-..."
Joseph: "I'm not sure why they did it in the one API."
Tzviya: "It's a question for the people at apple..."
Joseph: "The description is a user-friendly string. Would you say doc-abstract or abstract?"
<lrosenth> it would much better if we could have it
consistent for all APIs
...: "The UIA one is a piece of data, not really a string. You could
actually view it as... So it's saying treat it like a control type
abstract."
Ivan: "So, we have here, a view of various types of windows, linux, and OSX. What about mobile?"
Joseph: "XPI is whats being using on IOS."
<danielweck> doc-biblioref => Control type/role is 'bibliography references' in UIA, so this looks like a human-readable string (or maybe it's an editing error in this spec. document?)
Ivan: "Android?"
Joseph: "I think it's using ATK... the linux one..."
Nick: If I understand it, ARIA creates tags and markup to make HTML doc happily inserted into whatever OS it needs
...so I need to care about correct ARIA tags, roles,etc. so that whatever OS can do what it needs to do
...is that correct?
Joseph: First approximation, yes
...authors should care about markup
Nick: Is object model mainly for people creating accessibility applications
...or is it expected that reading system creates its own accessibility
Joseph: Core is to tell browsers: this is what you are supposed to do with the markup and how you are supposed to expose it within the accessibility API
Ivan: And reading system in this respect is just a browser
Joseph: can also be used by screen reader vendors to see what is coming out of the browser
Nick: they are familiar that things are verklempt
... ok thanks
Bill: They are not using the original markup but how it has been interpreted into these API schemes
Joseph: That is what they are supposed to be doing
...some use the APIs but they also look at the DOM
...very confusing
Tzviya: Some of what it looks at is @
Joseph: Is an HTML AAM; how to map
...and one for SVG element
...to extent that the mapping is complete and accurate the AT should not have to look at the DOM
Charles: "Quick q: looking at doc-abstract... we have role-system grouping, but there is none in the acknowledgements. So there's nothing that maps this new role? So now the AT has to look at the new role pair?"
Joseph: "So the AT has to have a map to how to display something."
Tzviya: "There are no roles that do not have a super-class in ARIA 1.1 - a superclass means it's points to a parent. it's better to look at the DPUB roles document."
Ivan: "The table - shouldn't it include in the cell
whatever the superclass maps to?"
...: "Any implementation needs to look at both documents at the same
time?"
Tzviya: " If you look at the ATK roles, they are just strings. In acknowledgements for example, it will say: 'expose role landmark'."
Ivan: "I would expect something similar in the first line."
Ivan.: " It feels incomplete."
...: "It's something we have to see with Rich - as he's the one who
created these tables. Lets make sure these questions flow back to him."
Tzviya: " Great, and now we have a topic to discuss on the meeting on Thursday."
<tzviya> if you have comments, please post to https://github.com/w3c/aria/issues with flag "dpub"
Bill: "There are quite a few typos that should be addressed..."
Tzviya: "Additional comments/questions/suggestions..."
Doug: "I saw you were talking about SVG stuff. Do you have any questions?"
Tzviya: " We were talking about APIs in general - and just noted there is a mapping for SVG"
Doug: "Ok, thanks..."
Tzviya: "Tim followed up with me - which is wonderful. Tim got together with people about archiving."
Tim: "This came up in the call 2 weeks ago. we discussed
next steps for PWP whitepaper. The question of how to address archiving
of these types of structures and what's already being done about
archiving came up. Breif discussion came up. We discussed and here's a
brief summary from where we are."
...: "The whitepaper needs to be extended a bit in 3.7 which has
placeholder text - possibly 5.2, where it mentions archiving. We wanted
to mention Portico and CLOCKSS. It has lots of things that are being
archived using those systems. How do the things we wish to do with PWP
impact on that."
<tzviya> http://w3c.github.io/dpub-pwp/#package
<ivan> current section in the PWP
<dkaplan3> http://www.portico.org/digital-preservation/join-portico/for-libraries
<dkaplan3> http://www.clockss.org/clockss/Home
...: "There are efforts on premise in the library space. There's an ISO standard on article versioning. We need to formulate the questions and get answers. We also need to make sure the PWP document reflects though. There are broader questions: should we strategically engage the parts of the library community that is dealing with archiving. The special library association is dealing with this area - there are preservation coallitions. Do we need to worry about archiving in our testing and demonstrations? Bill/heather - do you have a little more definition on what you want to get done?"
...: "Do we need a taskforce? if so, how do we get more volunteers. And that's what we'd like a little more clarity on."
Leonard: "I'm happy to participate in this group. I'm the ISO project leader on PDF-A - the long-term standard for archiving PDF. What I don't hear is what is meant by archiving? Who's doing it? Longevity? The things we talk about - and what archivist talk about - is that there are w whole lot of properties and concerns. Can you talk more about the background/goals of archiving a PWP."
Tzviya: "I think that's part of the task force is to figure out the goals themselves - the group needs to get going befroe we can answer that."
Tim: "we don't want to re-invent what PDF-A has done. For example, there are CSS items that needs to be archived. If there are thousands of documents that use the same versioned CSS archive - do you save that in all documents, or just some."
Leonard: "You need to ask what the requirements are - not the implementation questions. I think Tzviya is right, and take up these questions in a meeting."
<lrosenth> ivan - depends entirely on what your requirements are, which is why I started there...
Ivan: "It would be interesting to know... You said libraries already archive large amounts of epubs. It would be interesting to find out if they have run into technical issues - missing information - from doing so. Even with epub 3.1 or PWP - what should be provided to making archiving easier. It's the question I always repeat - what is missing - from a technical point of view - and what is necessary - for PWP to make the job of archivers easier. If the answer is 'nothing really' then maybe we don't need to do more."
Tim: "The point is, is to take advantage of what is already being done. What are the implications of what we want to do. And how do we adapt?"
Ivan: "It so happens that in about a month I will have a meeting with the head of the numerical department of Bibliothèque Nationale de France, that does archiving on a national level. I will try to ask these questions. Between now and then. That's in January."
Bill: "What I want from this group is a clear definition of scope. On the one hand there are archiving services - that are sector specific - and have entirely opposite approaches. Then you have national libraries - that also have very active and very different archiving things. On the opposite side of the scale, you have an archive that a publisher would want to create to have a canonical item that they would want to use for the publication. Is our scope all of that, some of that. Are we supposed to point this out?"
<lrosenth> +1 to Bill_Kasdorf
...: "PDF-A is mainly for publishers to have a canonical items?"
Tzviya: "We're slowly defining exactly what it is..."
Ayla: "I wanted to push back on the 'we can get this done in a week'"
Ivan: "That was a joke :) "
...: "Whatever finidng you have between now and January - if you send it
to me, that would be helpful"
Leonard: "Depends on who you're sending the content to and their purposes. Everybody has different requirements. There are commonalities - but who are we trying to address and why?"
Tim: "Archives have different levels of re-use (what they saw VS simply saving bit/bytes)"
Leonard: "Thats part of the question - long term vs short-term"
<Zakim> liam, you wanted to say no, versioning is a separate issue
Liam: "We've had a symposium on long-term archiving of
documents in the XML world - and we should connect into some of that."
... "Another way to look at versioning - is that if you have two
different versions, then you have two documents, which would mean you
have two different formats... To document the exact version of every
spec, it's an enormous task. If you come back in 50 years and you need
to get something that uses javascript working. To see how large it is,
you should see what the LOC has had trying to get versions of hypercard
working that require very specific versions of items working. "
<lrosenth> From the Library of Congress - http://www.digitalpreservation.gov/formats/intro/intro.shtml
<lrosenth> EPUB - http://www.digitalpreservation.gov/formats/fdd/fdd000308.shtml
Heather: "Did we come to resolution - do we need a taskforce?"
Tzviya: "Yes, it seems we need a task-force for archiving."
... "We're meeting for the next two weeks, then take a week off."
<Bill_Kasdorf> Please sign up for Locators TF: https://www.w3.org/dpub/IG/wiki/Task_Forces/locators
<tzviya> http://www.w3.org/2015/12/01-tag-nominations
Bill: "We are bringing up a locators task force - those interested in working on the locators - please add your name to that roster as the starting point."
Tzviya: "Please VOTE in the TAG elections. These are the people who make the high-level architecture decisions. Look at the link I just sent."