Protocols and Formats Working Group Teleconference -- 31 Oct 2014

<trackbot> Date: 31 October 2014

<MichaelC> Minutes from yesterday

<bgaraventa1979> would it be alright if I dialed in?

<bgaraventa1979> please do, it rang but no one on the other end

<ShaneM_> ScribeNick: ShaneM_

CSS Overview

JS: Our desire is to understand how CSS is thinking about CSS and its connection to the complex ox of specs

<MichaelC> meeting: PF TPAC 2014 Face to Face DAy 2

<MichaelC> meeting: PF TPAC 2014 Face to Face Day 2

JS: There are probably some questions from us. But maybe CSS people could talk about context.

<bgaraventa1979> is the number for muting my line 61?

RS: What we are seeing is a couple of things. We have the ability to inject content into a page with CSS.

<bgaraventa1979> thnaks

RS: there are a lot of modules and we are unsure how they all hook together.
... A11Y relies on the DOM. If CSS can inject things then it can confuse the A11Y efforts.
... second we are looking at flexbox. flexbox changes the flow of the page.
... navigation via keyboard may not follow the flow of the flexbox
... should flexbox change the keyboard navigation?

FE: If someone uses angular, for example, to change things and display gets changed to none for some things, then there could be issues. are there events?

JC: There are platform events.

astearns: The question is how does angular change the display mode. There are mutation events.

JC: No one uses those though. BUt the rendering engine will do something sensible and raise events.

FE: It is not clear that things always get done correctly.

JC: Some changes might not be obviosly important to the engine - like changing a class.
... most of the A11Y tools work with the view layer.
... The text content that is generated by CSS is available to the rendering engine so it is available to AT on most platforms.
... And it is accessible to the DOM.
... we have asked for alt on injected content, and it was provided.
... for example injecting a black right pointing triangle. need an alternate description.
... there are ways per language to provide list markers text. localized alt text for them.

JN: why not use the same mechanism?

JC: because it is challenging. But it works.

<zcorpan> where is the css/pf joint meeting?

astearns: There is alternate text? That's news to me.

JC: Tab has promised to put it into CSS4.

Bert: Well - that's not the same as accepted but okay.

astearns: probably put into pseudo elements draft.

JC: Flexbox - added text to clarify that it does not effect the order of speech. Not sure it addresses all the issues that we have.

<astearns> flexbox section: http://dev.w3.org/csswg/css-flexbox/#order-accessibility

astearns: It is an entire section about it.

RS: Are you involved in all the modules JC?

JC: I am not, but it is more effective to do the work within CSS than from without?

RS: Well - but there are a lot of modules and how can we find out when things are important to A11Y?
... also, about testing, is there an API that can help us?

Bert: Not yet.

JC: There might be a way to have CSS generated content in the DOM. WebApps discussed it this week.

<Zakim> joanie, you wanted to say it might not be CSS's issue, but there are issues bigger than ATs and a11y API needs

joanie: This is not just about ATs. JC just mentioned selection.
... if someone uses CSS generated content to mark something important - it is not always exposed in the user agent.
... I can't use the find operation to search for it.

<astearns> +1

Bert: It is our problem. The information needs to be in the DOM. There is a new module for DOM extensions. Not yet on TR

<jcraig> generated content alt property in CSS4: http://lists.w3.org/Archives/Public/www-style/2012Nov/0319.html

<Bert> pseudo-elements module

<jcraig> currently implemented as -webkit-alt in WebKit: https://bugs.webkit.org/show_bug.cgi?id=120188

joanie: the selection problem might be solved by this as well.
... some screen readers do not control the navigation. Because there is good native support for navigation.
... for example a cursor down will not land on generated content. WebKit GTK caret navigation is used.

JC: If keyboard access can't get to it then the screen reader won't see it.
... VoiceOver has multiple mavigation methods, but it would have missed it too.

FE: Transparency in colors. get computed style does not tell you what the actual color is if there is transparency.
... calculating contrast values is tricky in this case because the value is not in there.

astearns: we are adding blend modes that will make this even more complex

fesch: isn't transparency new in CSS?

Bert: No - there are just changes that are being made with extensions.

JN: no difference with backgrounds and gradients

fesch: but we need to do SOMETHING right?

JN: build better test tools.

JC: Media Controls - there is a reduce transparency and reduce motion setting on some Apple platforms now.
... a distinction for a preference related media feature. allows the page to know things that the user prefers
... then the media author can query those preferences and possibly modify their output
... puts the onus on the author

astearns: maybe not. you could do something by default as an author. user style sheet

JC: well, you could effect the default style sheet too. But do you want to do it across the board?
... there are a lot of places where motion might help the user.
... but it is important to let users make those choices.
... it should not be across the board.

astearns: back to the actual display color problem. there are things that complicate the actual displayed color.
... you are going to have to calculate it harder.
... we cannot expose colors for various security reasons (like visited links).

<Zakim> jcraig, you wanted to say it would be nice to declare: from element, get pesudo-elements, and from those pseudo-elements, get the content text or object nodes

JN: visited link color is a foreground issue. we are talking about background stuff.

Cyns: But background might need to effect foreground for contrast reasons.

JC: might need scripting access

astearns: It should be covered in the pseudo elements draft.

JC: will this solve your problem joanie?

joanie: no - but I am not convinced this is a CSS issue. I want to be able to have a caret in a pseudo-element.
... it is probably a rendering engine issue.

JC: Yes - rendering engine.

Cyns: Your user doesn't know whether the text is a pseudo element or not

RS: We need it for A11Y test tools. If the information is not exposed, we can't test it.

JC: That's not enough of a reason to add a DOM API.

RS: We need this stuff to make it possible for testing.

JC: We have platform tools to test this now.

RS: We are testing web content... We want to test through the DOM

JN: It is possible to do this.

JC: the testing tool aspect is a benefit, not a reason. pseudo elements and its DOM will be a help.

(quick aside while we reorganize the room)

RS: The image and alt text is not necessarily exposed to the A11Y API
... developers want to use the latest, greatest thing.
... it is not yet in the browsers for the A11Y tree.

JC: What's the alternative? If you only have backwards-compatility, you never make any progress forward.

RS: We get the objects in the CSS object tree.

