Accessible Rich Internet Applications Working Group Teleconference -- 19 May 2016

scribe jongund

<janina> http://lists.w3.org/Archives/Public/public-aria/2016May/0135.html

TOPICS: jongund

CS: Discussing contact John Jensen

MK: That is a nice development

JS: Nice
... The goal is to get ARIA out in June

CFC for last weeks actions

Actions 1743 2059 1524

<joanie> action-1743

<trackbot> action-1743 -- Matthew King to Put aria-activedescendant on application and request wg review -- due 2016-03-31 -- PENDINGREVIEW

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/1743

JS: There have been no comments, so by default they will be approved

Initiate a review of the spec for feature freeze in June

JS: Goal CR June 16th

MK: I thought it was a psuedo last call
... Feature freeze June 9th
... Before June 9th, everyone do a sweep of the document
... In the editors call we want a top to bottom review
... There is not any time between June 9th and 16th to make changes

JS: It depends on how severe the issue is

MK: June 16th is when all of the issues must be resoloved for pub on June 16th

JS: Please look at the spec top to bottom
... Hopefully there are no major issue
... Any other questions, the usual proceedure to have a final review

Separator role and autocomplete

MK: I'll put a URL in for a branch

<mck> http://rawgit.com/w3c/aria/action2069-separator/aria/aria.html

MK: I will describe the issue
... Issue 1028
... Currently the separator within a menu or content, to divide content

<jemma> http://rawgit.com/w3c/aria/action2069-separator/aria/aria.html#separator

MK: It is the same as HR element in accessibility apis
... It is a scrutural element, but then it also can be used as an interactive sepearator for like movable windows
... You can make it focusable, but AT does not support any keyboard interaction, so keys are not passed through to the application, since it is a structural role
... We just take the interactive language away from the separator role, let separator be separators
... Look at the branch

<Zakim> fesch, you wanted to ask is Matt talking about separator or splitter

MK: I added a splitter role, it might not have time to make ARIA 1.1
... It supports aria-expanded, so I took that off
... I think we need to remove the text either way

<Zakim> joanie, you wanted to ask why ATs cannot look at role + state to conclude that a separator is a splitter

Joanie: My think is about splitters
... I want to stay on que

FE: I took my self off que, my comment is on splitter

MK: Splitter is what we could do to close the gap between separator and the feature need

http://rawgit.com/w3c/aria/action2069-separator/aria/aria.html#splitter

MK: Discussion?

CS: Sounds like at great 2.0 proposal

MK: You want to push it off

CS: It is a good idea, but not enough time to implement

FE: same

Joanie: I have a followup on my e-mail and the implementation issue

JD: The ARIA stack, that is not exposed to AT, all I know is that I can hack around it
... Plateforms already has splitter roles, at least mine does
... User agendt could see it is a separator and tabindex, then map to splitter role, otherwise separator role
... ATs can already deal with this
... This is so easy to implement

MK: I am glad to hear your perspective
... If it is as simple as separators as whether they are focusable, ....
... We do give ATs specific instructions to pass keys through for widgets
... Checkboxes and buttons have default actions

CS: All great ideasare good, but we need to lock down to get implementation

<fesch> +1 to feature lockdown

<Zakim> cyns, you wanted to say that the spec lockdown is separte from implementation. It's fine for Orca to implement even if this isn't in 1.1

<joanie> +1 to lockdown

MK: Is it reasonably implementable
... We only need two implementations

FE: It maybe great, but we have not had a time to review

CS: Joanie can still implement

MK: If we don't make a change in the spec

CS: Browsers and ATs can do exploratory implementation

LW: In HTML 5.1

JS: Can you hear me

MK: Yes

lw: With HTML5.1 we have decided against rushing through substantive new features so close to CR and suggest doing the same with ARIA 1.1

JD: This would go into the core AMMs, a possible solution, not change anything in the spec, change in the AMM
... I don't think we should change the spec
... We will probably not get splitter role in 1.1
... Just change the AMM

MK: The ARIA 1.0 spec that separators can be static and dynamic, but there is not implementation
... We don't make normative requirements in the ARIA spec

<Zakim> joanie, you wanted to respond (but after others can take their turns)

MK: All the spec changes are editorial
... If is focuable you do it this way, if not do it this way
... I will withdraw this proposal, and I will make editorial changes based on JD suggestions

JN: I maybe in correct, but there are plateforms allow separators to get focus in menus

