Protocols and Formats Working Group Teleconference -- 26 Oct 2015

<trackbot> Date: 26 October 2015

<jnurthen> scribeNick: jnurthen

JS: as long as we meet the charter requirments we will have the conversation as to what the expectations of memebership of both groups are
... will deal with APA membership stuff on Friday

RS: https://www.w3.org/WAI/PF/wiki/Meetings/TPAC2015/ARIA

ARIA 1.1 Test Harness and Exit Criteria

RS: working to get 1.1 complete in the next year. Trying to get a number of things done for ARIA 2. Also have a number of joint meetings with webapps etc. this afternoon for 2.0
... lets look at the exit criteris

MC: for 1.0 what we did to test the spec was inttoduce a dependency on the UIAG
... the UIAG defiend how aria properties should map to APIs - simply tested that every mapping could be done in 2 places
... had to be 2 different mappings be is 2 user agents using 1 API, 1 user agent using 2APIs or 2 using 2 APIs
... the UIAG had a higher bar that needed 2 mappings to everythign in the guide
... now there are several API mappings
... and ARIA itself divided into modules

<MichaelC> Draft CR Exit Criteria

MC: for 1.1 itself I have drafted some exit criteria for the status section. These will need to be negotiated with management before we go into the CR phase
... what i have said here is

Exit Criteria: The Protocols and Formats Working Group intends to exit the Candidate Recommendation stage and submit this document for consideration as a W3C Proposed Recommendation after documenting interoperable implementability of each feature. For each feature, passing test results in at least two different implementations will be documented.

MC: need to firstly make sure this works for us
... so for role=none we could say the HTML mapping defines how this maps to MSAA and edge supports this. If no one else has done it then could go the SVG mapping and find an implementation there
... the big catch is that the mappings themselves are rec track docs and they must have 2 implementations too
... could say we don;t worry about that for ARIA but need to come up with some wording that says that the mapping guides themselves do not need to meet their exit criteria for aria to meet it
... where gets shaky is that could test against a mapping that wasn't a rec and it then changes. We could argue that it was implementable so aria passes. We are not testing implementations just implementatabiolity
... running up against normative dependencies

MK: all part of the same working group though

MC: aria does not normatively depend on the mapping guides, only the other way round
... we still have to test against the mapping guides they just don't have to go togethr

MK: you can't use it unless they are both implemented

MC: if we don't do it this way then - if eveything can only go to rec together we will never get there
... aria can go to rec whenver even if other things aren't ready for rec

RS: 1st question - we don't have to retest what was in 1.0
... down to new or changed features
... now have a name computation spec which is separate
... going to have to test that

MC: had tested in 1.0 only have to test what has changed
... don't think we need to rerun them unless the test has changed

RS: there are palces - for example for SVG which will have to do its own name computation. I think that is up to SVG to test

MC: I need to look at the name computation spec - it may not be able to exit CR until other things do
... the spec itself has moved name computation out
... there is some host language specific stuff. We didn't test the host language specific stuff as it wasn't relevant to 1.1

RS: SVG are replacing whole steps
... they have to look at the title
... name computation I wouldn't worry about for SVG

MC: going to take a careful writing up to sell it

RS: 1. For ARIA we are not going to test name computation where the host language overrides our name computation

MC: looks like we are in a situation where aria says for the accname AAM and then that says to follow something else. Need to smooth that out

CS: the name AAM could say what is in the string and then the aria one just says that it needs to expose the string

RS: 1 caveat - didnt test UIA last time - we removed it from the spec saying would add it back in

CS: ew need to test UIA as edge doesn't have MSAA
... they were not tested
... the MSAA+UIA Express in IE11 will not change
... need to talk about the webdriver effort for automated testing of APIs

MC: for 1.1 only need to test what has changed
... webdriver spinup have been talking about for years so mustn't have a dependency on it

RS: do you want to test all of UIA for 1.1

CS: I have to test it anyway

RS: Jan at the latest for CR

CS: I will have had to have done it by then anyway

MC: don't want to make extra work. If you have the results in some format I will get them into our DB

<MichaelC> (Not very accessible yet) ARIA timeline planning

RS: 2. we need to test Edge with UIA for the things that didn't work with IE in 1.0
... 3. we do not have to test features in HTML AAM or SVG AAM where they override the ARIA spec for name mappings
... 4. We need to look really hard at the name computation spec to make sure it is understandable by browser vendors - then need to figure what is differnt from 1.0 so we can decide what to test