JN: If the browser is not mapping it, then no one can use it, so why are you shipping it?

JC: The issue is that the browser supports it but the A11Y API / tree may not yet expose it.

RS: described the way that A11Y testing is done.
... development teams are testing to content

JN: It should be in the A11Y Tree.

Cyns: If it doesn't work in AT then it doesn't pass accessibility.

JC: let's get back to the CSS part of this discussion
... Rich is concerned that new CSS features are not getting into the A11Y tree as quickly as they are into the rendering engine.

JS: I heard that he needs to be able to rely upon finding when feature are used.

JC: WebKit is exposing this information in the native web dev tools. Chrome has committed to do this in a future release. Redirect some of your developers do finding the information using the platform level tools.

Cyns: You could add a WCAG test to check to see if there are unsupported things in use from the CSS.

RS: We are not parsing the CSS. Are you?

JN: You can look at the CSS object tree.

Cyns: Generated text is important to A11Y. I don't care if it is in the DOM or not. I care that ctrl-f can find it, and that I can copy and paste it. The user does not know if it is generated.

<mhakkinen> +1 to Cyns

joanie: Is there any use case where CSS generated content should not be selectable / navigable? Or is it something that happened?

Bert: Historically the CSS generated content was decorative and you might not want to be in the selectable text.

Cyns: list styles are an example of something where if should be exposed.

<astearns> (just sent a note to www-style about adding selection and search requirements to the content property)

<Zakim> jcraig, you wanted to mention navindex and nth-fragment() and to mention user-selectable (?)

fesch: generated stuff could be help - a picture that pops up. Not accessible.

JC: navindex is problematic

<kurosawa> nav-index http://dev.w3.org/csswg/css-ui/#keyboard

Bert: this is in the UI module now

JC: talk about how to have navindex integrate better

Simon: this is known in the HTML group. They are looking into possibly scoping tabindex.

Cyns: Having something in CSS is good as well.

Matt: Please don't do anything like requiring 'ctrl-tab'. Keep it simple

Cyns: Why?

JC: because the user would not expect it.

fesch: how do you get out of a sub-area then?

JC: you navigate off the end?

Matt: Trapping is a separate topic (e.g., in an overlay)

<Zakim> jcraig, you wanted to mention nth-fragment() and to mention user-selectable (?)

JC: glad to hear navindex scoping is being worked on.
... user select none - the ability to disable user selection via CSS

<kurosawa> https://developer.mozilla.org/en-US/docs/Web/CSS/user-select

Bert: I don't know what this is

It is not a standard property. It is not in any W3C specification.

Simon: we need to specify it if everyone implements it.

JC: If there is a need for this it should be in the DOM

Cyns: is Outline: none on the list? It is a WCAG failure.

JC: it could be handled through an event. If you are tabbing you want to be able to see something via focus. If you are mouse clicking then you might want to do something.
... it could be a vlaidation error if there isn't some other change when outline is set to none.

Cyns: for any product that we ship we would consider it a hard fail if outline is set to none

JC: On windows you could just handle it system-wide overriding the author intent if the user wanted it.
... was that actionable enough for CSS?

<jcraig> button { outline: 0; }

Bert: Not quite...

<jcraig> button:focus { border-color: red; }

<ShaneM> ScribeNick: ShaneM

JC: CSS through validation could throw an error if there was no exposed outline on a focusable element after a rendering change
... authoring requirement

(clarified that this is about people who cannot use mice or prefer to use keyboard access)

Cyns: Work around it in Windows by turning on narrator and then turn off the sound.

JC: User style sheets are not really used out there.

JN: Specificity of styles might make it very difficult for a user style sheet to override something.

JC: You could use ***** outline !important

JN: Not if there is an ID related style.

???: cascade level beats specificity. User style sheets should win.

<bgaraventa1979> +q, would like to bring up css content binding mechanisms to focusable elements when appropriate

