<trackbot> Date: 16 December 2013

<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus

<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-pfwg/2013Dec/0026.html

JS: Update on status of implementation guide
... Need to add version information on what was tested
... In two or three years people will want to know what was tested

Clown: When do we need it by?

MC: Soon

RS: Comments about at risk items?

MC: There was a good discussion

Clown: There a couple edits the GNOME people wanted in the editors draft

MC: When were they made?

Clown: December 4th
... I marked two items for pending review, mostly for the benefit of the gnome people

RS: What is the mac OS X version information we tested on?

JC: The best thing to do is use the OS version number

MC: Specified against

JC: Version 10.9.0, API only ships with the OS update

MC: We need a URI
... It points to the version of the API
... Right now it points to mac, we need to point to a stable URL that includes the version

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

MC: Concerned about the world being true at this point, changes in APIs require new documentation

Clown: We can use 2.1
... I put an URL in the chat room

<clown> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Accessibility/cocoaAXIntro/cocoaAXintro.html

JS: We need a stable URI, that doesn't change over time
... I know they exist at GNOME,org

<jcraig> For the Mac AX API, you can reference the same location: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html

JC: there is a couple of links that we could put in
... It says available in 10.2 and later...

<jcraig> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/accessibilityArrayAttributeValues:index:maxCount:

<jcraig> Available in OS X v10.6 and later.

JC: This one says available in 10.6 or later, or deprecated

<jcraig> Current release is 10.9

RS: If we have verision numbers that should be fine

JC: Latest release is 10.9

Clown: Do I have the URL?

JC: I pasted what is in the document now

Clown: I pasted what is in the document now

JC: The one I put in is the protocol reference

Clown: I should use yours? What should I put there?

RS: Mac OS 10.9 version number

<jcraig> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html

JC: The companion guide link is the one you already have

Clown: Use the one in the chat room now?
... I need something from Microsoft MSAA
... there is no version information
... If you follow the link it might

<clown> http://msdn.microsoft.com/en-us/library/ms697707.aspx

<clown> http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2

JS: I think we are 1.3 or something like that

Clown: this is what i have for IAcessible2

JS: this sounds right

RS: It has table 2 so that would be correct

<clown> http://msdn.microsoft.com/en-us/library/ee684013%28VS.85%29.aspx

RS: Are we all set with this? Can we moved on?

Clown: UIA is at risk right now
... There is no version number at this UIA link

RS: You need to ask cynthia about this
... Accessibility defects in HTML5

HTML5 defect 23371

<richardschwerdtfeger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23371

Strong Native Semantics table appears to imply @hidden trumps @aria-hidden

SF: Before the change was made in the spec, the HIDDEN attribute, basically HIDDEN overrides aria-hidden=false
... Hidden shouldn't override aria-hidden=false, it wouldn't block the content from being seen by AT

JC: I objected because hidden is a boolean, most elements is not hidden, that aria-hidden would never be valid, since the native semantics would override the aria-hidden

MK: You mean aria-hidden means nothing

Clown: does hidden apply to all elements?

JC: yes, all render able elements

MK: So it cases where you have the hidden attribute and aria-hidden=false

Alex: I understand there are 2 issue: one is semantic and you get two different version of the tree

RS: I think the thing is, if something visually hidden, but whats the information available to people with AT

<SteveF> current support for hidden/aria-hidden http://www.html5accessibility.com/tests/hidden2013.html

MK: I think these is a big problem the authors leaving aria-hidden, I think we need a different attribute, non-visual description attribute

RS: We could do that in the future

MK: The idea of revealing content to an AT that is not visible for visually

SF: This is a technique that has been used for years, using offscreen

MK: that is different

JC: how is that different

MK: That is not generally the way people hide content, we would not normally hide collapsed stuff with CSS or hidden attribue
... Hiding content off left was a hack

JC: there are many other cases like opacity and other techniques

<Zakim> jcraig, you wanted to explain the semantic distinction Alex mentioned and to respond to Alex's objection about *unhiding* hidden elements without rendering views

MK: These are all problems that need to have a solution

JC: In the spec it says hidden means hidden in all presentations

<jcraig> el.show()

JC: So having aria-hidden make it visible, also hidden can become visible using CSS
... The main purposes is to hide and show content visually, we need a way to override for AT

<jcraig> <div role="status" style="display:none"></div>

JC: So if you had an off screen live region
... lot of cases where this is the least hackey solution

MK: If you can associate it with it before or after, the actual screen position is not important

JC: It depends

MK: There is one statements, you need a way of overriding HTML5 hidden

