Protocols and Formats Working Group Teleconference -- 09 Jul 2015

<trackbot> Date: 09 July 2015

<MichaelC> meeting: ARIA TF

<scribe> scribe: fesch

Announcements

mc: heartbeats scheduled for next Tuesday
... pubs won't have commits from last week or today

mc: please work with your advisory committee to get their vote in
... sent pings to everyone
... any other announcements?

Issue 722 and Actions 1676, 1677, 1675 Inheritance Cleanup

<clown> issue-722?

<trackbot> issue-722 -- Inheritance cleanup -- raised

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

<clown> acttion-1676

<clown> action-1676

<trackbot> action-1676 -- Joanmarie Diggs to Remove directory as a superclass of tablist -- due 2015-07-07 -- PENDINGREVIEW

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

<MichaelC> https://github.com/w3c/aria/commit/94a5a93939

mc: reviewing action-1676
... related to issue-722
... any concerns about edits for 1676?

<MichaelC> https://rawgit.com/w3c/aria/94a5a9393988b7c15162edb441739669e8dba060/aria/aria.html

stefan: has the changes been tested?

<MichaelC> https://lists.w3.org/Archives/Public/public-pfwg/2015Jun/0178.html

mc: no

<MichaelC> https://rawgit.com/w3c/aria/taxonomy/aria/aria.html

mc: in-spite of the points Joanie makes, I recall that we had a reason for that structure... looking for class diagram

js: is it possible people make list boxes from... is that why we had the hierarchy?

mc: a list box has a list so it inherits from list and select... now we are getting questions on it...

<clown> rawgit.com/w3c/aria/master/html-aam/html-aam.html#el-select-listbox

bg: what do multiselectable items get mapped as?

<clown> http://w3c.github.io/aria/core-aam/core-aam.html#role-map-listbox

mc: ATK exposes a list box as a menu when the listbox is associated with a combobox
... we don't understand why Joanie wants to make this change, we shouldn't accept it for now

stefan: what happens when you remove directory?

mc: list and directory don't have any properties.... however we did it for conceptual grouping not inheritance, so we originally said listbox is a list

bg: a listbox looks like a standard select item, with a list inside of it

mc: I think we should not accept Joanie's edits at this time, needs discussion
... Joanie's 3 rd item

stefan: would be helpful to see before and after the change

bg: would it be helpful to this delay this topic?

mc: scrollbar - sometimes not an input field, but it could be considered a input
... need to talk through the edits with Joanie

stefen: maybe someone observed a scrollbar could be used for input

<clown> joanie's email: https://lists.w3.org/Archives/Public/public-pfwg/2015Jun/0178.html

mc: we will leave the item open for now, look at messages on the list, will put back on agenda for next week (hopefully Joanie will attend for discussion)

Action 1678 aria-readonly should support most form field role types

<MichaelC> action-1678?

<trackbot> action-1678 -- Joanmarie Diggs to aria-readonly should support most form field role types -- due 2015-07-15 -- PENDINGREVIEW

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

bg: I have a problem with that, it sounds weird

stefan: not so weird we have read-only check boxes...

mc: this comes from Joanie from an HTML face - to - face

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

mc: we were talking about readonly recently

bg: I can see that readonly for radio buttons and checkboxes, but

<clown> https://lists.w3.org/Archives/Public/public-pfwg/2015Jul/0046.html

bg: some things can't be selected and readonly

js: I replied on list
... I had a question on slider and spinbuttons... if you can't change it?

stefen: you may not have the right to do so...

<jamesn> +1 to Stefan

stefen: so you may disable a particular control for a particular user
... want to support a readonly state for an input item.

js: you can have a disabled state, but usually you can't focus on a disabled control
... so an active readonly control - what would it do? you could move it but snap back?

mc: readonly text field might exist until you fill in another text field

stefen: it makes sense to distinguish between roles and readonly, and we need to define those now

bg: how do you apply it to a multi select widget?

mc: I think in most cases, it would be readonly some of the time not all of the time

bg: for radio buttons you can't do it without breaking the button. getting focus selects

mc: isn't readonly the same as disabled?

several: NO

stefan: you could have readonly on a container, and it would make everything in the container readonly

js: I thought the distinction is you can't navigate to a disabled control

mc: disabled - it is perceivable, but may not be in the tab order

bg: readonly should make it disabled but in the tab order....

stefen: it should not be in the tab order... otherwise violates HTML...

<clown> is this not possible in html? <input type="range" disabled tabindex="0">

mc: Bryan's example of a menu... where you want to move through it...

bg: idea of having a readonly attribute does not make sense

jn: the needs of a screen reader user is different from a keyboard user...
... tabs don't go to disabled input items, but screen readers do

bg: if you propose doing something different for screen reader users vs keyboard users, you will get pushback

jn: right, doing so can cause all sorts of problems... talking fundimentally

mc: from the ARIA spec perspective - we may need to be permissive... but we have a lot of confusion about disabled vs readonly... the rest of the world will be as lost...
... do we need a white paper on disabled vs readonly?

