Protocols and Formats Working Group Teleconference -- 24 Jan 2014

<trackbot> Date: 24 January 2014

Modularization

<MarkS> RS: by modularization, I don't want to make ARIA a monolithic spec that has all ontologies we can think up in it.

<MarkS> ...I don't think we're going to see ePub semantics apply to an SVG drawing for instance

<MarkS> ...ePub wants to get their info exposed to AT so they can get it to work on their platform

<MarkS> ... OWL, break off that taxonomy and do a separate thing based on charting

<MarkS> ...those who wish to implement it can go do that

<MarkS> ...should be able to get people to do that with us

<MarkS> ... this will impact our implementation guides. A core implementation guide, based on what we have today, in a single doc with base ARIA semantics

<MarkS> ...technologies are moving toward a single DOM

<MarkS> ...tab-index, javascript support, for instance, same events in HTML in SVG

<MarkS> ...common set of events, common DOM

<MarkS> ...SVG can bring up an iframe now. A single model is evolving.

<MarkS> ...allows us to have a core implementation guide that can be used in various markups

<MarkS> ...if we want to creat additional semantics, say for SVG, we can have one for charts, reference from SVG spec for roles states and props.

<MarkS> ...in the HTML5 spec, instead of having a mapping guide for everything in HTML5 we can refer to host language semantics in the main document

<MarkS> ...you have to have the mapping. refer back to the main document

<MarkS> ...if we do this in moderation, we should be successful (looking at you CSS)

<MarkS> JC: do you have a list of modules in mind?

<MarkS> RS: SVG, would be called a Drawing Module, visual objects, grammar of graphics

<MarkS> ...analytics, x-axis, y-axis, locations

<MarkS> ...opportunities for a role description in that space

<MarkS> ...think subway map

<MarkS> ...might be able to have users create their own semantics for specialized drawings like that.

<MarkS> JC: Doug emailed last night looking for specific roles to consider

<MarkS> RS: easy to do without thinking about the entire taxonomy

<MarkS> ...Processing, would that be a separate subgroup?

<MarkS> ...Rich Text?

<Zakim> jcraig, you wanted to suggest we keep the list of all the possible roles in the same document. for simplification.

<MarkS> ...Stuctural book semantics, Drawings and Processing so far

<MarkS> JS: will be strange to have core roles and other roles in a separate document. BE great to be able to pull shared roles into core document.

<MarkS> MS: asks about roles differing based on context

<MarkS> JG: article might be an example of that

<MarkS> JC: validation rules might be able to handle problems like that

<MarkS> SM: we talked about a Grid module yesterday

<Zakim> ShaneM, you wanted to talk about M12N publication strategies

<MarkS> JC: we might not want to go that small. maybe "external data sets"

<jcraig> eg. tables, lists, etc

<MarkS> SM: do we need modules? Strong case for that. How do we get those out to the public? don't need to decide that

<MarkS> ...on avoiding collisions, we can avoid collisions. the role attribute rec has a mechanism for this, its called namespaces. just scope it.

<MarkS> JC: ePub is already using namespaces

<richardschwerdtfeger> http://www.idpf.org/epub/vocab/structure/

<MarkS> ...can break anything for ePub out.

<richardschwerdtfeger> q/

<MarkS> RS: these are namespaced

<Zakim> bgaraventa, you wanted to discuss roles dialog alertdialog and application if time permits

<MarkS> BG: if time later on would like to talk about how role = dialog is supposed to improve accessibility. jQuery live is creating some problems. Could be a messaging/training issue

<MarkS> RS: jQuery has people working on a11y, but nobody overseeing and verifying it.

<MarkS> ...its a big problem

<Zakim> MichaelC, you wanted to say I would like to use the taxonomy as a base for modularization and to say generating a master list is easy, that doesn´t need to impact modularizing the

<MarkS> MC: sounds like we are steering towards modularization based on types of content. I think we should us the taxonomy as a tool to define those. To me, that would be the core module. Would have to consider if the core is nothing but abstract roles. Gives us the framework and an extensibility mechanism.

<MarkS> ...Creating a master list of roles is easy.

<MarkS> ...the other way of looking at this is different audiences. The core of ARIA is a base tech layer that is of interest only to us and those working closely with us. Then there are concrete roles that are of interest to a wider audience, implementers for instance, then you have authors who need to know when to use these.

<MarkS> ...multi-dimensionally

<MarkS> ...want to avoid spec proliferation but not one spec to do it all.

<MarkS> ...how would we handle implementation guide...

<MarkS> CS: this sounds too unwieldy to me.

<MarkS> ... what about what HTML is doing with their extension specs.

<MarkS> ...every year do a dot release of ARIA. If an extension spec is ready at that point, it goes in

<MarkS> ...there is a way to work on things separately. but have one spec moving along

<MarkS> MC: these approaches may not be exclusive

<MarkS> ...if we don't have a guiding taxonomy, there will be a divergence in the way problems are solved and we could get collisions.

<MarkS> CS: we don't need to expose the taxonomy to the users (modularization)

<MarkS> MC: right, not necessary for the consumers to know

<MarkS> ...CSS is creating snapshots.

<Zakim> cyns, you wanted to speak in favor of a method similar to html5 extension specs

<MarkS> MC: i think we can solve that with how we pull things together

<jamesn> +1 to cyns on this

<MarkS> CS: i would like to avoid separate documents moving independently

<Zakim> ShaneM, you wanted to discuss follow your nose support for roles

<MarkS> SM: is there any notion that people who are implementing support for ARIA are using the taxonomy to help drive the architecture of the screen reader? Are you using it mechanically or visually?

<MarkS> JC: I think you mean "using it as a mapping tool for UAs" not ATs

<MarkS> ...there is an additional cost of developing that way.

<MarkS> CS: MSAA uses COM inheritance, UIA is .net. goal for us to have web and client applications behave the same. to have ARIA stuff be different is not a feature for us. in IE we match it as closely as we can.

<MarkS> SM: as we expand these roles won't it be harder to find mappings for all of them?

<MarkS> JC: all the same base rendering engine

<MarkS> ...if we determine a particular role is important than we can map it.

<MarkS> RS: HTML is well along at this point, but the drawing and RTE is not