<jcraig> Not specifically tied to @hidden. Also applies to display:none; etc

MK: It seems like HIDDEN and other CSS properties are all about visual rendering, if we need non-visual content visible we should have a way to do it regardless of CSS or HIDDEN

JC: That is what this is for, aria-hidden is to overriding native semantics

MK: That is what I am saying that we need a easy way without the confusion of CSS states

Clown: Some screen readers were looking at the DOM since they did not see the computed CSS
... aria-hidden was special when it was introduced

RS: Authors are using it to hide content...., and to expose content that was visually hidden

<jcraig> "Some screen readers" = Firevox

RS: We are having problems with aria-hidden being false

<jcraig> All other screen readers at the time used the screen rendering.

RS: One case is that it is being used to make content visible to AT that is hidden to other people

JC: one common use is hidden header, position them off screen so they are seen by screen readers

RS: Other examples

MK: I don't think we are short of use cases

<jcraig> skip links

SF: Visual link does not have enough information, so you put content in a span to add extra information and put it off screen

<jcraig> <a href="#">Learn more <span hidden aria-hidden="false">about product X</span></a>

RS: that is a situation that would impair the sighted user

SF: There is no good method other than to push it off screen

<jcraig> Sighted users see "Learn more"; a11y users hear "Learn more about product X"

SF: it is usually discrete chunks of test, not a whole new user interface

JC: There a bunch of use cases

RS: Alex needs more information about use cases, does he have enough use cases?

<SteveF> Invisible Content Just for Screen Reader Users http://webaim.org/techniques/css/invisiblecontent/

Alex: Evidence of need of aria-hidden for description...

MK: The live region use cases is especially important
... So like search results summary, is a strong case, dynamic information only to AT users
... You don't want only the .. you type in a text box and different types of new content appear on the screen, you don't want a live region, you want something short and terse

JC: Some times that is visually displayed, but screen reader users need that information

MK: Sometimes the information on screen is too terse, so it needs more context

<jcraig> s/but sometimes it's not, and screen reader users still need that information/

RS: the live region use case is particularly strong
... When aria-hidden=false is exposes content to AT

Alex: I would like to see some examples and make sure there are other techniques

JC: The other techniques are CSS hacks, and this hack seems to be more understandable than the other hacks

MK: We need something on the aria side to solve the problem
... We need an unambiguous way to make information visible to AT and specifically hidden to visual users

RS: We are not able control of the visual rendering
... Alot of stuff in HTML5 came because we showed them an early draft of aria

MK: There could be an HTML5 attribute for non-visual display only

JC: Accessibility APIs are used by other people than screen readers, such as switch control, zoom, automation, etc.

MK: Problematically to AT and not ever displayed on the screen

JC: I think that is what aria-hidden is doing

RS: I think we need to come to a decision on this?

JC: What is the decision?

RS: That HIDDEN attribute has weak native semantics in relationship to aria-hidden attribute

JC: is that a HTML5 decision?

RS: SF asked that we vote onthis

MK: Do we have a decenter?

RS: Alex do you support SF proposal that HIDDEN has weak semantics?

Alex: What I hear contradicts HTML5 concepts

RS: What we are saying with aria-hidden controls what is rendered to the accessibility APIs

Alex: aria usually defers to native semantics

RS: HTML5 will define the strong and weak native semantics

JC: Do you agree with this use case

Alex: We expose, that particular item is hidden....

JC: If you agree, then without the HIDDEN attribute you would have the same function
... The HIDDEN attribute has to be strong in either case

RS: Alex, it doesn't seem to object
... Does anyone object?

Clown: Is the two choices strong or weak?

JC: You can have no relationship

Clown: In current implementations of HIDDEN is to use display: none
... I don't want the strong mapping

JC: Mapping we would not want it to be aria-hidden false
... If you have it is the weak mapping, that it would still be hidden

SF: If there is nothing specified than browsers can do what ever they want
... My understanding is that Webkit implemented this behavior, it exposes the elements, but not the content

JC: You are right there is a bug

SF: If you use aria-hidden=false it exposes it as expected in most borwser/ats, but not FF

Clown: Are all the use cases all the screen use cases?

<Zakim> Joseph_Scheuhammer, you wanted to ask if all use cases are relevant only to screen readers

SF: I think so

Clown: Accessibility API is not just for screen readers, including magnifiers

JC: Magnifiers use the api to look for hit targets

Clown: Magnifiers also track keyboard focus

JC: This would not allow keyboard focus

Clown: There is an off screen attribute in some APIs

SF: Part of some of the implementations that defining some information of this situation

MK: in the accessibility API

