See also: IRC log
<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
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> 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
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
<richardschwerdtfeger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23371
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
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[End of scribe.perl diagnostic output]