JB: a few years ago there was an expectation of very rigurous testing of everything. Once we estimated the cost it was too high especially for HTML5
... if you look at the HTML5 testing proposal they decided to exclude stuff that was up and running
... they put out a call for review with the things that they wern't going to test
... they had an exclusion which had a formal review
... you have a few rationale as to what you want to exclude - i suggest you write it down and put it out for review
... hopefully you will then have an estimate as to how much it will cost you
... you want to document what you are going to test and what it will cost to make sure you have something feasible
... if you do the time estimate in advance then it allows you to be realistic as to what you want to exclude
... every group I know who hasn't done a careful study of the amount of work has had serious suprises
... it will force you to be more conservative as to what you want to test
... you could back your exlusion list by saying that if you tested everyhting it would take far too long
... get a well informed proposal as to what you are going to test

RS: logistical issue

JB: you were saying you are going to have to do the testable statements first. you might want to do a pilot first

RS: I am concerned about doing that

CS: the delta is pretty small

RS: some was taxonomy changes to make things clear

MK: some will drive testing changes too

RS: things like mapping of region with label etc.

MC: listing everything which is new or changed won't take too long and testable statements we know how to do now

RS: I would like to have everything ready to go by Jan

MC: need a feature freeze

RS: going to try to get closer there this week
... web components need somethign to ref content etc. so might need a 1.2....

JD: wanted some clarification on the status of the document section.
... do you have a reason to believe that we are in danger of core aam not being sufficient

MC: don't have data either way. not so worried about core but more about technology specific mappings

JD: talking about 1.1 through CR talking about core not the modules
... what I am wondering is that - if everyone buys it - so we really need the any any anys

MC: ARIA will depend on the core and accname mappings and in 1.0 also needed the html mappings

RS: need to make sure that what we have will work with AT

<Zakim> joanmarie, you wanted to ask Michael if he has concrete reasons to believe ARIA 1.1 cannot exit successfully based on Core AAM.

MK: don't remember from 1.0 - when are browser devs and AT vendors going to be asked to look at 1.1 - when do we recruit them and say these things are ready for you
... can't actually do the testing until they have actually done it

MC: we have excluded ATs from our requirements in the past
... in terms of the right time to implement. sooner rather than later review is better from ATs
... would hate AT to tell us going to rec that things aren't going to work right

CS: think let off the hook to easy

MC: need to have said we have solicited wide review b4 CR

RS: can send to AT vendors at feature freeze

MC: "pseudo LC"

CS: will be getting feedback from MSFT and AAPL

RS: know NVDA have been working with mozilla

MK: Jamie was very concerned about a number of features
... they only have 2 guys
... at the right time we can talk about there concerns
... I would be happy to volunteer to work with AT vendors
... I haven't started conversations with AI Squared

<MichaelC_> DRAFT ARIA project plan

MC: as a slight tangent - project plan. A pseudo gantt chart showing how all our specs effect each other
... should go through this at another time

<MarkS> +1 to MichaelC_'s GANTT chart

RS: how are going to write testcases for everything
... will be working with the SVG team - should have a meeting with Steve and group of editors to see how we can help them

CS: we have a dependency on them

JW: need to see if there are 2 implementations on each OS?

RS: no for each feature there need to be 2 not on each OS

CS: there are 3 APIs on windows and different browers use different ones so this is not achievable

MC: the mappings are a different thing

CS: they use different APIs

JW: thinking about the same APIs

CS: there is only 1 API on apple

RS: Chrome too

<cyns> scribenick: cyns

JF: I have some people at dq who may be able to help write tests

RS: do they know enough about api mappings?

JF: I think so

MC: John Gunderson has testers too

CS: I can do a UIA training with your people

JB: It would be great get a community of people who know how to do testing and create a pool of people

RS: test the web forward too
... need people to work with steve and jason on html testing too

JB: Talk to John F about how he has done internal recruiting

RS: I'm hoping by next year we have aria, html and svg all at the same level so we can all be moving forward together.
... Is msft looking at svg?

CS: it's on the backlog, but farther down

RS: MC, please show project management plan

MC: still needs some work, including making it more accessible
... covers entire charter period
... anything we do to push ARIA out later will impact start of other work, like graphics ARIA