<MarkS> ...want to avoid just sticking new roles in

<MarkS> RS: what about working on them independently and then rolling it in when its done?

<MarkS> JN: that is what cyns is saying

<MarkS> JC: the great thing about that is that the group working on that could pub a WD a month from now.

<Zakim> MichaelC, you wanted to ask if a community groups or extension specs approach is what cyns was thinking?

<MarkS> JS: so if we use this model, then these extension can't be rolled in until they reach CR

<MarkS> MC: I think we want a degree of consistency between spec that HTML is not necessarily concerned about.

<MarkS> ...we want to have a taxonomy, we want to have roles, structure, etc. as long as we are organizing and have a well defined structure, I'm OK with this model.

<MarkS> ...is it on the REC track or not? If it is, then we have to include it in our REC track. but I think they should be put on our same review cycle

<MarkS> CS: what about 12-18 month pub cycle

<MarkS> agreement

<MarkS> MC: when we receive module is fairly mature. we'd be starting from scratch

<Zakim> jcraig, you wanted to state that I think the epub module could be standalone and to say something like a graphics module should be part of the same document and to defend the CSS

<MarkS> JC: CSS does cool think with breaking up CSS grammar into its own specification. changes infrequently, anytime they add a new property, makes it easier for reviewers to work on.

<MarkS> ...breakdown of different parts of the language. If you want to review selectors, you only have to review that one doc, or just the new stuff that was added. Easy for spec authors. Potentially easy for web authors looking to find specific information.

<MarkS> ...cyns point that it s hard to find info as a web developer is a problem, but its not a major problem because few read our specs to find this out, they read books, articles, etc.

<MarkS> ...for implementers it may be an issue, but that can be solved with a list of the modules or some other organizing document.

<MarkS> CS: there is also an issue for reviewers. whenever I review a CSS module, I find a dependence on another module that isn't in a reviewable state.

<MarkS> JC: the ePub module could be standalone. greatly simplifies the number of additional roles we need to add to 1.1 if we pull out ePub and Drawing

<MarkS> ...a 1:1 mapping is something that should be done as one of these additional modules. Should go into a point release. Paragraph, em, strong, etc.

<MarkS> RS: we could evolve the implementation guide

<MarkS> JC: the implementation guide could point to a map of the 1:1 guide

<MarkS> RS: i want to get rid of the duplication

<MarkS> MC: are the implementation guides modularized in the same way the feature specs are?

<MarkS> RS: SVG is a host language and would need its own guide.

<MarkS> CS: who would be responsible for the host language mapping

<MarkS> RS: we would

<MarkS> ...i would rather have what we have now and add some abstract roles

<MarkS> JC: i'm talking about not doing the 1:1 mapping in a separate document so that its not included in this point release. eventually it will make it back into the main document.

<MarkS> ...some can be generic, like div which can also be used in SVG

<MarkS> RS: we should refer to the core spec, ARIA 1.1 then define mappings that we're not willing to define in the ARIA implementation guide

<MarkS> CS: works better if you maintain a firm production timeline and if a feature is not ready, it gets put on the next train

<MarkS> ...and there will be a next train

<MarkS> JG: who is going to work on this?

<MarkS> ...collaboration?

<MarkS> MC: we need a strong well structured guide.

<MarkS> JN: I know I can find people to work on focused topic, like Drawing

<MarkS> JS: are these optional for implementers?

<MarkS> ... what does an implementer have to support?

<MarkS> MC: the only difference is that we publish these as separate documents.

<MarkS> JC: they become rec track when folded back in.

<MarkS> MC: another solution is we can define conformance classes, eBook readers, etc.

<MarkS> JS: if they stay separate its easier to say what you support as an implementer

<MarkS> JG: will there be cross collaboration between ePub aria people and SVG aria people?

<MarkS> DM: I can see jon's point about how some modules don't mesh well with how others might want to use it in theirs

<MarkS> ...is there some sort of shared approach, database approach that can solve that?

<MarkS> MC: in W3C speak we have something called profiles, subsets of a spec

<MarkS> CS: perceived as less than full compliance though.

<MarkS> RS: all epub browsers are built on webkit, blink or trident. Whatever we put on the web, they get.

<MarkS> MK: two ?'s Talked about Drawing module earlier, not SVG module. In practice is each module going to be associated with a particular host language?

<MarkS> no

<MarkS> JC: 1:1 mapping for HTML: i don't even mean one role per element. one role for each element. some can be shared.

<MarkS> ...less additional roles than there are elements

<MarkS> MK: that was my concern, wondering if that problem would proliferate based on this solution.

<MarkS> ... role that says this element carries zero a11y semantics

<MarkS> JC: we have presentation and that is similar to null/zero role

<MarkS> MK: If you have a module that doesn't have a host language... any examples?

<MarkS> CS: host language access and module access. HTML would include graphics, document roles, UI roles, etc.

<MarkS> MK: canvas too.

<jcraig> ISSUE: Generic container roles for things like div/span, possible a "none" role. Need to avoid confusion with "presentation" role. (This issue may be a duplicate.)

<trackbot> Created ISSUE-638 - Generic container roles for things like div/span, possible a "none" role. need to avoid confusion with "presentation" role. (this issue may be a duplicate.). Please complete additional details at <https://www.w3.org/WAI/PF/Group/track/issues/638/edit>.

<bgaraventa1979> to be clear role=presentation removes the tag but keeps the text in the accessibility tree

<MarkS> CS: HTML is a good example of a general purpose language

<MarkS> MK: so we wouldn't call what we have now an HTML module

<MarkS> correct

<clown> right bgaraventa1979, it ignores the element role, but keeps the content.

<Zakim> ShaneM, you wanted to talk about optionality

<MarkS> SM: think we need to be super careful. if we are going through the trouble of producing an ARIA spec for something, we would want everyone to support it. It needs to be supported in the browser.

<Zakim> jcraig, you wanted to mention that, if the drawing roles aren't useful outside svg, what's the problem with namespacing (svg:* like epub:*)

<MarkS> JC: even within the HTML docs, canvas element's fallback content for instance, if authors do fill the sub-dom they could still use the SVG namespace inside that.

<MarkS> ...SVG is the only markup based language

<MarkS> CS: don't want to have it limited to one host language

