<trackbot> Date: 14 July 2014

<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus

<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-pfwg/2014Jul/0019.html

<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-pfwg/2014Jul/0019.html

<scribe> scribe: LJWatson

Heartbeat draft comments

MC: Haven't put them into Bugzilla yet.

<MichaelC> consider modding aria-haspopup definition in 1.1

RS: One bug was about haspopup relative to dialog boxes.

MC: Will add to Bugzilla and provide a link.

RS: We have an action on this?

MC: It was filed as a public comment.

JS: We have a Bugzilla bug, but no action as yet.

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

RS: There should be a corresponding issue?

JS: We don't require that.

RS: We have issues, actions and defect lists - need to tie things together.

MC: No automated way to tie together.

RS: Ideas?

MC: This bug was filed on future, so will move to 1.1.
... Use the version field to change from "Future" to "1.1".

<MichaelC> ARIA 1.1 bugs: https://www.w3.org/Bugs/Public/buglist.cgi?list_id=40679&product=ARIA&query_format=advanced&version=1.1

RS: We need to look at 1.1, and the API mapping guides as well.

<MichaelC> ARIA 1.1 Spec bugs: https://www.w3.org/Bugs/Public/buglist.cgi?component=Spec&list_id=40681&product=ARIA&query_format=advanced&version=1.1

MC: The URL I pasted includes both.
... We should include the URI for the bug within action items.
... Action items relating to bugs should include the bug URLI, but we shouldn't create bugs just for action items if a bug doesn't already exist.

RS: Will make sure we reference this bug list.

MC: Won't do anything on this particular bug until the WG arrives at a decision.

RS: Do we need to respond to the comments before the next public working draft?

MC: It's better to do that, but we can/should respond via the bug - although there is no formal obligation.

RS: Think we should respond, so we avoid a backlog.
... Objections?

MC: We should add externalComments keyword to these bugs.

<MichaelC> https://www.w3.org/Bugs/Public/buglist.cgi?keywords=externalComments%2C%20&keywords_type=allwords&list_id=40683&product=ARIA&query_format=advanced&version=1.1 Bugzilla entries that are also ARIA 1.1 comments: https://www.w3.org/Bugs/Public/buglist.cgi?keywords=externalComments%2C%20&keywords_type=allwords&list_id=40683&product=ARIA&query_format=advanced&version=1.1

RESOLUTION: Group agrees to respond to public comments before each working draft is released.

MC: We may need to add another keyword once we have a formal response.

RS: You want to create the response now?

MC: Can do.

RS: Do we want to craft a response now or wait? Perhaps wait?

MC: Think we should wait to see how it relates to others.

Issue 602

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

RS: James has asked for a role property to indicate a CAPTCHA.

JD: This is like password fields. If we have a way to figure it out.

RS: An optional text box attribute?

MK: Yes.

<clown> <span role="text" aria-captcha="true"> ?

MK: Usually have key echo off, but turn it on for CAPTCHA.

<clown> <span role="captcha"> … ?

LW: Agree with Matt.

JD: Could be a screen reader option?

MK: Yes.

RS: Looking at textbox - we want to add aria-captcha?

MK: hascaptcha true/false?

JS: Are there other use cases?

MK: Don't want to be too generic - like echo on/off for example.
... Would screen reader users want to treat password and CAPTCHA files the same way?

LW: Are we trying to solve a problem that can already be dealt with by the screen reader/user?

MK: Think the use case is for automatic configuration.

BG: Might be useful for live chat scenarios?

MK: Yes, but opposite desires.

JS: May want to think about this more.

JD: The original use case seems to be catering for non-advanced users.

JG: One problem is that no-one will use it - it's flagging the presence of a CAPTCHA to bots.

MK: Author resistance is a good point.

LW: Think this would confuse less experienced users - key echo is on by default, turning it off by default for CAPTCHA will be unexpected and require a certain level of knowledge to know why/change it.

RS: Don't ccrawlers already know a CAPTCHA is present?

JS: Think authors will rresist an "over here" sign on the page though.

MK: With a vote here/now I'm a -1 on this.

JS: +1

LW: +1

RS: Group consensus - close issue 602?
... Hearing no objections - security issues and lack of clear benefit for less experienced users.

JN: How do we solve this problem?

MK: The consensus we came to is that there isn't a problem. There's no clear preference for key echo on/off in this situation.

<richardschwerdtfeger> This was closed at the July 2014 ARIA caucus as people felt the security people would not want to apply this and because this would add confusion for new users. Not all end users of this feature, on the call, agree that they would want the feature to disable key echo because people would desire different preferences. This would be an advanced user preference. People agreed that we would not want to change the behavior for novice users.

RESOLUTION: Close issue 602, per minutes from this call.

<clown> issue-65-?

<trackbot> issue-65 -- Should we merge them? -- closed

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

Issue 650 and 545

<clown> issue-650?

<trackbot> issue-650 -- Need a "local" token for aria-live (only hear announcements when on or in this region) -- raised

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

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

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

<clown> issue-545?

<trackbot> issue-545 -- Resolve live region and aria-relevant conflict between spec an UAIG. -- open

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

RS: Request not to hear updates unless focused on the live region.

MK: The announcement of the live region would be conditional on focus location. May not need to be within the live region, but instead at a specific alternate location.

RS: Could be expensive for browsers.

JS: You could change the live region status dependent on location of focus.

RS: The browser would still need to fire the event.

JS: But the change in value could be author driven.

JD: Don't think we check when the page loads whether the live-region status changes.

<clown> http://www.w3.org/TR/core-aam-1.1/#mapping_events_state-change

RS: aria-live is a property, but don't knnow if there is a state change for it.

MK: Seems like an edge case.