RS: Since SVG hasn't been implmented consistently across platforms, and SVG is trying to go out soon, first drop of Graphics ARIA will be very small. Otherwise it is too much for browsers. That might let the graphics module to come in a lot earlier

MC: if we move that earlier, it will overlap with other CR, so we should think about the consequences to our work flow

tzviya: dpub date is past

MC: want to go through and validate these dates afeter tpac

RS: I think dpub is ready to send out for tpac. why not push it out with all the other specs
... SVG-AAM expecting to do a heartbeat next month

MC: need to look at everything that is publishing next month and making sure it's doable

RS: need to say something about introductions and abstracts of svg 2 in ARIA 1.1 spec.

MC: need to do lightly, and not introduce a dependency

<richardschwerdtfeger> Break Time

<JF> Scribe: JF

RS: about to look at low-level issues

Action 1361

<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/actions/1361

Matt has a proposal he wishes to share

<mck> http://rawgit.com/w3c/aria/mck_applicationRole/aria/aria.html#application

will look at latest text

MCK: application role is...

different in a couple of ways

first, application is now a structure, before they had a wording of landmark region

which was discussed previously and gained support

second paragraph is to make clear purpose of application role

somethng to be used when there is not an existing widget

aka roll-our-yown widget

then you could use applcation-role

RS: slightly confused - is it a structural role in the document, but is it a widget?

MCK: it could be. there is no need to use application role all of the time

the reason to use that is if you were creating a new type of widget

JW: you are saying it's a structural role, yet it doesn't seem to be a structural component - that it's a wdget instead

MCK: the point is to allow for new widget - therer is an example in the proposal

Rich reading example aloud

<jnurthen> if anyone prefers the diff view it is here - https://github.com/w3c/aria/commit/7593ebf363a11c7bc78a1c08dbfea76a31f7a77f

MCK: this was a new example to replace prior example

the point is to tell people the way application role has been used to date is taht it has been abused and over-use - creating more problems than solutions

RS: it's an interaction area of a document taht has no existing role?

MCK correct

JW: concerned about having a catch-all attribute

MCK: we have that today, the point is that applicationroles today

where we have a landmark region that then becomes an application, and passes keyboard control to the Ua

<jnurthen> strike that previous URI - https://github.com/w3c/aria/compare/mck_applicationRole

RS: concern is taht somebody creates a custom widget and then makes it an application

JW: shared concern

RS: what we could say

JN: we need a way to solve the roblem

when there is no aria role to do what it does, you need to say that the application is responsible for keyboard control, voicing context of focused items, etc.

JN: how is less important

RS: concern taht there is no semantics involved

MCK: there is one bug on an aria- interactive thing - it is quite vague

RS: asks JN where it is being used

JN: we've used it on grids where we needed to create a custom grid widget, SVG charts (keyboard interactive), and a few others

RS: for SVG, we have keyboard interaction s going in

JN: we need to tell the user more than just tab through

RS: suggesting we just declare this is an interactive area, don't steal keys

MCK: see this as a bridge to aria 2.0

RS: concern about calling it an application - it's a widget

MCK: getting hung up on the term application - and traditional definition

this isn't what we are talking about

when James uses it today, it's a control in an application - never applied to an entire page

in the grid example, we don't use role=grid, but instead the custom congtrol

JN: it's an author defined swwidget

RS; an authro defined custom widget

MCK: not advocating that this is the end-all and be-all, looking to plug a bucket

people make a date-picker, and they wrap it with a role=application

JN: not perhaps the best example, that may be valid some times

MCK: it could be, but believe this way would be better

you could place this directly on the element iteself

JN: how, can only have single role

MCK: could have a role description

JN: issue is that applications cannot take aria-activedecendent for example

as a direct child - creates an extra level in heirarchy

MCK: right, this way the structure does not have to be controled by AT

JN: prefer an aria interactive approach

retains the semantics, and then just add something to it

RS: that is my concern as well

JN: this would be for more document semantics - i.e interactive lists

MCK: problem with taking a staic role and giving permission to turn a static role into interactive

feel this is straying from the point

MCK: goal: if I cannot deprecate application, then find a way to use it sanely

RS: 2 things attempted: 1- ensure taht there is no landmark

2- concerned when looking at SVG, don't want to call the whole thing an application

JN: if somebody wants this to be a landmark, then add taht

RS: if you were to place this on a list, you would lose the structural value