<MarkS> JC: lets just not call it accessibly graphics

<jcraig> don't want any stigma that comes with the term "accessibility"… some people will see that and think "these role are not useful outside the context of screen readers, but indexing charts/slides/etc would be great as machine-readable data for a number of reasons.

<mattking> please note telephone is muted

<mattking> OK, pls unmute phone in conference room.

<mattking> thanks

<MichaelC> scribe: MichaelC

jc: ... large datasets

jg: how will the sub areas coordinate through the main group?

js: already interest from people working in specialties, who wouldn´t work in main

jn: so when something is ready, it goes in, otherwise it doesn´t

jc: when someone wants to propose a module, they should approach us

rs: we need a process

otherwise a lot of purely academic stuff could be done

cs: there is some stuff that is pretty clearly needed

and also have people who might focus on those

rs: @@?

jc: 2.0

js: so we´re ready on a set of modules?

Core, Publishing, Graphics, Editing

rs: platform owners need to work with these groups to ensure success

jc: there was proposal to use ag pattern for ¨accessible graphics¨

that in particular gets into confusions in the larger sphere about what ¨accessibility¨ means

mc: why not use aria- prefix?

jc: this is for roles

mc: but we control the roles

we would review module submissions for collisions

cs: and if different groups need the same thing, just use the same role

smc: and semantic accessibility is relevant

jc: one reason I want to avoid the a11y term

mk: would be good to have a single ontology

cs: and avoid namespaces

mc: nothing stopping modules from using patterns where sensical, just don´t impose
... big dangling question is whether current features are part of core or separate modules

cs: can have document structure, user interface, etc. modules

which cover much of what we have

rs: you want to break it up?

mc: in 2.0, not 1.1

cs: so core wouldn´t be something we use in implementation

mc: yes

rs: module builders need it

cs: so it´s a TOC

<jcraig> like the CSS TOC http://www.w3.org/Style/CSS/current-work.en.html

mc: and the taxonomy

<jcraig> http://www.w3.org/WAI/PF/aria/complete#roles_categorization

jc: so the current roles?

mc: the current abstract roles would be in the core

the concrete roles would move to a module

jc: we have document structure, landmark, and widget

cs: that´s a way of breaking up the module

<richardschwerdtfeger> k

jc: I´ve done an alphabetized list

cs, mc: still want that, it´s just not the organizing feature

dmd: not all designers get these subtleties

cs: they don´t need to

mc: we can have views

<Zakim> jamesn, you wanted to day that some are in the wrong place currently

jn: some of roles might move

jc: I hear that modules means separate documents. Don´t we want it all in a master?

mc: not sure we´ve decided either way

cs: would like flexibility to go either way

dmd: how to implement graphics?

mc: applies to whatever technology

cs: though alt on img normally ok

mc: can only use ARIA if there´s structure to attach it to

jc: WebGL doesn´t use markup but can attach responders

mc: why is why I said ¨structure¨ not ¨markup¨

cs: could use an imagemap to attach ARIA if useful

RESOLUTION: Structure ARIA 2.0 as an abstract base (which would not itself be implemented) plus modules / categorizations which may or may not be in separate documents. Currently planned modules may include document structure, user interface, EPub, graphics, editing, data collections.

mc: About document sets

<clown> http://www.w3.org/WAI/PF/wiki/Outline_Core_User_Agent_Implementation_Guide#Core_User_Agent_Implementation_Guide

we don´t know what docs there would be

but we could do user agent guides for content technologies like HTML, SVG, EPub, etc.

rs: plus a base

mc: ??? what does that cover?

rs: base how ARIA semantics map to a DOM

<clown> http://www.w3.org/WAI/PF/wiki/Outline_Core_User_Agent_Implementation_Guide#Core_User_Agent_Implementation_Guide

mc: so this is stuff that is not specific to a particular

think much of the current UAIG can be core, but think role and property mappings is not base

rs: but some of that is used across host languages, don´t want to duplicate

mc: but it´s inherently not base

we can address duplication, by edit once, publish multiple structure if needed

<jcraig> drop item 10

duplication might be desirable because HTML and SVG implementers will be different people probably

rs: but there´s so much that is duplicated

ac j

<Zakim> Joseph_Scheuhammer, you wanted to announce that lunch will be ready 12:30pm.

-- brain reboot break --

js: we´ve been talking 2.0 because of future planning

but have immediate work to do on 1.1

how much of 2.0 do we need to implement now?

mc: so, I´m ok with the proposal in the wiki

except SVG component is 2.0

rs: but need to start it

<Zakim> jcraig, you wanted to say that this modularization discussion may have covered both the modularization and extensibility agenda items

mc: that´s fine, we´re working in parallel

can slot where it goes later

ok to proceed with this proposal for 1.1

dialog/alertdialog (from Bryan)

bg: what should be expected behaviour of dialog and alertdialog?

right now, they are treated very similar by screen readers

static content goes invisible

not scalable

mk: spec currently says dialog is an application

<clown> http://www.w3.org/WAI/PF/aria/roles#dialog

therefore some AT go into application mode

should treat dialog as isolated portion of document

and not have dialog role dictate how AT handles it

a couple AT do

<Zakim> jcraig, you wanted to discuss the document vs application scenario, and that any static contents in a dialog not referenced by aria-labelledby or aria-describedby and to mention

jc: we´re not the ones telling AT to do this

<Zakim> jamesn, you wanted to ask if this isn't simply a screen reader bug?

they decided to switch into application mode on dialogs

whether or not you provide application

mk: but the spec is confusing

anyway, one has stopped

jc: have seen in e.g., terms of service documents

that have a scroll region with the legalese

a page can have multiple application and document regions

so the dialog can have static text referenced by aria-describedby or aria-labelledby

or have content in a documention region and AT switches out of application mode

bg: that works, but developers don´t know how to do that

jc: we can make that easier

HTML 5 dialog API has inert property on dialog

if it´s modal, graying out stuff behind it which you can see but not interact

that pulls all the other stuff out of the a11y tree also

so long term, want to implement dialogs so you don´t get to content outside of the modal reason

rs: have to extend @@

cs: something in Web page can´t affect what´s outside browser

jc: that´s not yet implemented though, right now have to use @aria-hidden

