See also: IRC log
<trackbot> Date: 09 December 2013
<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus
<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-pfwg/2013Dec/0001.html
<jcraig> scribe: jcraig
<clown> UAIG comments: https://www.w3.org/WAI/PF/Group/comments/list?document_version_id=23
JS: accepted comments (will add notes pointing to 1.1)
RS: one comment was "banner should be landmark" (in HTML?)
JS: comments came in pretty late in the process
RS: two features at risk: menu events and click handlers on elements with clickable roles
No ETA for WebKit or IE
MC: mark as at-risk in CR
document; don't have to pull out until January.
... 17 Jan 2014 as deadline for implementation
... Publish PR on 28 Jan 2014
RS: 508 refresh is coming soon, too
MK: Could we move that req from normative to informative
MC: We could do that, if we
modify the at-risk statement
... Another section (text alternative) already lists change
from normative to informative
(2B may be changed to informative)
Clown: tests pass (that one passes now)
<janina> scribe: janina
mc: Need to know by Thursday whether we can remove the "at risk" on name computation
mk: If we add informative option to menu events, we need to do so this week---by Thursday
clown: Will raise this on UAIG call
mc: Joseph can add the note re
ATK/AT-SPI changes
... We have three versions of what the note does ... We need to
decide
[discussion of whether to include a URI, and what that URI might point at]
<jcraig> scribe: jcraig
JC: could use a redirect?
MC: Bad practice to change normative URI
RS: Tell her "We'll start work on it."
<Zakim> jcraig, you wanted to discuss the other at-risk feature: click events on clickable roles and to mention ISSUE-616 at-risk feature
issue-616?
<trackbot> issue-616 -- ISSUE: Review potentially at-risk statement "When the user triggers an element with a defined activation behavior in a manner other than clicking it, such as by pressing Enter, simulate a click on the element." -- closed
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/616
MC: could resolve in HTML
Clown: What about SVG?
RS: SVG 2 has tabindex; this
could go there.
... Though this moves ARIA into the realm of affect mainstream
user interface
Clown: Cynthia wants this section put back in for ARIA 1.1
MC: on schedule, assuming
director approval
... lots of work to do: Jan 28 schedule is aggressive, but
doable.
JS: Need to make sure we're on the ball starting early January
MC: We'd announce PR on publication day: hopeful that's Jan 17th
RS: Rec a month later?
MC: If we get AC feedback and
support, yes. If we get feedback, will be required to address
it.
... optimistically 5 Rec status weeks after PR
... lobby them to vote yes with no comments (best for us)
... if comments needed, encourage including concrete
suggestions
<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-html-a11y/2013Nov/0050.html
Implemented in browsers as: [hidden] { display: none; }
<janina> scribe: janina
<jcraig> coincides with hidden DOM property
rs: Steve intro'd concerns
... I agree this is loosely coupled to ARIA-Hidden
<jcraig> this is totally unrelated to aria-hidden
jc: Reason this is implemented is that every framework has something about this
<jcraig> frameworks implement this el.hide()
jc: Just to toggle display property
<jcraig> el.hidden = true
<jcraig> <el hidden> content prop
<jcraig> el.hidden DOM prop
jc: Change one, the other updated accordingly
<jcraig> [hidden] { display: none; }
<jcraig> default style sheet
rs: There was the discussion about how this relates to ARIA-Hidden
jc: But that's not this bug
<jcraig> http://lists.w3.org/Archives/Public/public-html-a11y/2013Nov/0050.html
<jcraig> "concluded that the spec should say explicitly that hidden='' trumps all CSS."
<jcraig> this is a non-issue for accessibility, as long as the UA has a default rule implemented via display:none.
<Zakim> jcraig, you wanted to explain how/why @hidden was added
<jcraig> <el hidden>
<jcraig> el.hidden = false;
<jcraig> <el>
<jcraig> [hidden] selector no longer applies
<richardschwerdtfeger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574
<Zakim> MichaelC, you wanted to say you could set something to hidden with HTML, override the CSS to make it visible, but the AAPI mapping still suggests it´s hidden, right?
<jcraig> Mozilla tracker discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=945194
mc: TF question potential conflict ARIA vs CSS
<clown> el.getComptuedStyle() - what's the "display" property, if <el> (no hidden attribute)?
<jcraig> ""
mc: Remove hidden returns CSS to
default value
... ONly issue is author overriding to make it nonhidden
<clown> [hidden] {display:block;}
<jcraig> so in author styles: [hidden] { display: block !important; }
<jcraig> I'd call that an author error
<jcraig> MC: and bizarre
mc: Choosing to create an inaccessible situation --- author choice
clown: how inaccessible?
jc: Discussion now to map hidden weak to aria
<jcraig> <el hidden> (weak mapping to aria-hidden)
<richardschwerdtfeger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18574
jc: A separate discussion whether to map weak and/or strong
<richardschwerdtfeger> While I sympathize with Tab's rationale in comment #8 (and had made the
<richardschwerdtfeger> same argument myself in an earlier mailing list thread), I think there
<richardschwerdtfeger> are two reasons to not do this. The first point was raised by Boris in
<richardschwerdtfeger> comment #16: "Making things with @hidden "display: none !important" in
<richardschwerdtfeger> the UA stylesheet would mean web [pages] cannot override the display at
<richardschwerdtfeger> all, ever." Secondly, it's possible for authors to opt-in to such a
<richardschwerdtfeger> behavior by adding this rule to one of their page stylesheets.
mc: Further down Ted says "this
was considered, but we shouldn't do that, imo"
... As I read, Ted does not support !important
rs: So he supports overide?
... So one needs to look at css in addition?
mc: That's our concern when we filed the bug
rs: We don't have an
implementation guide that addresses this and includes CSS
considerations
... An html5 would have to consider the special case for hidden
that can be overridden
<clown> http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements2
<clown> "Elements, including their descendents, that have host language semantics specifying that the element is not displayed, such as CSS display:none or visibility:hidden or HTML 5 hidden attribute."
clown: Above from UAIG 1.0
rs: doesn't address marked hidden but overriden to be visible, which is being allowed by 19277 resolution
mc: H5 wg saying "we don't want
to enforce consistency"
... TF bug asked to mark this as "important"
... We're OK defining this as "author error"
<clown> http://www.w3.org/html/wg/tests-cr-exit.html
rs: but really not
mc: If we don't address this in our docs, we have to live with it
rs: We have to address this in an html5 implementation doc
<jcraig> The resolution should potentially include:
<jcraig> 1. Make it an author error/warning to override the CSS display of elements matching [hidden] in such a way that it "unhides" the content.
<jcraig> 2. Make the @aria-hidden weak mapping to @hidden only apply to the rendered display outcome of the element with all CSS rules applied. (e.g. <el hidden style="display:block"> would not map to aria-hidden="true")
[discussion of whether people like, or ever liked, ARIA-Hidden]
jc: Think we need both to resolve the issue
clown: really like the first
rs: #1 would wcag under
"robust"
... wcag 4.x
... any problem with #2
<jcraig> s/for work/to catch my shuttle to work/
rs: Don't think #1 is enforceable, but can be a WCAG error
<richardschwerdtfeger> ACTION: Michael Take the following text to the WCAG WG as warning or violation under robust "Make it an author error/warning to override the CSS display of elements matching [hidden] in such a way that it "unhides" the content." [recorded in http://www.w3.org/2013/12/09-pf-minutes.html#action01]
<trackbot> Created ACTION-1319 - Take the following text to the wcag wg as warning or violation under robust "make it an author error/warning to override the css display of elements matching [hidden] in such a way that it "unhides" the content." [on Michael Cooper - due 2013-12-16].
<clown> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277
<clown> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277#c21
<richardschwerdtfeger> Resolution: James Craig to add comment to defect 19277 "Make the @aria-hidden weak mapping to @hidden only apply to the rendered display outcome of the element with all CSS rules applied. (e.g. <el hidden style="display:block"> would not map to aria-hidden="true")"
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) Succeeded: s/and …/and click handlers on elements with clickable roles/ Succeeded: s/???/Publication schedule and Timeline/ Succeeded: s/Topic: Publication schedule and Timeline// Succeeded: s/CR/PR/ Succeeded: s/aria-hidden/@hidden/ Succeeded: s/select/selector/ Succeeded: s/and // Succeeded: s/a/e/ FAILED: s/for work/to catch my shuttle to work/ Succeeded: s/enforcable/enforceable/ Found Scribe: jcraig Inferring ScribeNick: jcraig Found Scribe: janina Inferring ScribeNick: janina Found Scribe: jcraig Inferring ScribeNick: jcraig Found Scribe: janina Inferring ScribeNick: janina Scribes: jcraig, janina ScribeNicks: jcraig, janina Default Present: janina, Matt_King, Rich_Schwerdtfeger, Cooper, Joseph_Scheuhammer, James_Craig Present: janina Matt_King Rich_Schwerdtfeger Cooper Joseph_Scheuhammer James_Craig Found Date: 09 Dec 2013 Guessing minutes URL: http://www.w3.org/2013/12/09-pf-minutes.html People with action items: michael WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]