JW: issue around distinguish between browse mode and interaction mode

discussion around SRs tath don't have a browse mode - seems most do

JW: the problem is not browsing, but with key-strokes

RS: in ARIA 2 there will be author defined widgets
... concerned about application - application is a container of some sort

so for example, don't want to loose list semantics, but you want to also declare it is interactive

MCK: it's up to the AT to expose semantics when in focus mode

RS; you put role=application, then put inside it you put grid?

JN: no, that isn't the issue
... complex grids lack the ability to define the complexity

too much reliance of aria-owned, and the grid model, so we are forced to hand-code stuff

would use row if it worked properly

if there is a simple grid, we use grid, but for more complex grids we use application model

MCK: this is not a long term solution

RS; want to avoid having authors create a custom thing and then wrap it with application

JN: documentation on how to interct is an important requirement here

MCK: is the idea to document additonal focusable items taht may not be aria widgets

RS: that the behavior is different

MCK: the thing that is different is taht the interactivity is non-standard

RS: will switch to James N's discussion, while Matt works on wording

<richardschwerdtfeger> scribeNick: Rich

<jnurthen> Indicates that an <a>element</a> is the primary action which is intended to occur on the webpage or the section of the webpage. Generally, this would only be present if there is a different visual indication for the primary action.

<jnurthen> A keyboard user would generally activate the primary action through use of the enter key, even if they are not focussed on the current control. Typically this is used for features such as the Next button in a Wizard, The Ok button in a dialog, or the Search action in a Search region.

<jnurthen> Authors should ensure that there is only one primary action per distinct region of a page.

Primary button

<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/issues/624

<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/actions/1736

<richardschwerdtfeger> Rich: we should not use the term region

<richardschwerdtfeger> Joanie: area would be a more appropriate term

<richardschwerdtfeger> Rich: we need to define in the context of what?

<richardschwerdtfeger> Jason: we need to know what keyboard interaction in a series of widgets

<richardschwerdtfeger> James: We need to indicate for a region as the primary action for that region

<jessebeach> I'd like to get a question in here for James

<richardschwerdtfeger> Jason: should we have an IDREF and have selectors later

<richardschwerdtfeger> James: we may not know what the component of the container when it is being rendereed

<richardschwerdtfeger> jessebeach: We have interactive areas wher there is no interactive element

<richardschwerdtfeger> rich: So, would you put this on the container

<richardschwerdtfeger> Rich: I am concerned as to whether it is going to cause someone to purchase something

<richardschwerdtfeger> James: I don’t think that is for ARIA to solve

<richardschwerdtfeger> Rich: would this only be on buttons?

<richardschwerdtfeger> JamesN: this might be on links

<richardschwerdtfeger> jason: So if you were tryint to delimate the region. How would you know what IDREF to bind it too?

<richardschwerdtfeger> JamesN: many frameworks will not know

<richardschwerdtfeger> Rich: could this be limited to the context of a form?

<richardschwerdtfeger> JamesN: Form or application

<richardschwerdtfeger> Joanie: The reason I care about this is I assume the screen reader user wants to know what the default action is

<richardschwerdtfeger> Matt: there is no screen reader user that makes intelligent use of this functionality

<richardschwerdtfeger> Matt: JAWS has a specific command to ask what the default button is

<richardschwerdtfeger> Matt: an assistive technology could make use of this

<richardschwerdtfeger> Jason: VoiceOver on OS 10 will tell you what the primary button is

<richardschwerdtfeger> Rich: Could we limit this to a Form Context for 1.1?

<richardschwerdtfeger> Matt: what about landmark?

<richardschwerdtfeger> Rich: Can we limit to the nearest immediate landmark?

<richardschwerdtfeger> Cynthia: what about Dialog?

<richardschwerdtfeger> Rich: yes, we would want it for Dialog

<richardschwerdtfeger> James: it would be good if there were not landmarks to appy the context to the page

<richardschwerdtfeger> James: if the UI designer has done their job it would be obvious.

<richardschwerdtfeger> matt: we are trying to spec. a way for an AT to determine the context based on what the author has designed visually

<richardschwerdtfeger> matt: unless we say the author must do something …

<richardschwerdtfeger> MarkS: I don’t think we should have this on link

<richardschwerdtfeger> Rich: I don’t like it on links