stefan: can we give you examples?

mc: I think this will be a problem going forward and with the HTML WG...

<MichaelC> ACTION: clown to start exploring content for a potential whitepaper on the difference between readonly and disabled [recorded in http://www.w3.org/2015/07/09-aria-minutes.html#action01]

<trackbot> Created ACTION-1679 - Start exploring content for a potential whitepaper on the difference between readonly and disabled [on Joseph Scheuhammer - due 2015-07-16].

<MichaelC> trackbot, associate action-1679 with product-17

<trackbot> action-1679 (Start exploring content for a potential whitepaper on the difference between readonly and disabled) associated with product-17.

mc: can we accept Joanie's edits on readonly?

js: trying to figure out whether there is any danger in being permissive and then reversing later?

RESOLUTION: accept edits from action-1687

Issue 669 and Action 1674 Need ability to differentiate errors and reference error messages

<clown> issue-669?

<trackbot> issue-669 -- Need ability to differentiate and reference error messages on invalid form elements -- raised

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

<clown> action-1674?

<trackbot> action-1674 -- Richard Schwerdtfeger to Write proposal to the list for error message referencs to live region -- due 2015-07-09 -- OPEN

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

<clown> https://lists.w3.org/Archives/Public/public-pfwg/2015Jul/0022.html

stefan: can show a related error message, like a tooltip role...
... want to have an error msg string... a separate error message

js: thats part of it, wants an id that points to a live region

stefan: there are multiple ways to display errors, is this flex enough to support multiple ways to expose errors
... 1) message post popping up
... describes multiple ways errors may be presented ...
... how to implement directly - to know better what goes on

js: those are APG questions

<MichaelC> close action-1678

<trackbot> Closed action-1678.

stefan: where does the error property be set? on the element input field?

js: yes

stefan: should this be implemented this way? or supported this way?

<clown> <input type="text" aria-invalid="true" aria-errormessage="msgid"> … <span id="msgid" aria-live="assertive"> message text here </span>

stefan: what should happen?

js: describes markup example

stefan: this is already happening, if you use JavaScript... what is the purpose of aria-errormessage? why is this needed?

js: the intended use is to describe the relationship between the input and the error message

<clown> " Typically, this would require the AT user to follow the reference to the error message if needed."

js: that allows AT to follow the error message back to the field,

bg: if you have a description and error message, they may not be the same....

js: errormessage and describedby are similar

mc: so Rich's proposal is - if you have aria-invalid, then you can get why it is invalid
... I assume the errormessage would only be present when aria-invalid is true...
... do we favor the general approach?
... does this solve it more elegantly than other approaches?

js: the errormessage might be in the DOM with display none...
... I assume if you switch display none to block, that is the same as a live region

mc: how will this be mapped in the current accessibility API?
... If we don't have a mapping, then we can put it off until ARIA 2, but if it is a important use case, then we can try to put it in 1.1
... any objections to put it off to 2.0?

js: I think James N. wanted to expand aria-invalid...

mc: aria-invalid is not true false, rather a set of tokens...
... does James consider this critical for the 1.1 timeframe or not and which is more important expanding the tokens or this?

stefan: we also have warning

mc: invalid id is a major feature, but expanding tokens is less

stefan: HTML has no concept of warnings, doesn't mean we shouldn't do it here

mc: we are here to fill gaps... so that is not a problem... does anyone know if it could have mappings? Having a mapping would make it more comfortable for ARIA 1.1.

stefan: who is doing the mappings?

mc: Joseph is leading the mapping....

<clown> issue-651?

<trackbot> issue-651 -- Allow aria-invalid to specify more types of errors including custom errors -- raised

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

mc: big worry - if we take it on, will it be supported in the 1.1 timeframe?
... if there is no mappings, then there is no reason to have this (in 1.1)
... need to stick in spec as a straw proposal...

<MichaelC> ACTION: clown to draft aria-errormessage property for review - may be at risk in ARIA 1.1 though [recorded in http://www.w3.org/2015/07/09-aria-minutes.html#action02]

<trackbot> Created ACTION-1680 - Draft aria-errormessage property for review - may be at risk in aria 1.1 though [on Joseph Scheuhammer - due 2015-07-16].

<MichaelC> trackbot, associate action-1680 with issue-651

<trackbot> action-1680 (Draft aria-errormessage property for review - may be at risk in aria 1.1 though) associated with issue-651.

<MichaelC> close issue-669

<trackbot> Closed issue-669.

mc: next agenda item may be long, will save for next week

Protocols and Formats Working Group Teleconference

09 Jul 2015

Attendees

Contents

Announcements

Issue 722 and Actions 1676, 1677, 1675 Inheritance Cleanup

Action 1678 aria-readonly should support most form field role types

Issue 669 and Action 1674 Need ability to differentiate errors and reference error messages

Summary of Action Items

Scribe.perl diagnostic output