MK: We consider it a mistake when that happens

JN: Thats OK, just wanted to check
... This is not a new requirement, if we can do it in the AAM that is great

<Zakim> fesch, you wanted to say would adding a splitter affect posinset and setsize

FE: Does adding a splitter role will effect posinset, and setsize, if they are interactive then there would need to be a change in the calc

MK: This is only in a window splitter
... I will revise my proposal based on today's discussion, action 2069
... The group has proposed an alternative to 1028, I will run with it
... I will bring it back next week

JS: Sounds good

Any progress on keyshortcuts?

MK: We will discuss in the APG call on monday
... I am on track

JS: That was easy

Issue 2067 aria-owns

JN: I have not had time to get to it

JS: ok

MK: What Bryan sent to the list, there are implementation problems due to the spec language, so it maybe more editorial to clarify
... This is pretty important stuff

JN: When I accepted, I was not sure I had time to work on it

Action 2068

BG: These are not true of other widget roles, children need to have presentational roles

MK: In the action itself

<fesch> action-2068

<trackbot> action-2068 -- Bryan Garaventa to Address issue 1006 -- due 2016-05-19 -- OPEN

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2068

<mck> action-2068?

<trackbot> action-2068 -- Bryan Garaventa to Address issue 1006 -- due 2016-05-19 -- OPEN

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2068

MK: I agrre with ever single one, ATs are already doing this
... Authors and user agents have to be on the same page

BG: The actual link role, exception

<jemma> more info can be found here. https://www.w3.org/WAI/ARIA/track/issues/1006

MK: How would AT know when it present a link know that the link contains semantics, it would have to say complicated link, ...
... We could use our imagination on what ATs could do, it could be mapped differently, you can look inside of the link to see if there are semantics, then some way for people to explore the semantics
... We would need to write some "should" language for ATs

BG: I find it a problem
... I am just talking about structural elements

MK: Does HTML allow that though?
... It can contain block elements, but not interactive elements, have not read for a few years

<Zakim> jamesn, you wanted to ask about combobox

JN: I agree with most, what about combobox>

BG: That was before 1.1, we can take that one out

JN: ok

<jamesn> https://www.w3.org/WAI/ARIA/track/issues/1006

button

img

math

progressbar

separator

scrollbar

slider

JS: FE is on que

GE: The ones I am worried about menu item and treeitem

BG: It doesn't limit us to additional controls, difference between an interactive widget and container

FE: If you put a custom widget, like a datepicker

MK: You can't do that
... You have a menu item that says datepicker and pressing the menu it opens a date picker dialog

FE: What open the menu button?

MK: The menuitem opens the dialog, sometimes ... is used to indicate a dialog

FE: Even in treeview

MK: It is not common, but it could be done

BG: We are talking about non-composite widgets
... Menubar is a composite widget
... It can be rendered adjacent to the ....

JS: WHere are we with this proposal? Is it acceptable?

MK: I think yes, I am working on proposed text, removed combobox

<mck> proposed resolution: Add children presentationaal true to checkbox, menuitem, menuitemcheckbox, menuitemradio, option, radio, searchbox, spinbutton, switch, tab, textbox, and treeitem,

JS: Any objections?

<mck> proposed resolution: Add children presentationaal true to checkbox, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, searchbox, spinbutton, switch, tab, textbox, and treeitem.

JD: I have seen both native and web, that there is an "X" to clear current results, or caps lock indicators, textboxes and ...

CS: All of the edit controls in Windows support these features

MK: When you are making a rich text editor, has to expose the structural information

JS: I have a comment

MK: We don't say anything about host language semantics

JS: Regarding spin button, those web apps and naitve controls, input type equal number, they have incrementer/dec buttons
... They show up in accessibility apis as objects, on purpose

CS: They are needed for touch support
... For some controls they are actually inside

MK: SR users use swip up and down

BG: The right and left is the inc/dec buttons, this works on touch screen devices, button would need to be a compsite widget

MK: Right it is not written as composite, and you need a text box

CS: Sounds like a ARIA 2.0

MK: I think we should leave it in

<mck> proposed resolution: Add children presentationaal true to checkbox, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, spinbutton, switch, tab, and treeitem.

FE: It seems we are changing the issue, because we have not talked about it

CS: Accessibility APIs have changed since ARIA 1.0

MK: I repoposed

FE: I object, we have not thought about it enough

MK: I disagree, this is a long standing issue, and we have been working on it for 6 months