Clown: Sme APIs have it we just need to map it
... It might be in there, i don't have it memorized

RS: Do people have any objects to SF proposal?
... none, resolution that it be a weak binding

<jcraig> ACTION: Joseph to consider mapping the "offscreen" API properties in the situation of aria-hidden="false" on non-rendered elements. [recorded in http://www.w3.org/2013/12/16-pf-minutes.html#action01]

<trackbot> Created ACTION-1320 - Consider mapping the "offscreen" api properties in the situation of aria-hidden="false" on non-rendered elements. [on Joseph Scheuhammer - due 2013-12-23].

RS: thats the first one. we also have the API binding
... in the case of aria-hidden=false do we expose to accessibility API with additional information on being on screen in ARIA 1.1 spec

MK: Are there any limitations on what could be exposed?
... You would have to expose it as part of the tree?

RS: We don't have time to do the details here

SF: if you have a container element with display: none or hidden, you can't expose children, then you have some .....

MK: that's what I want to be clear on

RS: They would apply to the sub tree

JC: It applies to text nodes, element nodes have there own display properties
... A non-hidden element that is inside a hidden element is still hidden
... That can be clarified in the spec

<SteveF> example <p id="h" hidden><span aria-hidden="false">patrick is a knob</span> test 8 html5 hidden aria-hidden="false" on child element;</p>

MK: if you had a hidden sub menu......

<SteveF> the above example does not work

MK: discussion of an authoring situation where people use aria-hidden as a CSS selector

JC: Sometimes authors make error with dynamically changing content not being updated

MK: You retain all the semantics, it works on any elements, aria-hidden=false always override

JC: I will add an action to clarify in ARIA 1.1 spec

RS: We have 2 action items: one for implementation guide and one for the ARIA 1.1 spec

JC: The implementation guide is already there

Alex: I agree with ARIA 1.1 changes

RS: If aria-hidden=false where something is hidden using hidden or display: none needs additional information on that it is not visible

<jcraig> ACTION: jcraig to clarify in ARIA 1.1 that aria-hidden="false" does not override the hidden state of parent nodes, only the current node. e.g. <div hidden><div aria-hidden="false">this text still hidden</div></div> [recorded in http://www.w3.org/2013/12/16-pf-minutes.html#action02]

<trackbot> Created ACTION-1321 - Clarify in aria 1.1 that aria-hidden="false" does not override the hidden state of parent nodes, only the current node. e.g. <div hidden><div aria-hidden="false">this text still hidden</div></div> [on James Craig - due 2013-12-23].

Alex: having an accessible objects for hidden things is not very useful to ATs

JC: are you taking about the accessible name?

Alex: yes, having an accessible object is not useful

JC: Use cases: off screen headers; off screen text in a link

<jcraig> <a href="#">Learn more <span hidden aria-hidden="false">about product X</span></a>

JC: A more complex example is a live region
... There are some examples in the test cases

JG: I can make some examples
... I will send to the list

<jcraig> ACTION: jon to make some examples for aria-hidden="false" (including a hidden live region) [recorded in http://www.w3.org/2013/12/16-pf-minutes.html#action03]

<trackbot> Created ACTION-1322 - Make some examples for aria-hidden="false" (including a hidden live region) [on Jon Gunderson - due 2013-12-23].

<richardschwerdtfeger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23380

RS: I would like to squeeze this in

JC: I have to leave soon

review other aria state mappings to see if they need to be explicitly allowed

Clown: aria-inert

JC: We discuss at FTF meeting?

RS: Ok to discuss at FTF meeting
... Next meeting is January 6th

<janina_> http://www.w3.org/WAI/PF/meetings/2014-01-ftf

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

<MichaelC> http://www.w3.org/WAI/PF/aria-implementation/#intro_aapi

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

FAILED: s/but sometimes it's not, and screen reader users still need that information//
Succeeded: s/ATs/screen readers, such as switch control, zoom, automation, etc./
No ScribeNick specified.  Guessing ScribeNick: jongund
Inferring Scribes: jongund
Default Present: Jon_Gunderson, Rich_Schwerdtfeger, marks, janina_, Michael_Cooper, Alexander_Surkov, Joseph_Scheuhammer, SteveF, Matt_King, James_Craig, Cooper
Present: Jon_Gunderson Rich_Schwerdtfeger marks janina_ Michael_Cooper Alexander_Surkov Joseph_Scheuhammer SteveF Matt_King James_Craig Cooper
Found Date: 16 Dec 2013
Guessing minutes URL: http://www.w3.org/2013/12/16-pf-minutes.html
People with action items: jcraig jon joseph