mk: right now don´t need to use application anywhere, even in modal application

jc: but there´s more problems than AT behaviour

that inert will solve

e.g., keyboard interaction

mk: we tell authors to keep focus in dialog

jc: that´s a huge pain without breaking other stuff

bg: @@

jc: virtual buffer

mk: issues are that AT treat like application and don´t limit view

bg: @@

rs: so virtual cursor allows arrow out of dialog

bg: yes

js: that´s a bug

rs: will follow up

mk: there are words in the text that leads to these implementation problems

<David_MacD_Lenovo> A dialog is an application window that is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response.

<scribe> ACTION: king to propose edit to dialog role to clarify issue that leads to bad implementation [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action01]

<trackbot> Created ACTION-1346 - Propose edit to dialog role to clarify issue that leads to bad implementation [on Matthew King - due 2014-01-31].

rs: alertdialog?

bg: @@

<Zakim> Joseph_Scheuhammer, you wanted to point out that the APG does advise the switch to "application" mode for dialogs.

<clown> When using dialog, all static text must be associated with widgets, groups or panes using the aria-labelledby and aria-describedby properties, otherwise it will not be read by the screen reader when the user navigates to the related widget or group.

clown: Authoring Practices says all text in dialog must be associated with a widget

action-1346: look at APG as well

<trackbot> Notes added to action-1346 Propose edit to dialog role to clarify issue that leads to bad implementation.

<clown> mattking: http://www.w3.org/WAI/PF/aria-practices/Overview.html#kbd_layout_impact

action-1346: http://www.w3.org/WAI/PF/aria-practices/Overview.html#kbd_layout_impact

<trackbot> Notes added to action-1346 Propose edit to dialog role to clarify issue that leads to bad implementation.

<Zakim> jcraig, you wanted to mention aria-modal attr for dialogs

mk: the best practices are maybe not necessary anyways

jc: thinks there is an error in assuming all dialogs are modal

non-modal dialogs, focus moves there, but you can move the focus out of it

maybe we need an aria-modal property

mk: in one AT you can stop interacting with dialog, pops you back out

even in a modal context, want to be able to go back and forth

jc: think HTML inert will handle keyboard stuff

out of scope for AriA

the context issue is not spec issue, though we could tweak support materials

only spec issue is not distinguish modal and non-modal

rs: @@

<jcraig> ACTION: jcraig to add an attribute for differentiating modal vs non-modal dialogs/menus/etc. (possibly aria-modal) [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action02]

<trackbot> Created ACTION-1347 - Add an attribute for differentiating modal vs non-modal dialogs/menus/etc. (possibly aria-modal) [on James Craig - due 2014-01-31].

bg: a script library implementation @@

rs: one of our collaborators should get that fixed

<jcraig> action-1347: could recommend here that UAs or ATs automatically move context to modal elements

<trackbot> Notes added to action-1347 Add an attribute for differentiating modal vs non-modal dialogs/menus/etc. (possibly aria-modal).

jn: is that a transitory problem related just to current AT bug?

bg: @@

rs: there were lots of examples in APG

Dangling issues

jc: found a bunch of issues without products assigned

put a bunch of them on 2.0

some I think could apply to 1.1

so we´ll need to pick those up when we return to issue scrubbing

<davidb> Note to all, just a heads up that we need to move into a meeting room called Finch at 4pm due to a conflict.

<davidb> Also, regrettably, I'll be a bit later than planned (unavoidable)

<ShaneM> ScribeNick: ShaneM

<clown> https://www.w3.org/WAI/PF/Group/track/products/17

Scrubbing ARIA 1.1 Issues and Actions https://www.w3.org/WAI/PF/Group/track/products/17

issue-427?

<trackbot> issue-427 -- Need a way for application to find out what role has been applied to or computed for an element -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/427

JC: It would be convenient for a lot of reasons. If you have something like a UL in HTML, it gets a default role of list. But this is not discoverable from JS.

<clown> <div role="foo checkbox">...

<clown> <div role="switch checkbox">...

JC: no way for authors to know which one is applied when the engine is making a choice.
... proposal is for a readonly attribute on the DOM element that could be used to ask what the current role of an element is.
... thinks we may be able to get it into 1.1

RS: In order to do this would we need to interact with whoever owns the DOM?

JC: We can add a partial spec. But the group in charge could object.

RS: I think this is needed, but don't know if we get away with it.

JC: We can put it in and see if it gets objected to. We definintely need it for 2.0, but earlier would be much better.

JN: Does this include implicit roles?

JC: yes. So we would need to clarify what the default role is in all cases. There should not be any ambiguity.
... this is the ARIA normalized role, not some internal role.

RS: We defined a processing model for 1.0. Is it possible that model could change in 2?

<MarkS> Decision to move DOM4 to HTML WG

JC: as far as I know role is the only attribute where it is an ordered token list. We can't change that.

SM: There are other attributes where the order matters, but there is no DOM support for it directly.

RS: I am only a little concerned that something might change down the road. And you would want the whole list. Or the list of relevant roles.

JC: If that happens we could add another interface. Or this could return an ARRAY instead of a STRING.
... In the current version there is one definitive role. I don't think we need to be able to return a list today.

RS: But we could just address it today and for now it would always return a single element list. The first element in the list could be the computed role.

JC: Remember we are just in bug scrubbing mode now. We can get to the fine points later.
... Would firefox implement support for something like this?

AS: Why would this be exposed outside of the A11Y layer?

JC: Because a search engine might need more information to impute semantics about content (e.g., slides in a presentation)

CS: Why would anyone need to get access to this?

JC: use cases include discovering whether the inherited role is what you expect. Validation. Testing.

CS: It seems unlikely that we would implement this. I don't understand what the actual value is to end users.

JC: This could help provide for A11Y inspection in the web development context.

<Zakim> Joseph_Scheuhammer, you wanted to note we need test case(s).

JC: Authors are not getting this right today.

MK: We need something like this for computedName too.

JC: computedLabel would be good too.
... would need to be careful here. Screen reader users may hear something different than what the computedLabel is.
... but it would allow us, within the browser at least, to see if stuff is closer to correct.

CS: This would lend a false sense of security.

JC: No - it tells them more information than they have today.