<richardschwerdtfeger> Proposal: We will call it aria-primaryaction and it will be limited for use on buttons with landmark containers

<jnurthen> or dialog

<richardschwerdtfeger> Proposal: We will call it aria-primaryaction and it will be limited for use on buttons with landmark containers or dialog containers. If it is placed on a button that is not within a landmark or dialog container it is considered to be an error.

<richardschwerdtfeger> Resolution: We will call it aria-primaryaction and it will be limited for use on buttons within landmark containers or dialog containers. If it is placed on a button that is not within a landmark or dialog container it is considered to be an error.

<richardschwerdtfeger> RESOLUTION: We will call it aria-primaryaction and it will be limited for use on buttons within landmark containers or dialog containers. If it is placed on a button that is not within a landmark or dialog container it is considered to be an error.

<MarkS> scribenick: MarkS

ARIA 2.0

MH: we're working in two standards spaces. ETS does tests. We work with IMS Global as well as W3C. IMS has a standard for testing.
... test vendors use different ways they implement test items.
... from an accessibility perspective it varies from zero to pretty good
... looking at how we can provide a single model to implement QTI in HTML
... can we create custom elements or web components to do this.
... actual implementation is handled with Javascript. All a11y information is there
... prototypes we've built so far are pretty good. with aria-roledescription it gets better

RS: would you want specific roles for these?
... probably with descriptions is AT is not doing anything with those

MK: what is the advantage from a screen reader users perspective

MH: you have extra verbiage to improve the experience.
... additional keyboard interaction models

MK: so it exposes additional instructions to the user for the various multiple choice options for instance
... correct

JW: order interaction item: reorder a list. those are complicated as far as user interface.

CS: and this adds cognitive load for all users.

MK: the fraction item model. exposing a pizza to the student who has to select sides. multiple ways to do that, confusing to users. like to be able to expose information to the user up front.
... giving more meaningful name to the control.
... the important thing is for roledescription, authors should never use it unless there is some other way of communicating the interaction model.

CS: we use something like this for "kindof" relationships
... default string for list item is different than what ARIA would say
... i can see roledescription being used that way
... there is room for developer error and abuse here

RS: you still are conveying the interaction model

MH: correct

RS: might be that we have the AT convey the interaction model

CS: that is what we do

MH: even overriding something like checked unchecked with on or off
... many of our assessments are based on real world activities and shouldn't be based on GUI paradigms
... lots of science exercises. What is in this graduated cylinder, operate this valve, tec.
... want to create new objects that are not abstractions.

RS: you want a state description...

CS: the way this works in UIA, make a group of checkboxes, but you would change a string that is spoken as its type. pizza, pizza slice, selected
... there are limitations, do you want to override selected? UIA can't do that.

MK: you want to make the widget UI language, correspond to the surrounding vocabulary, language of instruction.

RS: an author defined user interaction method

JW: with regard to web components. other uses/applications. in the context of ARIA, we have to make sure this work applies to more general work as well.

MH: familiar with the Diagram Center work?
... the content model for associating description of image
... we need this capability for assessments.
... what about delivery?
... we took this model and applied it to web components.
... audio/video element, controls attribute. it applies own UI. imagined this for images as well.
... if you choose to roll your own UI, you can do this.
... we have a working mockup.
... i can show later.
... can be used to solve longdesc issue.

Joint meeting with Web Platform

<MichaelC> Minuted at http://www.w3.org/2015/10/21-webapps-minutes.html#item08

<joanie> scribe: joanie

ARIA 2.0 and web components