RS: Once the page loads ATs are not looking for aria-live state change.

<clown> http://www.w3.org/TR/core-aam-1.1/#mapping_events_state-change

RS: This would not be a trivial thing to add.

KN: Instead of a state change, what about removing the live region and adding it back?

RS: That would work.

JN: We could do with some clarification around removing/adding live regions.
... Something for the authoring practices?

MK: If the spec is clear on the intended AT behaviour.

RS: What about aria-busy?

MK: Can't use aria-busy because Jaws removes anything that's marked as such from the virtual buffer.
... So with Jaws, you're unaware there is a busy area on the page.

RS: What about a different string value - true/false/paused?

MK: How is that different?

RS: So the content would still be present.RS: The paused value would indicate the content of the aria-busy area was still valid.

JD: What are the other use cases?
... If the region is focused, Orca might already be handling it, have to check though.
... What about an existing relationship like aria-controls - although Orca doesn't presently recognise that.

<Zakim> Joseph_Scheuhammer, you wanted to note that the core-aam has no event mappings for chaning the value of aria-live

<clown> "Indicates that updates to the region should not be presented to the user unless the used is currently focused on that region."

MK: The description of aria-live="off" sounds like it solves the issue, no?

RS: What does Jaws do with the off value?

MK: If the VC is on what's changing, you'll be aware of changes.

RS: If you move from assertive to off, does it remove it from the DOM?

MK: No.
... The spec wording seems clear, and I think Jaws behaves per spec.

RS: Ok, but what about announcements only when focus is in another specific part of the page?

MK: The way this issue is worded, the spec already addresses it. If the issue is intended to represent a more general case, we might need to look at it.

RS: Objections to aria-live being the solution to this issue?

<jongund> md

MK: Removing/adding the live region works for the wider use case, but it's not elegant.

JS: Accessibility APIs are sensitive to content changes.

RESOLUTION: Close issue 650 as it's supported by aria-live="off".

RS: Do we need to add authoring practices?

JN: Something about adding/removing/changing live regions, yes.

<clown> http://www.w3.org/TR/core-aam-1.1/#mapping_events_visibility

<clown> http://www.w3.org/WAI/PF/aria-practices/Overview.html#LiveRegions

<scribe> ACTION: Nurthen add text in ARIA 1.1 Authoring Practices to explain how to manipulate live regions and when they cause ATs to speak or not speak. [recorded in http://www.w3.org/2014/07/14-aria-minutes.html#action01]

<trackbot> Created ACTION-1482 - Add text in aria 1.1 authoring practices to explain how to manipulate live regions and when they cause ats to speak or not speak. [on James Nurthen - due 2014-07-21].

BG: Per a quick test case, Jaws seems to detect attribute changes to live regions in the DOM.

MC: Product 24 is ARIA 1.1 Authoring Practices.

RS: Will save issue 545 for another time.

<clown> issue-578?

<trackbot> issue-578 -- Figure out why aria-readonly is not on more roles, like checkbox, radio, etc. -- open

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

Issue 578

MK: This gets into the discussion of disabled v. readonly?
... One of those semantic discussions.

RS: We need someone to make a proposal for this.
... We don't have readonly on a column header for example. Action would be to identify other places where readonly should be applicable.

<clown> http://www.w3.org/TR/wai-aria-1.1/#aria-readonly

RS: Can't see why you'd want readonly on a radiobutton.

MK: Inherits on columnheader

RS: Suspect we'll go into this in more detail with the word processing work.
... Buttons, links, logs...

MK: Not on links. Would be crazy to hear readonly on a link.
... A log is a structure ,not a widget - don't think readonly makes sense there.

RS: Log is basically a live region.

MK: It still falls into the structure part of the ontology.
... I think we actually have it covered.

JS: What about exporting parts of a log?

RS: That wouldn't apply.
... Might have haspopup on something that could be edited.

MK: Putting readonly on elements that are not designed to be editable adds annoyance for AT users.

+1

RS: Do people think we have this covered?
... Any objections to closing this on the basis we believe it's covered by the spec?
... Any objections to closing this on the basis we believe it's covered by the spec, and that haspopup could be used to present the user with an option to edit instead?

MK: We already have readonly on all editable widgets.

RESOLUTION: Close issue 578 as solved by current spec, with haspopup as alternative method for enabling user editing.

BG: Shall I send through the test case cose for the live regions?

RS: Please do.

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/change fom/change from/
Succeeded: s/JS: One problem is that no-one/JG: One problem is that no-one/
Succeeded: s/JS: Seems like an edge case./MK: Seems like an edge case./
Succeeded: s/JS: APIs are sensitive/JS: Accessibility APIs are sensitive/
Succeeded: s/applicable?/applicable./
Found Scribe: LJWatson
Inferring ScribeNick: LJWatson
Default Present: Rich_Schwerdtfeger, Leonie, Joseph_Scheuhammer, +1.603.882.aaaa, Michael_Cooper, Joanmarie_Diggs, janina_, +1.415.624.aabb, +49.322.110.8.aacc, +1.541.678.aadd, mattking, Jon_Gunderson, James_Nurthen, Cooper
Present: Rich_Schwerdtfeger Leonie Joseph_Scheuhammer +1.603.882.aaaa Michael_Cooper Joanmarie_Diggs janina_ +1.415.624.aabb +49.322.110.8.aacc +1.541.678.aadd mattking Jon_Gunderson James_Nurthen Cooper
Agenda: http://lists.w3.org/Archives/Public/public-pfwg/2014Jul/0020.html
Found Date: 14 Jul 2014
Guessing minutes URL: http://www.w3.org/2014/07/14-aria-minutes.html
People with action items: nurthen

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.