<scribe> ACTION: JamesN to try to find an example where user style sheet cannot override author intent [recorded in http://www.w3.org/2014/10/31-pf-minutes.html#action01]

<trackbot> Created ACTION-1522 - Try to find an example where user style sheet cannot override author intent [on James Nurthen - due 2014-11-07].

Simon: It might be difficult to tell from a validation perspective if a focusable item can really have an outline when focused. The validator cannot connect if there are sub-elements or there are over-arching styles.
... visual inspection might be the only way to really check this.

astearns: I think it would be nearly impossible to find it perfectly. But the validator could flag any time outline is set to 0. An author guidance seems like a good idea.

JC: I don't think that it could be an error. But it could be a warning.

fesch: You could also flag transparency of outlines too.

Simon: But should a CSS validator do A11Y validation?

JC: We are making some progress in getting the HTML validator to assist with A11Y validation.

Simon: That is about existing conformance requirements.

JC: So you are saying that unless there is specific author guidance in the spec, there couldn't be a warning in the validator?

Simon: We need to draw a line somewhere. Outline is one thing. What about contrast?

JC: We don't need to repeat the A11Y guidelines in the CSS spec. Not all of them. But some author errors should probably be noted in CSS specs and the validator.

Bryan: There is no way to bind changes to the pseudo elements related to an element that has focus might not be exposed.

<MichaelC> ack

JC: I think that it should work right, and is not a CSS issue.

Simon: Actually I don't think the css changes to pseudo elements are rendered when done in this way (on native form fields).

JC: I think the problem exists, but it is not a spec problem.

ISSUE: Look into how browsers or screen readers should react to generated content that changes on focus.

<trackbot> Created ISSUE-684 - Look into how browsers or screen readers should react to generated content that changes on focus.. Please complete additional details at <https://www.w3.org/WAI/PF/Group/track/issues/684/edit>.

<Zakim> jcraig, you wanted to mention nth-fragment()

JC: Simon was talking about places where we could have additional author notes, and alan mentioned backdrop filters and blend modes.
... there are going to be issues there. In that part of the CSS spec you could point to the Media spec. "When using blend modes be cautious."
... nth fragment is awesome

<kurosawa> http://www.w3.org/TR/css-overflow-3/#fragment-pseudo-element

JC: has anyone implemented it yet?

Bert: I dont think so

JC: the potential A11Y issues with it... might not be an issue. But due to the way each fragment might be in a separate view node, A11Y APIs might have trouble relating them.
... we might need to extend the API so that it shows how fragments flow from one to the next.
... position is important. The AT needs to know where focus is. It is going to be challenging.

<kurosawa> http://dev.w3.org/csswg/css-regions/

astearns: The same thing comes up with region chains. Already supported in some browsers. How is this supported now?
... you have a chain of boxes and you can traverse the list. They are displayed in different places.

JC: If they are real DOM nodes, I am almost positive that they are going be a problem for the A11Y API.

astearns: even if they are in the DOM, the DOM nodes are empty because the content is flowing through it.

<kurosawa> https://github.com/Igalia/css-regions-selection/wiki/Selection-&-CSS-Regions

kurosawa: order of rendered tree is different than order of the DOM tree

astearns: there has been a lot of work done on this at Igalia to make selection work right

Fantasai: Since there is no Last Call any longer when do you want us to ask you to review things?

JS: Sooner than later. We need to be informed.

MC: You should push notify us when you think it is stable (pseudo-last call)

fantasai: Early on the high level gets written, then we start doing the implementation details. But PF probably doesn't care about that.

MC: Yes.

JS: If it is feature complete, then we should be reviewing.

fantasai: gridlayout is stable now

<Bert> CSS Grid Layout Module Level 1

Steve: (chair of process working group) There is a best practice in the process wiki about how to decide when horizontal groups coordinate reviews.
... goal to get more dialog to make it more effective.

JS: PF is big enough that we do not attend all of the meetings in any given week.
... when we do reviews we need expertise from across all the disciplines. JC is the one most up to speed on CSS because he is active in the group(s).
... but JC doesn't necessary attend every meeting.

JC: If there is technical expertise in PF for something, those experts should join the working groups.

JS: yes. we are moving toward that.

JC: I know current work document points out the CSS modules. Is there someting equivalent to a non-editorial change log?
... if there is a new spec that's one thing. If there is a new section added how do we know?

fantasai: Most specs have a change log. It depends on the editor.
... as the spec stabilizes more detail gets into the change log. The list tracks changes between published working drafts, not editors drafts.

Bert: CSS blog has announcements. Also posted to www-style

<Bert> CSS WG blog

fantasai: Announcements are CC'd to coordinating groups. Threads are tagged with spec codes on mailing lists.

<astearns> official announcements on www-style use "[csswg]"

<jcraig> announcement subject line prefix: [csswg]

<dbaron> the announcements use [CSSWG] in all caps

<Bert> Just the publication announcements

Eric: Browsers display form fields without enough contrast. Text, borders, and checkboxes. Developing a WCAG technique.
... is there a standard way to format the 'placeholder' attribute right now.

<jcraig> placeholder pseudo class becoming standard?

Eric: will it be done through the shadow DOM?

fantasai: Debating a pseudo element for this.
... dont ask authors to fix this. Get the browsers to fix it. author's will just screw it up.

JF: We need to do it as an author because there are ADA requirements and we need to fix it to stay out of court.

fantasai: fixing the contrast issue in the browser should be easy to do. it should be able to be in the next release for almost anyone.

JF: Sure but just because it is easy doesn't mean it will happen.

David: In many cases browsers are using the system form control styles. Because that is what the users expect.
... if we are getting the styles from OS then the browsers are less likely to try to make a change.

<Zakim> jcraig, you wanted to mention placeholder pseudo element with shadow dom implementations

JF: Yes, but that doesn't mean we as content authors have a choice.

JC: there are non-standard pseudo selectors now. And there might be an added pseudo element / pseudo class.
... If there is a browser problem and there is no solution in CSS then it to the browsers to fix.

David: If there is a platform setting for form controls, then it should effect browser appearance of the controls too.

Eric: Sometimes there is a 'high contrast' it might not be a great solution for everyone on every screen.

JC: to clarify there are different types of 'high contrast' on different platforms.

<Zakim> jcraig, you wanted to mention placeholder pseudo element with shadow dom implementations

JF: Not saying that we need to fix this tomorrow. It is just that the today solutions feel 'hacky'. It is great that you are working on this. The urgency is not that it is just about design. It is also about A11Y requirements too.

JC: webkit implements placeholder as a pseudo element. Is that why you went this way instead of a pseudo class.

fantasai: Two reasons. There was no way to effect the opacity with a pseudo-class. Becase that would style the background and the borders and everything.
... other reason was that it was unclear what the relationship between placeholder text and actual text.

JC: does this ignore the content property?

fantasai: the content property is not used for this. Some other pseudo elements ignore content as well.

David: The only that care about content are before and after.

Simon: placeholder values sometimes get displayed even when there is a value, but get relocated in the field.

astearns: flexbox? There is a section. Is that sufficient?

JC: I dont think anyone in the room is familiar enough to determine if there are issues.

fantasai: the flexbox spec. we looked at the A11Y use cases and wrote up the actual behavior.
... we wanted to allow authors to do a good job, but encouraged them to reorder the DOM. navigation follows logical order, not visual order.

fesch: I thought the whole point of landmarks is to assist with moving through documents.
... skipping things you don't care about

<astearns> some of the use cases for named flows and region chains follow the same logic, jcraig. You can keep DOM order for the content and rearrange visual order using the regions

fantasai: visual order doesn't really matter to visual users

<astearns> so any issues with flexbox ordering may extend to regions and nth-fragment as well

JC: actually they do. Some keyboard and visual users still rely upon screen readers.
... switch control users also use the same A11Y API as the screen reader. The order that gets exposed to the A11Y API does matter.
... you navigate the DOM but are still seeing the display that is on screen. You are sighted but you rely upon the A11Y API for navigation.
... too early for me to talk about changes, but there might be some improvements in the future.

fesch: there are some tool bars that use float. tabbing through then does surprising things.

JC: we see misuse of css transforms for performance reasons (authors do not reorder DOM when they should) from time to time.

RS: There might be a way to use navindex to customize the tabbing order.

JC: navindex + flexbox should help for focus order. It does not deal with view order or order of other unfocusable content.

<mhakkinen> +q

fantasai: navindex at the CSS level is similar to tabindex. Our position is that if there is a logical order to go through your content, that should be the DOM order.

mhakkinen: navindex might be a solution for some of the things we have been working on . I actually like it.

MC: we owe CSS a response on flexbox

JC: What was the PF comment?

fantasai: PF said the tabbing order should follow the DOM. We disagreed.

JC: Maybe that comment was premature.

fantasai: CSS should not be used for document reordering. If you turned off CSS the document should still be the same.

Steve: If CSS were off the document navigation order WOULD match the DOM.

Matt: dont we want to be careful about managing developer expectations? This is one of the places where presentation and interaction merge.
... we should be forcing developers to rely upon DOM order.
... as soon as we put navindex into the CSS then CSS is embedded in the interaction layer.

RS: if you make them reorder their DOM and they are using this to not reorder the DOM.

fantasai: then they are non-conformant.

JC: Yes. we need to give you some specific use cases and change requests.
... we want to encourage proper use.

fesch: is there a way to stop animation?

astearns: goes back to an earlier discussion about ways to reduce animations

JC: there were some ways to do this (historically pressing esc). WCAG requirement to stop animations within 3 seconds.

fesch: CSS specs talk about animation, but there are no clear ways to turn it off.

rssagent, make minutes

Timed Text Topics

Nigel: Three documents are rec track
... what sorts of things is PF looking out for when we review specs.

JS: Mark H is a good person to talk to about this.
... UI implications are important.

Nigel: Our specs don't really talk about UI

JS: There are also semantics issues. We appreciate it when we see them.
... captions. We need someone with expertise in captions. But it has probably been pretty heavily vetted.
... Sylvia has a lot of expertise in this area too.

ShaneM: Also want to ensure that the specs themselves are accessible.

Breaking for lunch. We are reconvening at 13:30 pacific

<joanie> scribenick: joanie

Scoping 1.1

RS: I've got a rewrite of the introduction, but I don't want to spend time on that.
... I've got a bulleted list with the goals of 1.1. I don't know if the group agrees, but I'd like to try to scope it.

<richardschwerdtfeger> • expanding WAI-ARIA 1.0 to fill semantic gaps needed to support HTML5

<richardschwerdtfeger> • make incremental improvements on existing WAI-ARIA features that make it easier for the developer to understand such as deprecating the “presentation role” and replacing it with the role of “none” .

<richardschwerdtfeger> • make incremental improvements necessary to aid access to online rich office applications, while pushing more lengthy changes to next major release of WAI-ARIA

<richardschwerdtfeger> • making it easier to for authors to provide help information

<richardschwerdtfeger> • improving the accessibility of dynamic content generated by scripts; and

<richardschwerdtfeger> • providing for interoperability with assistive technologies

RS: Do the items above really reflect what we want to achieve?
... (Reads aloud above list)
... How much more specificity do we want to add?

MK: The last item is really broad.

JC: Do we want to take it off the list?

RS: The reason I mentioned it is in the context of the new API mapping specifications.

JC: Do you mean add new mappings?

RS: Yes.

JC and RS: That is a reasonable scope.

RS: The name computation is going to be moved out, I think.
... Part of ARIA 1.1 talks about name computation. Part of that is also in the new ARIA specification.

JC: We should reference that in the other documents.

RS: Does that need to be in the list? This is a pretty significant piece of work.
... Should that be in the introduction?

MC: As far as the introduction, I think we're introducing what we are doing.
... It's probably useful in the introduction to talk about the role of the other specs.

RS: I did mention the CAAM later on in the text.

MC: This might not belong in the introduction.

RS: What else would we like to include?

JC: I want 1.1 to be nothing unless it's solving a critical problem in a small enough scope that it's readibly achievable.
... And also *only* HTML 5.x features that are already implemented.
... Otherwise we'll have a hard time getting our two implementations.

RS: What version of HTML 5?
... 5 or 5.1?

MC: I thought it was 5.1 for ARIA 5.1.

SM: That's what we agreed at our last face-to-face meeting.

RS: Ok, we'll make it HTML 5.1.

JC: I don't think color is implemented. They render as text fields.

MC: If plan 2014 is in effect 5.1 should be in last call right now.

Group: And it's not in last call.

MK: James you mentioned things that are solving a significant problem but are small enough to be contained.
... There are two very specific actions that I really want to try to get done:
... 1 is aria-current and the other is action-1505

<jcraig> action-1505?

<trackbot> action-1505 -- Matthew King to Create proposal for a role and strategy to address issue 633 -- due 2014-10-13 -- OPEN

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

action-1505

<trackbot> action-1505 -- Matthew King to Create proposal for a role and strategy to address issue 633 -- due 2014-10-13 -- OPEN

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

RS: These are features that the group deems necessary?

<jcraig> issue-633?

<trackbot> issue-633 -- listbox and tree may contain only static items; badly need interactive widgets that can contain interactive typed items -- raised

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

JC: Why are listview and treeview different from list and tree?

MK: Trees and listboxes are strictly widgets and not structure (to ATs)

FE: I thought that in HTML this was expanded.

MK: You can have a link in a list item but it won't be a link.

JC: This sounds like an implementation problem.

MK: The spec says the list must contain list items; not links.

JC: That sounds like something we can solve without creating two new roles.

MK: That goes back to widget versus structure.
... An option in a listbox is not designed to have child elements.
... So the problems that we are solving are things like search results or to recreate the Windows Explorer or the Desktop Finder experience in ARIA.
... You cannot recreate this experience in ARIA today.

JC: I can see this being expanded to include more than static content.
... If we add an entirely new widget/role, that might expand the scope too greatly.
... Example: If you go to twitter.com and arrow down from the search field, you get a list of selectable options.
... That list item includes a button which allows you to delete an item.

MK: In the feed itself, you have J and K to navigate in the list. And you can still Tab around. But if we had a listview element, you could have each tweet be something you can arrow to.
... Compare it to Windows Explorer on the Desktop.

JN: To me, the timeline is a listview.

JC: Listbox option implies selection and form elements.

MK: I am working on a more specific proposal.
... I don't know how long it will take to get the two implementations.
... But if we can get it done, I'd not like to toss it out a priori.

RS: So this falls under the heading of incremental improvements?

JC: Is adding two new roles an "incremental improvement"?

RS: When would we like to be done with 1.1?

JS: We were trying to tie this to what HTML was doing.

RS: The original plan was to get 1.1 done by the end of 2016.
... This was based on HTML 5.1's plan. But then they moved that up a bit.

JS: But they might do modularization. They are still deciding, so we don't know yet.

MC: I'd like to set a reasonably short timeline and separate from HTML.

RS: We've gone through most of the issue list. That doesn't mean we're not going to add more at this item.
... James Craig has action items to put them in the spec.
... But we can target this by first quarter of next year.
... We can say anything not resolved by then gets pushed back to post 1.1.
... Thoughts?
... Reminders, we have CSUN, SXSW.

MC: CSUN would be a nice time to stop.

JC: We 64 open actions on ARIA 1.1. and 41 opened and raised issues.
... The 41 issues are harder to scope. But I think they are still open because they have action items.
... Some of those are just editorial.

RS: CSUN is March 2nd through the 7th.

JC: What I meant by "quasi last call" is: There is a point where we need to ask for reviews.
... The new process drops the last call stage. We have the option of choosing the old process or the new process.
... But it means that for review, because there is no last call, we need to be more proactive about getting wide review.

Nigel: We did this with Timed Text. And you do need to be proactive about wide review.

RS: Can you do a call for review?

MC: Yes.

SM: That would mean feature complete, right?

MC: You don't have to, but probably should be.

RS: This would also apply to CAAM right?

Group: Yes.

RS: So we need a version of core and a version of name.

MC: Joseph posted some edits yesterday and today.

RS: We were going to vote on whether or not to publish this as a heartbeat.

SM: Can't we do a FPWG of name computation any time right?

MC: Judy is the approval chain for WAI FPWG.

<ShaneM> FPWD is different than a WD in that it needs approval; short name allocation;

RS: So we should try to get her a copy of the name computation a month or so early.
... So we can shoot for a call for review for CSUN.
... That's for core and name computation.

MC: I would like to have heartbeats for HTML 5.1 A11y mapping spec, SVG 2 mapping spec at that same time.
... There is now a name computation product.
... One reason I'm suggesting CSUN is because it's good to have a deadline.

RS: Back to the scoping, do we think we can get all of the issues resolved by that date?

MC: Resolved or deferred.

RS: I don't know if Mark is going to need something.
... Are we going to have 1.2 or go straight to 2?

JC: I'm not convinced that ARIA will be the place where we solve some of these issues like the document views.
... Even if we thought it was reasonably achievable in a short time, I don't see it as 1.x.

RS: Do you see it as a separate module?

JC: Potentially. And we shouldn't try to squeeze it into ARIA with the roles list.

RS: So it doesn't sound like we need an uber 2.0. We can do incremental updates for 1.x releases.

MC: Modularization was planned for 2.0, but we jumped the gun.
... Related to that, everything is versioned 1.1. Do we need to tie the modules to that versioning?

<Zakim> MichaelC, you wanted to ask about versioning of AAMs

RS: Let's say that Mark's stuff cannot be done in 1.1, but we can achieve it for 1.2.

MC: Right. So far we modularized the mapping guides, maybe we should do that for ARIA itself.

RS: We're kind of doing that (book effort, for instance)

MC: Maybe we need to do the framework for modularization in 1.1. For me the big thing is rejiggering the taxonomy for the abstraction points.

RS: One of the things we agreed is we would not include the OWL taxonomy in the spec.

MC: But it would include what goes into the spec.

<richardschwerdtfeger> • Align with a new governance model for modularization and extensions to WAI-ARIA

JC: That approach makes doing the review much simpler. 100 pages are harder to review than 20 pages.
... And stakeholders can review the parts they care most about.

SM: We don't have that many documents, so it's not that complicated.

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

JD: I think the bullet related to incremental improvements is too specific.

RS: Do we want to mention annoations?

JD: I think we want to keep the incremental improvements but not list the specific areas so we can include things like the testing needs.

JC: Annotations are specifically tied to the rich text editing. If we try to squeeze something like that in without knowing what they are doing, we might be steering implementations in the wrong direction.

MC: I'm concerned about expanding scope.

JC: I think we should postpone selectors and annotations.
... If we do, then it's down to a few new roles and a few new properties.

RS: We need to make sure everyone is in agreement.

MC: Modularization should help in this regard.

Imake incremental improvements necessary to aid access to online rich office applications, while pushing more lengthy changes to next major release of WAI-ARIA

(Group discusses whether or not the revised bulleted list reflects our plans)

<richardschwerdtfeger> • Expanding WAI-ARIA 1.0 to fill semantic gaps needed to support already implemented features in HTML5.1

<richardschwerdtfeger> • Align with a new governance model for modularization and extensions to WAI-ARIA.

<richardschwerdtfeger> • Make incremental improvements on existing WAI-ARIA features.

<richardschwerdtfeger> • Enhance annotation capability.

<richardschwerdtfeger> • Making it easier to for authors to provide help information

<richardschwerdtfeger> • Improving the accessibility of dynamic content generated by scripts; and

<richardschwerdtfeger> • Provide API Mapping specifications for the features in ARIA 1.1.

RS: I'm going to send this document out to the list.
... The other thing I did is change the language associated with the scope, as ARIA is not a "bridging technology."
... (Reads proposed/draft language)

JN: I thought the primer was going?

MC: We haven't had any plans to update it.

JN: We're going to move those sorts of things to authoring practices, right?

<MichaelC> Editors´ draft of ARIA primer

RS: The problem statement (of the primer linked above) is dated.

JC: Is there a way to retire TR documents?

MC: Yes. We chose not to go through the administrative process of doing that. But we could if we wished to.

RS: Do we want to do that for the primer?

MC: I am planning for us to do a requirements document. Maybe the relevant bits from this could go into that requirements document.

RS: At the time this primer was written ARIA was entirely new to everyone.

MC: I think we want to migrate the content, but this is largely editorial work.

RS: I'll make a note to myself to remove references to the ARIA primer from this revised introduction.
... And I'll reference the requirements document instead.

<MichaelC> ARIA Requirements editors´ draft

Review of pending actions

<jcraig> action-1293?

<trackbot> action-1293 -- James Craig to Add aria-colindex to role gridcell and aria-rowindex to role row -- due 2014-11-11 -- OPEN

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

JC: I don't think it's a pressing problem.

JN: We need some way to handle grids scrolling in multiple additions.

JC: My general view of this is that large data grids are not going to work well until HTML 5 data source.
... The current problem is that everyone is doing a custom implementation. We need a native solution.
... James N is saying this is a stopgap.

JN: Every grid has to become an application essentially.

JC: I understand that there is a problem, but even if we mapped this in WebKit, it wouldn't work in VO for some time. The same is likely true for Gecko + JAWS.

JS: Which is easier, this or aria-owns.

RS: This is something you can put on the cells. So I don't think it's terrible, but....

JC: It's easy to spec and easy to expose.
... Has managed focus?

<jcraig> ACTION-1362?

<trackbot> ACTION-1362 -- James Craig to Patch issue-640: aria-hasmanagedfocus -- due 2014-02-01 -- OPEN

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

JC: We're keeping the managed focus one.

<jcraig> ACTION-1390?

<trackbot> ACTION-1390 -- James Craig to Add aria-hint to aria 1.1 as related to ISSUE-406 -- due 2014-03-03 -- OPEN

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

JC: It's not a hard one, but if it's not really pressing we should punt it for 1.1.

RS: Some people asked for it at the face-to-face.

JC: I did too. But we need to determine what is most important.

Mark: What is an aria-hint.

JC: It's basically tooltip.
... Or help text. Do we need an API way to override this?

RS: I don't have a strong opinion either way. I think things like colindex is more important than this.

<jcraig> ACTION-1422?

<trackbot> ACTION-1422 -- James Craig to Develop proposal for label role and aria-labelfor property -- due 2014-05-05 -- OPEN

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

Group: We'll punt this one.

MK: I thought we already closed this.

<jcraig> Per discussion in the ARIA meeting on April 21, there was consensus to drop the proposal for an aria-labelfor attribute to go with the new role label. The group did not identify any specific benefits of an aria-labelfor that are not provided by aria-labelledby.

<jcraig> Proposed specification text for role label follows.

<jcraig> Label

<jcraig> An element containing content that labels another element. A label MUST have an explicit relationship with the element it labels expressed with aria-labelledby on the element being labeled.

<jcraig> The most common accessibility API mapping for a label is the accessible name property. However, because aria-labelledby is required to create the labeling relationship, use of role label on an element does not change the accessible name computation of the element to which the label applies.

MK: I thought we punted on the whole "for" thing. What was left?

<jcraig> Authors are not required to use role label to identify elements that serve as a label but may do so in order to provide semantic clarity in code.

<jcraig> Related concepts:

<jcraig> * HTML label

<jcraig> * HTML caption

<jcraig> * HTML figcaption

JC: (Reads the above)
... So this is a generic bit of text that labels something else?

MK: We looked at the mapping table in UAIG. There are plenty of mappings in HTML that are property-based. Conclusion then: We could make this property-based; we don't need a role for it.

JC: I said "punt" it for 1.1 based on the title of the action item.
... I'm going to retitle it to reflect the decision made previously. I think we can do this.

RS: ARIA hint will be postponed to 2.0, right?

JC: Yes. The issue and the action are being moved to 2.0.
... There is a related issue (issue-411)

issue-411

<trackbot> issue-411 -- Consider aria-description which would take a string like aria-label -- open

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

RS: I think that's a good thing to have

JC: (Reads from issue comment.)

RS: What do you map it to?

JC: I think we map it to help.

MK: Whatever you map aria-describedby to should be the same as aria-description
... We have it in 1.0. We tested it. It passed. So wouldn't you be able to use the same algorithm for this?

RS: This would discourage people from showing the same help text to everyone.

JC: Right, it would hide this text.

JN: But we allow people to hide text already.

(Discussion about whether or not the rationale is the same as with label)

JC: We need a label for certain things. With description, we should provide it in such a way that the description is available to all users.

MK: Using that logic, why do we allow aria-describedby to point to a hidden element.
... Isn't it more transparent and easier to understand if we have aria-description and not an property pointing to an ID for an element which may or may not be hidden?

JC: How do you discover the description when you navigate to an element with a description, and then how do you activate it?

MK: JAWS does not render aria-descriptions in the virtual buffer unless it is visible to everyone.

JC: VoiceOver has help text which is not intended for longer text; it's intended for something that might appear in a tooltip.
... Part of my worry is that we're trying to cram description into places in APIs that were not intended for them, and might not be consistent across platforms.
... That one is assigned to Steve so we'll see if he gets to it.

<richardschwerdtfeger> topic: More ARIA topics

<bcampbell> scribe: bcampbell

<bcampbell_> JD: This is stuff I've been thinking about for many reasons. Things we do want based on dPub

<bcampbell_> JD: We do want to extend based on roles. We might want chapter.

<kurosawa> RRSAgent: make log

<bcampbell_> Janina: Are you talking about extending beyond...

<bcampbell_> JD: We all have educational testing, dPub

<bcampbell_> JD: We have a need to extend roles but not have role explosion

<bcampbell_> JD: need localized role names

<bcampbell_> JD: a lot of logic both in screen reader and implementations including web apps due things differently based on what the roles are

<bcampbell_> JD: If we have more roles, what's Orca going to? What if it doesn't know what a Chapter is?

<bcampbell_> JD: Those AT's are going to start recognizing what a Chaper is eventually

<bcampbell_> JD: Proposal #1 is ARIA-Subrole eg. as Chapter

<bcampbell_> JD: Subrole gives further specificity to a known role

<bcampbell_> FE: Is it just another name for it?

MK: it would have different state in the parent role, right?

JD: the switch in case of AT as a toggle button can be pressed or not pressed, when that state changes, AT's want to react, they want to present to the user, they might want to say on or off, but programmatically, theere is no difference.

MK: is it going to say switch pressed? how do you say it?

JD: have ARIA localized state
... If we have a mechanism to say, "is checked now true?" then we update ATK set - and we have a way to say what that localized state is "on"
... and similar for off
... The exact API would be still needs to be flushed out a bit but accepting at conceptual level would be awesome
... want to address the whole localized role thing
... I want the role name
... Instead of localized Role name, have a "sub" role or similar
... For instance Section, Chapter, Kanto

<Zakim> jcraig, you wanted to mention action-1417 (aria-locrole) and the token fallback roles (e.g. "switch checkbox") and to mention also role="-epub-chapter section" -> role="chapter

MC: How does implementation tell it apart from role?

JC: We do have on the list ARIA... closest to this is loc_role which is basically a string, so the role is left alone, this is just how it's described on the platform
... loc_role would be chapter

<jcraig_> role="-epub-chapter section"

JC: you mentioned a fall-back role. We also have the opportunity to do something like (shown above)

<jcraig_> role="chapter section"

JC: For example, ePub would not recognize but would fall back to chapter

<jcraig_> role="chapter section" aria-locrole="chapter"

RS: ePub didn't want space name

<jcraig_> epub:role="chapter"

RS: they just want to say "Chapter"

JC: we should be careful letting them define that

J: we are in charge

JC: Once we do the chapter [space] fallback, the whole time along the way, the browser is speaking "Chapter"

FE: You could say I want to style by epub [role]?

JC: yes
... Subrole was initially just an OS10 construct

MK: we'd both have subrole and locrole?

JC: we have both on OS10 but I don't think we need both
... my caution is that other platforms do not have it
... gave example

JD: for me, the subrole is not end user consumable, the localized subrole would be

JC: it's a user presentable string so we need to be clear if it's localized
... OS X has role, subrole, role decription

JD: makes case for same on ARIA
... we have several use cases: if Webkit doesn't recognize chapter, it'll fallback to section. But if publishing industry wants books to be compellingly accessible on the web.
... there will be web core accessibility logic associated with Chapter becasue webkit now recognizes it
... in the case of a search input, the user only cares about the input, knowing it's a search field... you're in your browser FF, you hit ctrl-F and start typing, accessible events are happening in the view, the screen reader is not presenting this info, how do we know those results are not presentable?...

JC: why do you need to hang onto the text role?

JD: probably don't absolutely need to. I need fallback all the time.

JC: we know how to map group, if we add chapter then ... I don't see the need for the fallback role or subrole

JW: James said what I wanted to say. in ARIA the roles are all laid out and that will find its way, but we don't have a way for authors to add their own and have that find its way to the API
... important to solve the problem where new things come into ARIA and all the layers must be updated, process to make this easier needed

RS: uncomfortable with subrole. Could we make the taxonomy available to AT vendors.

JC: yes, we have a finite list of roles and a hierarchy of fallback roles.
... user agents also have a finite list of roles with mappings
... landmark roles are platform specific in mapping

RS: we have this hierarchy. if we could make it available to vendors, so they can go to the superclass and grab if they don't recognize
... could even post a server
... this versus having to put in a subrole.

MK: you could specify a subrole that isn't compatible and has a conflict

JC: would subrole just be a string where you can put anything? Why not just map to main role?

Janina: because we don't know what it is

JC: we aren't talking about role description

RS: we don't allow freeform. agreement we shouldn't allow freeform

JC: we all agree that role is a tokenized list and nothing else is a recognized finite list
... it's okay for the user to call it Chapter but it behaves like a group role
... why not define it as one of the known roles?

JD: once webkit knows this thing is chapter role, there is logic: do I emit a notification based on role according to platform

JC: could be related to webkit implementation details
... typically, we'll commit a change, add a role, leave the ATK role open to fill in the blank

JD: the fallback is role unknown

JC: we'll just fallback to "something" so it doesn't disappear when not recognized

JD: perhaps this is a webkit thing we can talk about later
... not unique to webkit

JC: WebCore could hang on to both roles and use for platform specific mapping

RS: the localized state name creates a lot of problems
... you go back to, "what does this belong to?"
... there could be a lot of states and properties, which localized things belong to what? Don't know how to do that. Need to think about it. You might have to have access to resource that is synchronized

JD: we'd be potentially changing a lot of code. Implementation details once again.

JG: when you define these things, how do people interact with it. All these roles that dpub wants to add, are they something new?

JC: I get why we need to hang onto the fallback role, but why author-defined subrole?
... if platform knows role, what's value of subrole? if there are more details to the subrole, we want that defined at the role.

JG: how does a user interact with the subrole, such as pizza and then pizza slice. This makes sense only in certain context.

JD: dPub as an example: give us a defined set of roles we call subroles.

JG: how do I interact with it?

JD: pizza was like a checkbox

JC: to answer JG, we won't need special interaction with subrole. there won't be special behavior, just more specification for the role
... but if you take a slider and call it a number line, that's a problem. Authors shouldn't override loc role or interactive roles due to confusion

Example of number line for students who are taught a number line but it's called a slider, kids won't understand

In the context of education

It will be implemented as a slider but called a number line

JC: that might be a valid case of overriding the slider role

MK: example of education number line... clarification of education example by Janina
... why not labeled number line slider?
... when you get to it, you need to know how to operate it. Call it number line slider. Should have multiple aria-labelledby

JC: mostly it won't be confusing in practice
... number line in this context will be something you'll figure out
... it should not go in label but should go in description

RS: say the role description and then say "behavior" slider

MK: role specifies behavior
... AT renders roles
... it's up to the AT to render even if they want to localize role names

JC: AT has to also implement or it doesn't get seen anyway
... AT vendor could have a setting that would announce number line AND slider both

MK: explosion of names of roles concern

JC: os10 has had ability to do this for a decade but almost no one has overridden it... except those doing it well. So in practice, the anticipated user confusion has not been a problem.

<richardschwerdtfeger> <div role=“slider” aria-locrole=“number line”> say ”number line, behavior slider”

RS: if AT said the behavior would that help?

MK: if AT knows primary role, it'll speak, tell you it's a combo box and how to interact. Even if you call it something else and the primary role is combo box, JAWS will give combo box instruction

Janina: Not sure it's useful in 4th grade

JC: usually that "speak instructions" verbosity is turned off, but in contexts it may be useful

RS: in UIAutomation, they have localized roles and control patterns they can say
... It's as if you had an API and you'd have a state change event

FE: is it the AT? would the developer provide it?

JC: the author provides the loc-role

JE: what about supporting multiple languages?

JC: that's not our problem, the author provides text content and title attribute, they've got loc roles

RS: you could assign certain states and values with certain elements and say here are the localized values of those

<Zakim> jcraig, you wanted to discuss Joanie's meniton of aria-locstate

RS: we could do that but not here but maybe with an API. you'd have to call a js "something" on the document

Issue: Creation of Resource definitions for localized state information

<trackbot> Created ISSUE-685 - Creation of resource definitions for localized state information. Please complete additional details at <https://www.w3.org/WAI/PF/Group/track/issues/685/edit>.

JC: JD asked for loc state on/off. why do you need states for that?

Mark: use case: subdividing a circle into slices, slices are options you can select/deselect, you must shade slices

JC: don't know of any platform that supports that yet

JD: can we do as at-risk and push back? (localized states)

JC: to Mark, can you send to PFWG - sounds like good use case. Not saying no but don't want to commit by Spring

Mark: will provide the examples for the spec
... we have ATS with lots and lots of items... lots of vendors. We can't call these items the correct thing because of non-visual descriptions.

Janina: Put use cases, who needs it, who wants it
... it's useful to step back and make sure we've got places to slot the things dpub is about to throw at us. Want to look over briefly the taxonomy of the things that are coming to us. We are going to need help. The dpub stuff is relatively easy but we need help from HTML. The trickier stuff is like what Mark is bringing us here. So we should review the taxonomy.

JS: dPub is giving us things that next. They have names they want to use instead of H1, H2, etc. They have Kantos instead of chapters. We will get free floating things like sidebars and sidenotes, they can go anywhere and just plop into place.

JC: we can take those in the context of html5

JS: But we have footnote, that is only a starting point. We don't know where it ends and have to get to it from multiple places. Back button may not work. We need to look at those things.
... 3rd kind of structure from dPub we won't get to right away. need way to span across multiple structures. mapping of pages.

JC: this is defined in epub

JS: need to extent to braille page

JC: no, that would be the real page
... canonical page 63 will always be the same

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

<jcraig> EPUB Canonical Fragment Identifier (epubcfi) Specification

JS: the assessment stuff, some is in books, might be the set of test questions at the back. These are the widgets we've just been talking about. The structures all have names and yoiu can't predict that any one of them will have the same name.
... We're using most of the stuff we already know.

<Zakim> joanie, you wanted to mention use case of launchers

<jcraig> that may not be the right reference

<jcraig> Here it is: http://www.idpf.org/accessibility/guidelines/content/xhtml/pagenum.php

JD: thougth of another example, not just a justification for the subrole. What if you want a web application equivalent of the Windows Explorer. What you're navigating in is an icon but what those icons do is different than other things, the might launch things, or something else... we don't want to lose "icon" but we might want to have it be specialized to have a particular special action.

JC: but this icon is a marker or button that launches and application, image, or file? You'd want to hear different... (showing example on laptop - different views of files)

JD: the icon has a special purpose as a launcher
... let's go to the queue

Jason: what happens if referred to number line but behaves as a slider. The AT could tell them so in the hints... another important element: if you're the author of the content and this is slider-like, you might want to call it something else and signal that and that's difficult to do at the moment. There is no way to declare that the information is helpful to the user for how to use it...
... rather than description.
... the user could be operating by any input method. if the author is customizing the low level about how the events are processed to interact with the control, but not way providing that to the AT user except for standard ways.
... How will the user find this information?
... for example the radio button that is slightly different. Behavior is different and need a way to explain that to the user who has different expectations.

JC: possible that some of this will be covered by IndieUI

Jason: we should think about what support we'd be providing for that

JC: some of this would be with IndieUI since the platform will be handling it. Every screen reader is different. JAWS could speak a slider differently due to interaction controls. IndieUI should flatten that.

Jason: as long as what you're doing fits the event types that is recognized.

<mhakkinen> +q

JC: but what would the instructions say?

JS: you're askign for modality contextualized help. mousehelp, touchscreen help

Jason: yes, this is a challenging problem

Mark: QTI has option for author to provide a box for the use of an item below the visual location of visual elements. We need a way to provide a more generic description. For example, "use the arrow buttons to [showing instructions on screen} to divide the circle into more or fewer parts"
... instructions continued: Then shade the parts of a the model.

<bgaraventa1979> sorry guys, I've got to head out

Mark showing demo. Selecting pieces with enter key.

Mark: we have thousands of these types of interactions. What do we call these things? We would have to tell the user that this pie is a series of checkboxes

JC: we'd hear "shaded slice 3 of 6" do we want to take index and set size to localize like that?

Mark: on a number line we have value and value text already

MK: this is a complicated solution to an easy question

JC: it's an interactive widget that helps you figure out the answer

MK: think about how to present the question in a different way that makes more sense
... a person would be filling in the answer for me

Mark: CAN we develop a common experience?

<Zakim> ShaneM, you wanted to talk about children taking standardized tests

MK: the entire conversation keeps going back to same fundamental set of issues. in ARIA 1.1 and concept of 2.0, we have roles that map to behaviors, but in generalized problem of the world, with the excellent examples we've seen today, we need the ability to communicate behaviors and states and instructions and customize the whole bit. Put that power into the hands of the content authors....
... Enable AT to interpret reliably.
... is this problem with custom components, is it in our near-term scope? it seems antithetical to what we've done to-date.

JC: the items on our 1.1 agenda puts this on our agenda in the near term

<Zakim> jcraig, you wanted to defend the pie slice example from an instructional designer point of view

JC: we could test this with track pad commander on osx
... this example is visual for the pie slices. This allows you to perceive this spacially. This ability to learn spacially is important for both versions all versions.

RS: even if you say pie is localized, teacher can explain the touch. Touch interface is a huge improvement. Most things do not deal with touch these days.

Janina: it's a different type of accessibility

Mark: we have no way to test blind users now on these questions

RS: you could very easily put a localized role into various objects. It would be trivial. This is easily doable with a role name.

Protocols and Formats Working Group Teleconference
31 Oct 2014

Attendees

Contents

CSS Overview

Timed Text Topics

Scoping 1.1

Review of pending actions

Summary of Action Items

Scribe.perl diagnostic output

Protocols and Formats Working Group Teleconference 31 Oct 2014

Attendees

Contents

CSS Overview

Timed Text Topics

Scoping 1.1

Review of pending actions

Summary of Action Items

Scribe.perl diagnostic output

Protocols and Formats Working Group Teleconference
31 Oct 2014