MK: This would be very helpful for developers.

CS: I think developers should be testing at the screen reader level.

JC: But they do not. They don't even really test across platforms heavily.
... Let me repeat what David said - it is way too hard to make an accessible web application.

CS: It gives them a false positive.

JC: No - it is not false, but it is not complete.

MK: Telling people that they should test at the screen reader level is sort of silly.

JS: We need to decide whether to do this or not, and when.

JN: We do this for our developers, but we do it at the A11Y layer. We want to do it at both layers.

(discussion - but more of the same)

JG: I think it is a great extension. We have computed stuff and helps make inspection tools more complete.

Joanie: Would the extension say that it is a "ARIA Role Button" or is it the "ATK Button"?

JC: The ARIA Role Button

joanie: Is there a way to make the underlying item available?

JC: maybe. but it might not be as useful. We are looking for the applied ARIA role because it should be the same on every platform.

RS: When authors test they are looking at content a11y APIs, not platform APIs. They run on their pages with automation tools such as Selenium.
... today we cannot tell if the computed names and computed roles are right.
... If the computed item is wrong then that would be good to know.

<mattking> can we move to next issue?

joanie: This is neat. This is a double edged sword though. ATs can implement whatever APIs are needed. But if there are older browsers involved then the data might be inaccurate.

<Zakim> jcraig, you wanted to say I hear all but one person saying this will be useful

JC Note that when there is a new item we are always going to recommend that roles are user such that they 1.1 role can be fallen back to.

JC: Reminder that we should be scrubbing not specifying. Can we move on?

Brian: Would this include default role?

JC: Yes. It would absolutely use default roles AND flag invalid roles.

CS: In additional to my concerns it seems big. Hard to specify and hard to implement.
... because ARIA does not currently specify any JS interfaces.

JC: We can always specify that it is at risk.

Maybe it should be in a separate "module"

JC: Could be in a module. I have lots of things like this in my list of suggestions for 2.0.

CS: If we implemented patterns (actions) then we would need JS stuff anyway.

David: Space delimited. Fall back. Method would show exactly computed role is being sent to the accessibility layer from the browser for a given element. Is that right?

JC: Explaination of the concept with visual aids.
... you need to be an expert in order to write ARIA that is anything beyond simple today. This would help people who are trying to do things that are complex be more likely to do them correctly.

CS: How does Safari figure this out now?

JC: It is all in webcore

CS: How do you know that the computed role that is being reported is right?

JC: We are doing a reverse lookup from the internal table of roles to the platform roles
... Most web developers don't use the native tools for platforms when testing.

CS: It feels like this is only half way, and that half is not giving accurate information.

JC: Who feels this would be useful? (nearly everyone)
... Would firefox be interested in supporting this?

Alex: Maybe if it were not in the DOM tree.

JC: But this is intended to be a readonly DOM attribute.

MK: Lots of things could be useful here - not just computedName and computedRole

<jcraig> ISSUE-427: Also computedLabel()

<trackbot> Notes added to ISSUE-427 Need a way for application to find out what role has been applied to or computed for an element.

issue-517?

<trackbot> issue-517 -- #aria-haspopup has normative-like statement in values table. Should probably have RFC prose regarding author SHOULD manage focus and use aria-owns on any non-descendant popup. True value currently means the menu MUST be an OWNED element. -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/517

JC: This is currently ambiguous. Its a simple edit.

<jcraig> ACTION: jcraig to patch issue-517 [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action03]

<trackbot> Created ACTION-1348 - Patch issue-517 [on James Craig - due 2014-01-31].

issue-561?

<trackbot> issue-561 -- We need @aria-placeholder as backup for @placeholder in custom fields. -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/561

CS: If HTML has this we should too.

JN: Where does it map into the name computation?

<jcraig> ACTION: jcraig to patch ISSUE-561: We need @aria-placeholder as backup for @placeholder in custom fields. [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action04]

<trackbot> Created ACTION-1349 - Patch issue-561: we need @aria-placeholder as backup for @placeholder in custom fields. [on James Craig - due 2014-01-31].

RS: The HTML5 spec indicates how this is computed already.

issue-565?

<trackbot> issue-565 -- Consider making aria-leve, aria-posinset, and aria-setsize global attributes -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/565

RS: I think this could be on more, but not on everything.

MK: Could it be 2.0?

RS: well, it should be looked.

JC: Can we close this and then do things individually as we move around?

JN: There are other issues that are more specific?

RS: Give me an action to look and make a specific proposal.

<scribe> ACTION: richardschwerdtfeger to make specific proposals for whether aria-level, aria-posinset, and aria-setsize might be needed [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action05]

<trackbot> Error finding 'richardschwerdtfeger'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.

<jcraig> ACTION: Rich to propose specific edits or close ISSUE-565: Consider making aria-leve, aria-posinset, and aria-setsize global attributes [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action06]

<trackbot> Created ACTION-1350 - Propose specific edits or close issue-565: consider making aria-leve, aria-posinset, and aria-setsize global attributes [on Richard Schwerdtfeger - due 2014-01-31].

<clown> action-1347?

<trackbot> action-1347 -- James Craig to Add an attribute for differentiating modal vs non-modal dialogs/menus/etc. (possibly aria-modal) -- due 2014-01-31 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1347

issue-569?

<trackbot> issue-569 -- Introduce an ARIA attribute to indicate a column is sorted -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/569

RS: If multiple columns are sortable - how can you tell which column is actually sorted.

JC: There can be multiple columns sorted too.

RS: Do we want to have a 'active' sort?

JC: It should be the sort order. primary, secondary, tertiary.

MK: There is a fair amount to talk about here. Do we really want to take 1.1 time on this?

JN: Would it make more sense to expose this on the cell than on the column header?

CS: I think we want to think about grids holisitically.
... If we do something now and then do something later that would be worse.

Punt to 2.0

issue-574?

<trackbot> issue-574 -- Add required state of aria-selected to role option, and implicit value aria-selected='false' -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/574

Is a straight edit.

<jcraig> ACTION: jcraig to patch ISSUE-574: Add required state of aria-selected to role option, and implicit value aria-selected='false' [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action07]