JD: I have concerns about link, some people put a heading inside a link

MK: There is no way to see a heading insde of a link

JD: IA2 provodies

BG: All of the weird things people put stuff in links, without create ghost links

CS: We have dealing with those, it is not valid HTML

MK: DIVs inside of links are valid, but I am not sure about headings,

MB: You can put block level elements inside of links, just not interactive linlks

JS: DO we have a resolution?

MK: Do we need to investigate what is valid in HTML, because I think link is really important to handle, and link is the biggest problem

JD: I support more research and a formal proposal

MK: Is it valid to put a heading inside of a link?
... We need to find out what is valid HTML and what it says, if it allows more we may need to change our link role

BG: I think all the other ones are safe, except link
... Some people make a whole table a clickable link

JN: I have not seen that

MK: We will not allow ...

JD: There is coding example in the HTML 5.1 spec
... Basically it shows how links can used to wrap, headings, tables.....

MK: We need to take link out of the proposal, and we need to figure out what ATs

<mck> Rewritten proposal ...

<mck> proposed resolution: Add children presentationaal true to checkbox, menuitem, menuitemcheckbox, menuitemradio, option, radio, searchbox, spinbutton, switch, tab, textbox, and treeitem.

JS: I hate to here the spec promotes these techniques

FE: Searchbox and textbox out

<joanie> https://www.w3.org/TR/html51/single-page.html#example-17ea2c7d

FE: I suggest that we take a week to look at this

<mck> Fixed ... removed textbox and searchbox ... proposed resolution: Add children presentationaal true to checkbox, menuitem, menuitemcheckbox, menuitemradio, option, radio, spinbutton, switch, tab, and treeitem.

JS: I think that is a good idea

MK: I think it is finally there
... The CFC is about, 6 days of consensus
... If peole have the week to object, and we can discuss next week

JS: We would log a resolution, RS would need to send out a CFC
... I would log it and document FE concerns, rich can decide on the CFC
... ANy object of logging this as a resolution

RESOLUTION: Add children presentationaal true to checkbox, menuitem, menuitemcheckbox, menuitemradio, option, radio, spinbutton, switch, tab, and treeitem
... Add children presentationaal true to checkbox, menuitem, menuitemcheckbox, menuitemradio, option, radio, spinbutton, switch, tab, and treeitem.

Action 2044 presentation role

<fesch> action-2044

<trackbot> action-2044 -- Richard Schwerdtfeger to Separate out text from role="presentation/none" so that a single location may be referenced in core-aam. -- due 2016-04-12 -- PENDINGREVIEW

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/2044

JS: His note says it is important, and suggest move to ARIA 2.0
... Discussion?

MK: Is this just editorial?

JD: One of the motivators, was the SVG spec, to have a single ref

FE: That was one of the things

JD: If we postpone to 2.0, it might impact waht SVG needs

MK: All of the exceptions, there are two many places and put all in one document

JD: My understand that is spread out in the ARIA spec, there needs to be a single link for other specs to reference

MK: That is editorial, you can make editorial changes during CR, if needed since it doesn't change the requirement
... Why do all editorial changes need to be done before CR

JS: we can make changes after CR, but it delays things

CSL I didn' think it did

FE: They can describe what can overrule them, the exceptions need to be put in one doc

MK: I don't see anything in the action about changing the rules

<jemma> Editorial Note regarding the ARIA 1.1 none role. In ARIA 1.1, the working group plans to introduce none as a synonym to the presentation role, due to author confusion surrounding the intended meaning of the word "presentation" or "presentational." Many individuals erroneously consider role="presentation" to be synonymous with aria-hidden="true", and we believe role="none" conveys the actual meaning more unambiguously. Until implementations include sufficient suppo

JS: We want to rewrite it to reduce its size, and that there is not enough time in the ARIA 1.1 time frame

FE: He is talking about ...
... dicussion of all the exceptions of presentation in ARIA ...

MK: I don't want to live with this for the next 4 years if we put it in ARIA 2.0

JS: The question is of resources

FE: How does it affect other document
... HTML has different rules on this rule, and SVG has other rules

JS: CSS maybe different too

MK: Maybe someone not working n testing does this

FE: MC could answer why this is a big deal

JS: It is a thorny issue, we are at the end of the hour

- DRAFT -

Accessible Rich Internet Applications Working Group Teleconference

19 May 2016

Attendees

Contents