MH: The example that got us originally looking at web components, back before we had longdesc. We looked at the diagram model.
... This (on screen) is an HTML page with diagram content model, with buttons on top with javascript to toggle various items on/off.
... (Reads from screen. Link: https://github.com/mhakkinen/dg-content)
... In operation, you have an image of two surveyors measuring distance between shore and river.
... You can toggle the description.

RS: How does this manifest itself as a web component?

MH: (Brings up example code on screen)

RS: So you defined a custom element, and that gets expanded into.... ?

MH: Shawdow DOM.

RS: Divs and spans?

MH: (Explains, pointing out aspects of code on screen)
... We can define the behavior (e.g. show and hide) of the custom elements.

RS: How do you envision ARIA being added here?

MH: Polymer is just what Google provides as a way to declare custom elements.
... What's missing from the ARIA perspective? Identifying a label that's external to an element.
... We're defining new kinds of widgets that don't have any kind of ARIA role presently.
... How can we expose that to ATs?

RS: And roledescription solves part of that?

MH: In the short term.

RS: Regarding custom states, each platform has events handling. So we need a way to fire custom states on the platform. And also how to expose the states to users.
... That would require some platform accessibility API additions.

MH: Looking at all the different kinds of simulated environments in the educational assessment space, we need a means to expose these sorts of things in a clear manner.

MK: What screen reader vendors are able to do with states are prety limited.
... Unless those basic communications are able to be changed, you wouldn't be able to define new states.

RS: If you have a new state, you would have to know the old and new value.

MK: And if they are custom states, you need to know even more.

MK+RS: And then there's localization.

MK: Regarding localization, if there are things like posinset and setsize, the author would need to provide singular and plural form of the role.
... Because roledescriptions can have spaces, we couldn't treat them as a list of strings to solve the plural problem.

RS: Getting back to your example Mark, we could add ARIA to it. But what would you need?

(Group on if/why web components are different with respect to ARIA)

CS: Because they are resuable, if you make a bad component, it's worse.

RS: So are you expanding HTML elements?

Group: Could it be SVG?

JG+MH: Yes.

JG: When you create a web component in a custom element, you specify a protoype. What happens to the role? Is it inherited from the HTML element?
... Are you using JavaScript to define it? If we're going to make it easier to define ARIA roles, states, and properties....
... Just before TPAC, Dominic raised example of web component with child in the shadow DOM, you cannot reference it via IDREF because of the barrier between the two.

RS: Is it possible to solve this via selector?

MC: CSS selectors has a way to specify an ID.
... If you try to mix an ID with a non-ID, it wouldn't know what to do.

RS: We take a basic ID today; there's no hash.

MC: Ours is an idref. If we wanted something that might or might not be an id, we need a means to express that.

RS: So we need a way to make it uniquely a selector.

JN: We don't want more attributes.

RS: We'll have to come up with a syntax for that.

JN: I think there have been proposals for that.

MC: I don't think we have to compe up with a syntax; I think we have to choose one.
... We might choose it based on what's already implemented in browsers.

RS: Do we need to have selectors earlier rather than later?

MC: I'd do that in a major release like ARIA 2.0.

Group: We could do a point release or an extension.

<jessebeach> +q

CS: If it's in a draft and no one is complaining and browsers are implementing it....

JB: I wasn't understanding the discussion about selectors and it seems like it might be dangerous because you can select more than one.

MC: A single ID in a selector would select only one thing. I think Jesse is concerned about accidentally selecting more than one thing.

<mhakkinen> I have the DIAGRAMMAR example that was shown on github: https://github.com/mhakkinen/dg-content

JB: Attribute selectors, element selectors....

MC: We might need to choose a subset of a selector language and/or have error handling.

MK: Do we have any attributes that must be restricted to one?

Group: activedescendant.

<kurosawa> http://www.w3.org/TR/dom/#dom-parentnode-queryselector

<kurosawa> > The querySelector(selectors) method must return the first result of running scope-match a selectors string selectors against the context object, and null if the result is an empty list otherwise.

JW: The DOM has queryselector and queryselectall.
... QuerySelector would take only the first.

<MichaelC> Selectors Level 4

<MichaelC> (intended to harmonize CSS and XPath functionality)

<MichaelC> issue-653?

<trackbot> issue-653 -- Need to support selectors in ARIA relationships -- open

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

JW: Is there a syntax in any of the selector proposals to select what is inside the shadow DOM from the outside?

MC: The level 4 spec has only two profiles now, fast and complete. But I think we could make a case for a profile to handle this.

JW: Multiple idrefs are in aria-labelled by. So being able to select multiple items is a good thing.

JB: But you need to know the order.

MC: For attributes, there is a defined order.

JN: I don't think the CSS spec defines an order.

MC: I just assumed DOM order.
... For automatic numbering, it would matter. So CSS probably already has a solution.

MK: We built a component called APIP alternates.

MH: There's displayed text, spoken text, and braille text.

RS: So you want modality?

MH: Yes.
... We have a pop-up menu.

RS: How would you specify these as attributes?

s/MK: We have/MH: We have/

JG: We don't have an ability to send one string to speech output and another string to braille output.

MH: And this is a requirement of the assessments.

RS: So you want this not just for labels, but also for descriptions?

MH: Good question. I think it's just a one-for-one replacement for the content -- whatver you have wrapped.

RS: So this is the text content itself?

MH: Yes. But why stop there?

<MarkS> scribenick: MarkS

RS: you want multi-modal customization

scribe: what about attributes?

MH: just text content
... we're not doing abbreviations, we are doing replacements.

MK: the new text role does replacement, doesn't it?
... would that work in this context?
... IMHO text is defined way too broadly, and may permit this

JW: but it won't differentiate based on modality

<MichaelC> ¨gargantuanly dangerous¨

MK: no

<joanie> https://rawgit.com/w3c/aria/master/aria/aria.html#text

JW: that is what we need.

<mhakkinen> The following is a math expression:

<mhakkinen> <apip-spoken id="s1" exclude="false">Twelve times ex squared, plus seven times ex times why, minus ten times why squared</apip-spoken>

MH: here is an example

[MH demo]

MH: this example demonstrates a math expression that was displayed using visual display. then we have alternates, display, spoken and braille
... spoken gets sent to AT
... braille gets sent to AT
... you want nemeth on braille display
... and verbatim description for speech
... formatted HTML for visual display

MK: when you think about spoken, for a screen reader, screen readers make sounds, so maybe that is how you want it to sound, you want the presentation that is on the screen... trying to understand

MH: we want to use SSML, to control pronunciation, but we don't have that. This was an attempt at solving that.
... this is a hack, but it could work when required.

MK: even screen readers do not natively support this.

MH: when we've asked vendors fi they will support SSML so we don't have to do this, they say, we have our own lexicons and rules for this. But we don't want to author pronunciation tools for each screen reader

MK: they don't develop their own synthesizer, who defines this.

JN: I sometimes get developers who request that their company name for instance gets pronounced directly.
... and I tell them not to do that.

CS: what about web speech api?

RS: yes, but they you have to figure out...

MH: we filed bugs with Apple and Google about supporting SSML

LW: back to the CSS query selector question. Do we have any idea when this property would need to resolve?
... when it needs to come into existence

JS: we haven't scoped it all the way.

MC: we haven't decided if we want the feature set, and not sure what we need to ask for when we do

<mck> scribe: matt_king

<MichaelC> scribeNick: mck

proliferation of ARIA attributes

JF: we have 61 properties and attributes

DPUB and COGA moving to intro more.

JF: concerned about author feteague
... Is this the right way to move forward?
... The functionality of aria-destination, which is metadate, could be possibly with rel.

MC: When using attribute , do you mean state, property, or role?

<Zakim> MichaelC, you wanted to different roles from state/property attributes

JF: only states and properties.

IH: DPUB is not contributing to this problem; we are introducing only roles at this point.

<Zakim> tzviya, you wanted to clarify a few points

JF: WRT to COGA, they are looking primarily for styling as I understand it.

Browser vendors do not think they should be making changes to the visual interface.

JF: I keep seeing proposals to bring in more and more and I am questioning if that is the right thing to do.

JN: I think role proliferation is worse than state/prop proliferation. I would rather see more states/props then roles.

If something starts with ARIA, browser devs are making the choice not do anything with it.

Janina: Charles is saying ARIA is only be used for/by AT

JF: That is a challenge to the browser devs, not a statement of how it should be.

RS: ARIA was built based on op sys apis ... that grew over years.

If you create UI based on common elements, why not trigger browser behavior off of them.

RS: if you have checked on a checkbox, why not trigger off of that attribute in the UA.
... It is stupid for authros to add ARIA after you have created all the UI. Better to use the ARIA as one of the way to drive presentation and behavior.

JF: not saying we do not want more. But, I am saying we need to be more thoughtful about it and exercise constrait.

RS: You want us to think more broadly and think of a way to solve the general problem rather than specific.

IH: example please?

RS: With role link, we could have subrole to say that a link is link to a glossary ref instead of having aria-destination do that. This would allow subrole, which could used to solve other problems in addition to the aria-destination problem.
... Secondary roles are fallback, not additinal roles. But, if we had subrole, that could be additional info.
... basic idea is that subrole could solve multiple problems whereas aria-destination can solve only one.

Janina: DPUB is fairly mature because it is brining thinking that has developed over many years.

Whereas COGA is bran new, blue sky thinkig. It is not in the same place as DPUB.

<Zakim> MichaelC, you wanted to talk about vocabularies, annotations, attribute values, etc. and to say ARIA is and should remain a self-contained technology and to say an attribute is an

MC: An attrib is an attrib. If feature is needed, it doesn't matter if it is provided by ARIA or another technology.
... States and properties relate to the roles in ARIA. They are not independent of ARIA roles.
... We chould still consider other solutions such as rel. We should not necessarily assume ARIA is the way to solve all problems.

JF: I think you have summed up what we need to do quite nicely.

Let's make sure we step back and solve problems architecturally.

<Zakim> JF, you wanted to comment on Michaels comment regarding role taking multiple values

JF: the role can take multiple values. Browser goes down the list and takes the first one it recognized; it does not permit one element to have multiple roles.

JW: We need to see where there are opportunites to have features in host languages where possible.
... ARIA is designed to fill gaps.
... This WG needs to have close relationships with the other WG so that we do not fill gaps that could be adressed better in other places.
... In some places ARIA can lead the way, but in doing so, we could create things thatbecome unnecessary at a later time.
... Another thing we need to cover in the ARIA 2.0 discussion is the extensibility of ARiA.
... A careful discussion of ext mechanisms could solve a broader arrya of problems.

When you have a11y specific tech that comes more and more complex we can solve, in some cases with education, but in some cases there may be a technical solution.

Complex problem and the complex solution may be required.

IH: The discussion of rel ... we have that on the agenda?

TS: it is on DPUB agenda.

IH: it is not a DPUB issue.
... The problem with using rel attrib is that RDFA uses it in its own purposes.

TS: if the same attrib is used for more than one purpose, that is recipe for disaster.

There is a group today using DPUB attribs for scientific publishig.

RS: so rel may not fit as a solution for aria-destination.

but we might be able to do it with a subrole

JN: why do we have to map it though?
... We do have role of link that is mapped, why do we need to map it.

Why do we need to map rel to a a11y api?

CS: we could use localized role description
... is this a 1.1 or 2.0 issue?

We could solve this with patterns.

Janina: we need a 1.1 time frame solution.

CS: If we add subrole now, do we solve only some of the problem and create a mess.

RS: For each type of role we have, we should have a pattern instead of just having this kb interface def
... should be done in a device independent way

CS: in 2.0 timeframe, if we had a link pattern, it could have a link type with a bunch of constants.

CM: What is the actual nature of the way RDFA uses rel?
... In actual implementations, does that create a problem.

IH: you may want to people at schema.org to get the answer to that.

RS: Problems with rel ...1. it is not mapped. 2. it is not avail in SVG.

<ivan> RDFa will generate triples including a subject; if the only value appearing in a document is a specific and ARIA specific @rel value, then the generated triple may be meaningless. This may create problems for applications relying on the output of an RDFa processor.

CM: One of the issues with not using rel is that we are setting 2 competing patterns for the web. People will have to choose between the a11y path or another.
... looking at standard html vs aria, the standard html path mainstreams it faster.

CM; also forces others to think about a11y issues.

CM: I will go and talk to schema.org people to find of the random tripples cause a real problem or just get thrown away.

Schema.org is used on about a 3rd of all domains on the web.

CM: One thing we learned painfully in schema, if people do not understand fine distinctions, they get them wrong.

If you get a lot of bad usage, you have to recognize and treat it as if it were right.

CM: So creating fine distinctions has the effect of creating no distinction.
... It is not complicated to apply rel to an element with role link.
... You can have 2 valid rel values and use them both.

So where you have things that have 2 valid subtypes, you can put in both.

RS: Can you look into this by friday?

CM: I can, but I don't know if possible by fri.

RS: There are a lot of things in SVG where we point to the html spec and may be able to do the same thing with this.

rrsagent: make minutes

TS: Not understanding how a subrole is different from a subclass?

RS: It would be another property, eg aria-subrole

<trackbot> Meeting: Protocols and Formats Working Group Teleconference

<trackbot> Date: 26 October 2015

<richardschwerdtfeger> chair: Rich

<richardschwerdtfeger> Meeting: WAI-ARIA Working Group

<MichaelC> agenda: https://www.w3.org/WAI/PF/wiki/Meetings/TPAC2015/ARIA

- DRAFT -

Protocols and Formats Working Group Teleconference

26 Oct 2015

Attendees

Contents