<trackbot> Created ACTION-1351 - Patch issue-574: add required state of aria-selected to role option, and implicit value aria-selected='false' [on James Craig - due 2014-01-31].

<jcraig> ACTION: jcraig to patch ISSUE-576: Add aria-posinset, and aria-setsize to tab role [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action08]

<trackbot> Created ACTION-1352 - Patch issue-576: add aria-posinset, and aria-setsize to tab role [on James Craig - due 2014-01-31].

<jcraig> action-1352

<trackbot> action-1352 -- James Craig to Patch issue-576: add aria-posinset, and aria-setsize to tab role -- due 2014-01-31 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1352

issue-580?

<trackbot> issue-580 -- Consider changing rowgroup superclass to structure (from group) to prevent inheritance of other supported attrs in ARIA 1.1. -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/580

<David_MacD_Lenovo> http://www.w3.org/WAI/PF/aria/#tablist

<clown> http://www.w3.org/WAI/PF/aria/roles#tablist

<jcraig> ACTION: cooper to fix generated URL: http://www.w3.org/WAI/PF/aria/#tablist [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action09]

<trackbot> Created ACTION-1353 - Fix generated url: http://www.w3.org/wai/pf/aria/#tablist [on Michael Cooper - due 2014-01-31].

<jcraig> ACTION-1353: in #aria-descendant

<trackbot> Notes added to ACTION-1353 Fix generated url: http://www.w3.org/wai/pf/aria/#tablist.

<clown> http://www.w3.org/WAI/PF/aria/roles#group

punt to table / grid discussion for 2.0

CS: This might be a platform interoperability issue.

JC: Remember that we did this organization on purpose.

CS: rowgroup and colgroup are important

<David_MacD_Lenovo> @ Michael ... many of the roles links are not working

<jcraig> ACTION: jcraig to patch ISSUE-580: Consider changing rowgroup superclass to structure (from group) to prevent inheritance of other supported attrs in ARIA 1.1. [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action10]

<trackbot> Created ACTION-1354 - Patch issue-580: consider changing rowgroup superclass to structure (from group) to prevent inheritance of other supported attrs in aria 1.1. [on James Craig - due 2014-01-31].

RS: We can do this in 1.1 - it is simple.

<jcraig> action-1354

<trackbot> action-1354 -- James Craig to Patch issue-580: consider changing rowgroup superclass to structure (from group) to prevent inheritance of other supported attrs in aria 1.1. -- due 2014-01-31 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1354

issue-588?

<trackbot> issue-588 -- Clarify rowheader and columnheader selection (editorial) -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/588

<clown> http://www.w3.org/WAI/PF/aria/roles#rowheader

JC: Request for the group. If something is really editorial, just create an action on JC rather than an ISSUE.

MK: I have a question though - is this really editorial?

<clown> http://www.w3.org/WAI/PF/aria/roles#columnheader

JN: There could be a use case where you only want to select a header instead of the whole row.

MK: If we are talking about how it propagates then isn't that a UIAG issue?

<clown> http://www.w3.org/WAI/PF/aria-implementation/#mapping_events_selection

JN: If the author wants them to be selected the author should mark them as such.

RS: The AT should not have to be going back up to the document to see what is selected.

MK: If the application provides a way to selected every cell, then it will set aria-selected on every cell. Then the AT would just know.

RS: But then we don't tell the authors to set those flags.

MK: Oh - then maybe this is for the authoring practices.

JC: this is an authoring practice.

RS: how they render it visually may not mean they automatically use aria-selected.

MK: Note that this is not necessarily a table thing - it is just any time you perform an action where selecting many elements you need to set selected attribute on all the things that get selected.

(visual aids by JC)

<MichaelC> close action-1353

<trackbot> Closed action-1353.

<jcraig> ACTION: rich to propose specific edit for ISSUE-588: Clarify rowheader and columnheader selection [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action11]

<trackbot> Created ACTION-1355 - Propose specific edit for issue-588: clarify rowheader and columnheader selection [on Richard Schwerdtfeger - due 2014-01-31].

<jcraig> ACTION-1355

<trackbot> ACTION-1355 -- Richard Schwerdtfeger to Propose specific edit for issue-588: clarify rowheader and columnheader selection -- due 2014-01-31 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1355

MK: We should just give Rich an action to write some text and suggest where it goes.

RS: This would be about contextual selected.

David: This could be a technique too.

<scribe> ACTION: 1355 to Possible to be a WCAG Technique, in the authoring guide, in the HTML5 binding document. [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action12]

<trackbot> Error finding '1355'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.

ACTION-1355: Possible to be a WCAG Technique, in the authoring guide, in the HTML5 binding document.

<trackbot> Notes added to ACTION-1355 Propose specific edit for issue-588: clarify rowheader and columnheader selection.

<jcraig> https://www.w3.org/WAI/PF/Group/track/actions/1355

issue-593?

<trackbot> issue-593 -- Reflect the fact that browsers are now exposing child content for things like sliders, separators, scrollbars (childrenarepresentational) -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/593

<David_MacD_Lenovo> I will file new issue using aria in html 5: if selecting any piece content causes selection to more than that element then add aria selected to all the other selected items

demonstration by JC of video and how shadowDOM works

The group understands the issue, and wants to punt to 2.0

<clown> When the user triggers an element that is only focusable because of its tabindex attribute in a manner other than clicking it, such as by pressing Enter, and the element has no defined activation behavior, fire a click event

JC: there was a bit punted from 1.0. If you added a role of button and tabbed to it then pressing return would activate the button. It was in the UIAG but not in a way that was really concrete.

<clown> The above is a quote from the UAIG

JC: all I am proposing is that when an element matching certain roles (that have activation) has a click event handler AND it is focusable, they keyboard event that would trigger a click event on a native control would trigger a click event on this control.

MK: How would the author know this?

JC: They don't need to know.

MK: What if they had done their own keyboard handlers?

JC: Then that would override.

RS: Note that this would be clearly specifying browser behavior. We have steered away from those because it is way too hard to reach agreement.

CS: Historically it has been hard to reach agreement on things like this.
... authors should not need to go out of their way to make keyboard events to work in the A11Y context.
... The developer puts onclick and not onkeypress. If you add role='button' it should just work and it does not right now.

JN: We would need a list of roles to which this would apply.

<bgaraventa1979> for grids, aria-selected is already documented for rows, not just cellswhat happens in the case of toolbar buttons? one tab stop?

MK: Interesting point. anchors get this now. why don't aria buttons get them now.

CS: The current behavior is broken.

JN: Why can't we require tabindex=0 too.

DB: key events bubble right?

JC: yes.

RS: can we limit it to a couple of roles in 1.1 and see how it goes?

CS: Two different issues.... is having role="button" on something focusable turn on click mapping? Second, is having role="button" on something that is NOT focusable change its behavior so that it becomes focusable?

DB: Would it be acceptable to just specify it independent of ARIA?

JC: tricky. But I like where you are going. What about a click handler on a superior element like body?
... I am hoping for platform specific behavior for the particular role.

DM: How would it get focus?

CS: We are requring tabindex (in 1.1 at least)
... This could have a huge impact on the A11Y of many applications.

DM: This would be a huge help to developers.

DB: I would like to run the general suggestion by some other people next week.

<scribe> ACTION: davidb to Chat about the general case solution of mapping onclick to keypress in certain circumstances with appropriate people and get back to the working group [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action13]

<trackbot> Created ACTION-1356 - Chat about the general case solution of mapping onclick to keypress in certain circumstances with appropriate people and get back to the working group [on David Bolter - due 2014-01-31].

<scribe> ACTION: cyns to Chat about the general case solution of mapping onclick to keypress in certain circumstances with appropriate people and get back to the working group [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action14]

<trackbot> Created ACTION-1357 - Chat about the general case solution of mapping onclick to keypress in certain circumstances with appropriate people and get back to the working group [on Cynthia Shelly - due 2014-01-31].

<MichaelC> issue: Making key events work automatically on focusable elements matching certain roles (e.g. button, link, checkbox), that have click event handlers

<trackbot> Created ISSUE-639 - Making key events work automatically on focusable elements matching certain roles (e.g. button, link, checkbox), that have click event handlers. Please complete additional details at <https://www.w3.org/WAI/PF/Group/track/issues/639/edit>.

<clown> http://www.w3.org/TR/wai-aria-implementation/#keyboard-focus_tabindex

<jcraig> ISSUE-639: possibly (not not for certain) limited to specific roles: button, checkbox, columnheader, link, listitem, menuitem*, option, radio, tab,

<trackbot> Notes added to ISSUE-639 Making key events work automatically on focusable elements matching certain roles (e.g. button, link, checkbox), that have click event handlers.

<jcraig> ACTION: jcraig to compare the ARIA and UAIG text alternative computation specs, because they somehow got out of sync [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action15]

<trackbot> Created ACTION-1358 - Compare the aria and uaig text alternative computation specs, because they somehow got out of sync [on James Craig - due 2014-01-31].

<jcraig> scribe: jcraig

issue-601

<trackbot> issue-601 -- Ensure that regions must have a label -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/601

close issue-601

<trackbot> Closed issue-601.

<richardschwerdtfeger> http://www.idpf.org/epub/vocab/structure/

Mozilla has David_Bolter

Janina summary is events so far

ARIA 1.1 or 2.0 will contained modularized/categorized for specific sub-sections for things like graphics (SVG) , book (EPUB), etc

EPUB

<richardschwerdtfeger> http://www.idpf.org/epub/vocab/structure/

MG: EPUB Vocabulary is the "bread and butter" structural semantics used to "subclass" HTML in EPUB

Not specific to AT

used in distributional content, machine-reading systems, etc.

example: decoarates links, notes, etc. so the epub viewer can hide them contextually

ex: term semantics can be auto linked to glossary. etc

some aspects inherited from DAISY, so it has some roots in accessibility

but the role usage is not exclusively consumed by AT

main adoption we've seen is form non-AT clients

Some of these roles benefit AT directly. Some are not terribly useful to AT, but other machine-reading systems.

JG: HTML uses deprecated? Explain?

MG: Squeezed SMIL into EPUB, but those can't be used in HTML.

RS: accessible roles can be used for both accessibility and other use cases, correct?

MG: yes, but it is limited significantly in HTML

"HTML Chairs told us not to use @role in HTML"

MG: HTML disallows @role in HTML.

SM: No it doesn't. Not anymore at least.

MG: IDPF vocabulary is growing. Perhaps to some of you, alarmingly so.

sub-projects want to extend this vocab instead of using their own vocabulary

MG: Would this be extensible so that IDPF could manage it's own role usage for EPUB.

JC: discussed an epub role namespace earlier.

Some of the vocabulary are specific to "comics" (graphics layout books) for example rather than something needed in ARIA

Some things used audio vvs vibration api

<Zakim> jcraig, you wanted to ask why you're defining roles like page-break

MG: indicates a print page break, not a dynamic (e.g. CSS) page break

EPUB wants to migrate a way to migrate away from epub-namespaced attrs

Would extensibility happen soon enough for us to use ARIA in EPUB4, or should we continue to specify our own

SM: you can use epub-namespaced roles already

MG: but AT will not read those
... @@

<Zakim> jcraig, you wanted to mention fallback roles

<ShaneM> if ePub were to use scoped values in @role for things that are interesting to the ePub community that would be fine. Anything that you think should inform AT would need to have values that are in the ARIA space in order to ensure support from rendering engines.

JC: Could use a fallback accessible role in addition to epub role, e.g. role="epub:qna section"

<ShaneM> CS: I don't like overloading the use of @role with things that are not AT related.

Cynthia: I am concerned about combining the namespaced roles with the aria roles

<mgylling> Error Line 5, Column 54: Discarding unrecognized token baz:bar from value of attribute role. Browsers ignore any token that is not a defined ARIA non-abstract role.

MK: We should bring in the relevant epub roles into ARIA.

JC: Agreed, but epub could use the namespaced ones in the meantime, and indicate to user agent to support the epub: prefixed version. (e.g. future UA might recognized both aria "qna" and epub "epub:qna")

JW: Noting/Concerned(?) that role is overloaded. If recognized for epub, allow fallback to ARIA in an AT context. Namespacing may be a good waty to do that.

<ShaneM> MG: The validator is complaining about non-ARIA roles.

SM: MG's previous validation concern was a bug in the validator.

<ShaneM> ACTION: ShaneM to file a problem with the validator about role values that are scoped. [recorded in http://www.w3.org/2014/01/24-aria-minutes.html#action16]

<trackbot> Created ACTION-1359 - File a problem with the validator about role values that are scoped. [on Shane McCarron - due 2014-01-31].

<davidb> (general discussion)

<ShaneM> JC: a11y will get the recognized ARIA role. The ePub engine should get the ePub role value

<ShaneM> SM: Yes.

CS: This may complicate the UA internal processing, and I'm concerned that this will cause bugs in current or previous imoplementation. I want this to be additive, not a replacement. for example, bringing in this set of roles into ARIA with accessibility mappings for each.
... We need additional harmonization, not less.
... I want one definitive list of roles, managed by the ARIA/PF group.

<ShaneM> JC: anyone can do namespaced roles. We are talking with ePub so they might be special.

<ShaneM> JC: For example: figure is in the ePub vocabulary today. ePub could do epub:figure. If we did figure as well then we would recommend that an implementation support both.

MC: I'm hearing vendor prefixes.

<ShaneM> CS: I am concerned about handing the mapping from external to aria to implementation roles.

<Zakim> ShaneM, you wanted to talk about scoping of terms

<richardschwerdtfeger> scribenick: Rich

<richardschwerdtfeger> Shane: It was never the intent of the xhtml role presentation that we would assume accessibility semantics about things that are not in our name space

<richardschwerdtfeger> Shane: I think it is unrealistic to assume this and that the browsers will input this and pass them on

<richardschwerdtfeger> cynthia: roles was an accessibility thing in msaa

<richardschwerdtfeger> Shane: Role was conceived in xhtml2

<jcraig> JC: "role" in the general sense is not specific to accessibility or XHTML2

<richardschwerdtfeger> Jason: It is interesting that this issue is being decided such that this is a vocabulary that anything can create

<ShaneM> CS: historically 'role' IS related to accessibility.

<richardschwerdtfeger> Jason: If the accessibility community wants to claim complete control it is a bit late

<richardschwerdtfeger> janina: where do we want to end up

<richardschwerdtfeger> janina?

<richardschwerdtfeger> markus: I heard one thing that nobody disagrees with

<richardschwerdtfeger> markus: we should get together to migrate things from the ePub vocabulary that can be migrated

<richardschwerdtfeger> markus: this would be vanilla without name spaces

<richardschwerdtfeger> cynthia: In addition to that there should be an effort to harmonize with accessibility apis

<richardschwerdtfeger> rich: we agreed this should be part of our process for doing new semantics

<ShaneM> RESOLUTION: It makes sense to migrate many of the ePub vocabulary terms into the ARIA collection as first class citizens.

<richardschwerdtfeger> james: we need to get this list to see what is useful

<richardschwerdtfeger> rich: who will participate in this task force subgroup?

<richardschwerdtfeger> markus: I will put this out to the digital pub interest group

<richardschwerdtfeger> rich: Rich and Janina to participate

<richardschwerdtfeger> jcraig: Markus, how formalized are these right now?

<richardschwerdtfeger> markus: we are taking feedback and we are trying to keep it agile

<richardschwerdtfeger> markus: if you want to do that either through me or the IDPF rep.

<richardschwerdtfeger> jcraig: we could have a yes/no wiki page for this

<richardschwerdtfeger> markus: if this stuff breaks ATs it will not fly as this would impact tools.

<richardschwerdtfeger> rich: I can help with Freedom Scientific and some other ATs

<richardschwerdtfeger> cynthia: we put the whole role string and map it to an aria role

<richardschwerdtfeger> davidbolter: it is more like regressing but not breaking ATs

<richardschwerdtfeger> janina: this is not version 1 from DAISY

<richardschwerdtfeger> matt: we did see issues in Firefox when JAWS was treating log and something else on the table tag

<davidb> i didn't say that :)

<davidb> I hope I said it is *not* like regressing ATs.

<richardschwerdtfeger> matt: did we do multiple role testing

<richardschwerdtfeger> jcraig: we did

<richardschwerdtfeger> jcraig: we had at least two implementations of tests that used more than one value

<richardschwerdtfeger> Shane: I don't think they were aggressively tested. More work is required

<richardschwerdtfeger> jcraig: we did not test for security issues

<richardschwerdtfeger> jcraig: generally speaking, do you like what you heard today

<richardschwerdtfeger> markus: I like this first class citizen approach

<richardschwerdtfeger> makus: name space rolls is something we are looking at

<richardschwerdtfeger> jcraig: the majority of these seem reasonable

<richardschwerdtfeger> jcraig: we have listitem one word

<richardschwerdtfeger> jcraig: we can resolve some of these where you can use some of what exists

<richardschwerdtfeger> cynthia: web document editors could use these

<richardschwerdtfeger> markus: we are working with the open annotation working group to define a common set of bookmarks, highlights, etc.

<richardschwerdtfeger> janina: you can publish these independent of the book itself.

<richardschwerdtfeger> markus: we can currently only do this within one vendors products.

<richardschwerdtfeger> jcraig: it would be valuable to give an epub protocol link to an epub title book. You could link from an HTML web page to a location in someone's book

<jcraig> epub://bookID/locationId/

<richardschwerdtfeger> markus: we do have CFI for that.

<mgylling> http://www.idpf.org/epub/linking/cfi/epub-cfi.html

- DRAFT -

Protocols and Formats Working Group Teleconference
24 Jan 2014

Attendees

Contents

Modularization

dialog/alertdialog (from Bryan)

Dangling issues

Scrubbing ARIA 1.1 Issues and Actions https://www.w3.org/WAI/PF/Group/track/products/17

issue-601

Janina summary is events so far

EPUB

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Protocols and Formats Working Group Teleconference 24 Jan 2014

Attendees

Contents

Modularization

dialog/alertdialog (from Bryan)

Dangling issues

Scrubbing ARIA 1.1 Issues and Actions https://www.w3.org/WAI/PF/Group/track/products/17

issue-601

Janina summary is events so far

EPUB

Summary of Action Items

Scribe.perl diagnostic output

Protocols and Formats Working Group Teleconference
24 Jan 2014