ARIA Face to Face Day 2 -- 03 May 2018

<bgaraventa1979> no problem, I dialed into the same number as yesterday

<jamesn> test

<joanie> https://www.w3.org/WAI/ARIA/wiki/Meetings/F2F_Spring_2018#May_2_-_Agenda

Inconsistent support

<jongund> scribe: jongund

MK: There are two things I want to talk about
... One at browser level and one at screen reader support
... What do we consider success for existing CR
... Get feedback on AT experience
... Testing in ARIA 1.2
... We can have browsers pass if they have something in the accessibility API
... If you changed aria autocomplete in your code, would that be reflected by the browser

DM: 10 new roles are proposed, and we map them all to the same APU mapping, therefore it works, but AT cannot distinguish between the roles

MK: There maybe important semantic differences, but the authoring ..., , we can say that a browser passes on a platform, even though the semantics are not available

JD: Is it implemented

DM: It does not test if the semantics are being communicated

JD: We cannot force platforms have was to map all semantics
... Passing means we are doing wwhat the platform says to do

MK: SO maybe for roles,...,
... If Apple or others say this is where it should map, it doesn't mean that it is correct

JD: Who are we to say?

MK: If the semantics are meaningless, it will effect what ATs can do
... We should have something specific to enumerated properties

JD: The other thing is we want to stick with the 2 independent features, so we can't wait for everyone to implement

MK: Test results is maybe more what I am talking about, autocomplete inline and autocomplete both are the same mapping, that should fail

DM: We need something in between pass and fail, we should have partial supported

MK: it would be useful to know about mobile

DM: Let's talk about roles, so if you map switch to checkbox, then let's call that partially supported

MK: That is a good example

DM: Fully passing means all semantics are available
... IAccessible2 and STK-SPI pass through objectAttribute is easier to do
... It is better to have more specific tests
... What about role description or state description

<joanie> https://www.w3.org/wiki/index.php?title=Core_AAM_1.1_Testable_Statements

JD: I am going to setup a wiki page ..., but MSAA+IA2 and ATK-SPI have specific mapping

GG: We prefer object attributes
... Having them as attributes makes the information to us available sooner

DM: There are some requirements are only available through object attributes
... Is the goal, should other platforms do this in the same way, do we want browsers to do more validation

MK: Let's take role description, is only in object attributes

JD: Yes and I use it

MK: If it is only white space or not associated with a valid role, then it should not be passed in object Attributes

GG: If we don't have avalid role, it breaks our logic
... ATs do something different for checkboxes and buttons
... This seems like artificial requirement, maybe in an ideal world, but maybe not in the world we live in

MK: Are you worried that there should be some checking

<bgaraventa1979> What happens in this case?

GG: If the browser is just passing along the author information, whether or not it is valid, if not valid or poor authoring, how does it effect the AT

JD: I have filed bugs with Chrome to do sanity checks

MK: GG it matters , because the author hears button, I think it works, it can be confusing for authors to know if they did it right
... When authors screw up, what should happen, how severe did they mess up and still have something usable

GG: I don't feel strongly about user agents filtering more, in the stand point of the ATs I represent it doesn't matter

JD: We don't have to discuss it now, maybe when we have more AT vendors in the room
... I get mappings from others, we go along, but people don't notice until later and then object, how do we get this earlier

AS: Just ping us, or file a bug

MK: In the new flow we develop the test cases, we write the test cases, we should know every point in the process on implementation
... When we write the test cases, what do we consider a valid test case
... We want to look at 1.0 and 1.1 are they the tests we need
... My goal is that ARIA is as reliable as CSS

DM: There are a couple of differences, whether something is rendered is dependent on the AT
... There are non-screen readers that use some aria, but not all
... CSS defines test as pixel perfect, it is only dependent on the browser
... Here we output some protocol, but ATs do what they want with it
... What if instead of browser to expose something, that some AT does the right thing, the result is does it work in the AT

JD: What do mean about how it does it

DM: Just testing the AAM should not be enough, some AT actually has to use the information to do something different to the user

MK: I did not expect the conversation to take this direction
... I was looking at more consistent mapping of the unique information of ARIA
... I look at it as a multi-layer problem, we look at each layer, but each layer has itts own pass criteria

DM: My only observation is, if only 2 implementations, and IAccessible2 and ATK-SPI allow you to use object attributes, it is not much of a success criteria
... For example, aria-errormessage is not being used by ATs, the spec says I pass, but not useful to users and authors yet
... Web authors like MDN, since they talk about where elements works
... USe alert today, since aria-erromessage is not supported

MK: That is the business of the authoring practices

MC: DM has identified an issue we are concerned about
... The mappings are more like living standards, and W3C does not have process for living standards
... We may want to talk about this more
... We leaned on the mappings to meet exit criteria, but we could discuss more about the exit criteria

GG: We don't advance implement something

JN: The authoring practices can show how to use a feature, and those practices should work in ATs

MK: Browsers should not be dependent on the ATs to implement
... Our plan is that as we write the spec for a new feature, that the practices mirror the authoring examples
... It should feel like the aria equivalent of that in the practices
... Practices have a little of the chicken and egg problem

JN: I don't know if all issues can be in the authoring practices, we need something else for things like role parity

MK: Agenda+ for role parity testing
... We need to know what to do with these new roles
... DM you were talking about MDN, what is a good test and bad test
... Let's make sure we know what practices does now, it should include reference examples to serve as test cases
... We didn't quite make it, we have 25 patterns, and 22 have examples
... There are 59 reference examples
... 6 grid examples, 8 combobox examples
... The examples are intended to be reference implementations, so if they don't work, it is abrowser bug, AT bug or some combination of both
... My goal in having these reference examples, is having the can I use, which of them work with browser+AT combinations
... The next most important priority is developing a score for browser+AT combinations

<Zakim> jamesn, you wanted to say to Matt that we need to version the examples in the APG

MK: To do this developing an objective methodology for testing
... We have a repo for the results, but nothing in it now
... First step is developing the assessments by the end of the year

DM: How many people do we have to do the testing?

MK: After we work out the methodologies, we will pick a few, we will work with working group members and vendors to do the assessments
... We can do assessment jams, teams of three people per platforms and with AT+Browser combinations
... It can't be automated, but we need a process to insure consistent support for the semantics

GG: I think it is a good idea, I have some concerns, I am concerned about reputations being hurt

MK: I share that concern

GG: We want to make sure vendors are part of the discussion

DM: Does that change our exit criteria?

MK: My goal on this topic, do we need to review our current tests, are the tests a source of the inconsistency of communicating semantics

JN: If something is not mapped at all...

MK: DD example of switch being mapped to checkbox, should be considered a partial implementation and acceptable

JN: We do not have everything we need for switch now, in terms of labeling

JD: Let me offer a different approach, how do we distinguish a switch from a checkbox, if the mappings in the core AAM are unique, the mappings

JN: If not mapped, then that is a failure

JD: If they say in UIA is not mapped, we either need to get them to implement the feature, or remove the feature

MK: We can use that result through the practices
... That's useful to authors, are there HTML that...

DM: There are ployfills to get features implemented more consistently

MK: For example, hotkeys is something that Apple said they would not implement

JD: All of the tests are what is in the core AAM

MK: I need to review the core AAM

JD: That is the mapped not mapped problem
... All things mapped to group, we call that partial implementation
... Just treat not mapped as a failure

MK: In our reports can we generate partial implementation?

JD: Yes I will figure that out

MK: I want to go back to the AAM to find these gaps, is a 1.3 issue

JD: Someone should go through the AAM to find the not mapped and redundant mappings
... I do not think the tests is our problem

JN: The issue is making sure the AAM is waht we want

JD: We need to make sure that the AAM is accurate

JN: I will go through and identify the not mapped and where there are not unique mappings

<jamesn> JD: have the browser vendors and the Api owners

<jamesn> JD: it is the owners of the mappings

<jamesn> DM: should we ask apple to make a distinction between the platform and the screen reader

<jamesn> ... small amount of AT on the Mac now - should we ask apple to have mappings which VO can ignore but others can use

<jamesn> ... android a11y apis have things which Talkback might ignore - but that is out of our hands as the user agent

<jamesn> MK: talking specifically where same owners of platform and AT

<jamesn> JD: hypothetically object attribtues

<jamesn> DM: could consider throwing it into the spec

<jamesn> JD: for the AAMs we want apple to come to us and give us their version of the object attribute

<jamesn> DM: suggest we approach apple from that standpoint.... would webkit consider exposing them - but not expose them in safari ....

DM: I am suggesting the platform ...

JD: The platform maintainer needs to provide mappings

*** break ***

Where CSS effects the accessibility tree

<jamesn> https://bugzilla.mozilla.org/show_bug.cgi?id=1005271

MK: Exhibit A issue

JN: There is some recent work

MK: By default CSS should never effect the accessibility tree, unless there is specific ARIA requirements

DM: That cant happen, there are more than 15 examples I can think of that effects the rendered content
... CSS is an active group and very active, you propose an opposite way

MK: There is no spec that says how CSS effects the accessibility tree
... If we don't know how CSS effects the accessibility tree it effects the development of practices

GG: Github uses markdown and that is not rendered ass tables but looks like tables visually
... So that is the bad thing

JN: That is a 4 year old bug, I filed it

DM: This is an example, there is a reason why it is done this way, it is just a bug

DML There use to be a lot of layout tables, browsers were trying to figure out if it a layout table or a data table

DM: I think what you are asking for is browser giving you a hint if it is a layout or data table
... Identifying a table from the CSS is complicated
... Example of calculating table ....
... If we try to do it we are duplicating other code in the browser, we want to query the other code
... It an author has choosen, to layout a table as not as a table, then we need to computer indexes

GG: It maybe a flawed table

DM: If it is not laid out as a table, then there really are not indexes

MK: Colcount and rowcount ...

DD: That is not heard, the default row and column index is the harder part, and we want to get this from the browser table layout code

x/DM/DM

DM: We want to render what is visually shown

MK: When I use INSERT+F it always says lowercase and normal text, but I can't tell the CSS that has been applied

JN: Somethings are arcroymns ...

DM: This is not reflecting what is in the screen, some authors can override with label

JN: I don't like that
... Labelled by itself
... That is an interesting using aria-labelledby

MK: Your not convincing me that we should not specify

DM: We just ask the rendering engine what is the final rendered text, there are issues with white space or remove it
... I a paragraph we do not include whitespace

MK: If you want to override list..

JN: Don't use a list in the first place

MK: Maybe there was reason to use list for selectors or ...
... By putting padding on elements, it added space and separated content form being concatenated

GG: If we go through the HTML5 spec we can review each element, that is pretty finite set of things, CSS is a lot more complex

MK: I didn't know the number of places that CSS effects the accessibility tree, the issue is not to allow CSS to effect native semantics

DM: I think rather than define where CSS does or does not apply, it is more important to say if an element is rendered, the HTML element should be definite in defining the role, unless that is an exception
... We use the aria role if it is provided
... There is not a strong mapping of the table element being represented as a table role, it is dependent on rendering

<Zakim> MichaelC, you wanted to ask if we´re tackling generated content in this discussion

MC: We have nver really sorted out the CSS issues of rendered content, but it is an issue for the CSS working group, and there needs to be coordination
... It is a join task force between aria, APA and CSS, but only one active member

DM: Flex box lets you render the cells in a table in reverse order, should the accessibility tree represent this

MC: That is a big issue in the task force

DM: If the tab order seems to be the main consistency issue

<MichaelC> CSS Navigation project in CSS TF

MC: It is a issue for several CSS specs

MK: It is a three way task force, but few active participants
... We have 4 high impact bugs for several years

JN: It is fixable now by the author by using role=table

JG: You put role table n a table?

JN: yes

DM: We have made some progress in fixing this

AS: It is a low priority to fix

MK: I hope we are beyond this being a low priority

AS: We are working on this bug

DM: If any part of the table is missing we can recompute
... We are looking at more cases and trying to improve our fixing the bug
... We only compute when we have to, ...

GG: Lists are another problem, we want to give users information about what is on one line
... There is a tension as something as a list and a navigation bar that users want to get past
... We want to make it easier to navigate over

DM: I don't know what the problem is

GG: JAWS thinks every new link is a new list item

DM: Check display: inline or block, whould give you some items, it does not tell you if they all fit on line, ...

GG: We are now getting into how to solve this problem, is it good to should something as a list, if it does not look like a list

DM: The layout of a list is less important that it is a list, lists are much simipler than tables
... Maybe we should just move on there and let us know the priority of fixes
... AS and I have more bugs than resources to fix, so we need priorities from the community to help guide our resources
... This includes aria features, if people are not using something it doesn't seem a priority to implement a feature
... When people use DIVs and use CSS to make them look like tables

JN: they should add the table roles
... I would like mode of trust me, I know what I am doing

GG: We are trying to implement that type of feature
... If we embark on this will you help us

<MichaelC> CSS AAM placeholder

<Zakim> MichaelC, you wanted to mention CSS AAM

MC: The CSS task force could address many of these issues

DM: I think we could create some general guidelines, like when CSS transforms text that should be respected, since that's what is rendered graphically

MK: CSS does not make the final call, when aria-hidden="false" overrides display="none" text
... Does that go into the same guidance

DM: ARIA overrides CSS
... The current state of flex box, is that it does not effect the accessibility tree position

JN: The issue with tables is in a responsive design, when screens get small, then it does not look like a table anymore
... CSS is being overridden to change the rendering

MK: You should be able to change the ARIA

JN: You want to do it all in CSS

DM: We have implemented the consensus, we should document the rules and fix current bugs

MK: The CSS joint task force could start with a note on what browser do now

JN: The action is to get task force working again

MC: The CSS people need help form this community to help them get started on the problems
... We could start a CSS AAM, we can work with Ian to get it started

DM: What is you could set role with CSS

JN: That would be awsome, but that was rejected ...

BG: What about aria-owns ....

DM: I wonder how much push back from validators

JN: We talked about it, not sure the discussion

MC: That seems to bleed the separation of style and content even more

DM: I like AOM is proceeding is parallel, I think this is something kind of similar, a mini sister spec

MK: It sounds like what MC said is to get a person to be on the CSS task force

DM: I would be happy to help someone drive this

MK: I think Ian needs more input

MC: We need someone from ARIA to push it

DM: We need to get the AS, Edge, WebKit and I to talk about his issue
... Maybe a video conference, to hammer out a draft and some point FTF to make language

MC: Are you willing to be the driver?

DM: I want to be in the room

MK: I don't think if I have time right now
... What do we mean by driver
... Maybe Jemma
... What does being a driver mean?

JN: I can help her

role-description

JN: Will take on contacting people about the CSS task force

MK: start with application role, since it effects role-description

<mck> http://w3c.github.io/aria/#application

MK: We are being hounded in the APG to get some examples
... There are people wanting to use it, the language to discourage use is not effective
... Some of the sources of confusion
... IN ARIA 1.1 it states: is a structure with one or more interactive controls that are not defined in through other role patterns
... GG do you have any questions about the definition

GG: In 1.0 is a container for more than one control, and in 1,1 it is a widget that cannot be described by other roles

MK: continues reading spec...

JN: It dependents on your definition of element

GG: I should of fought this more, this should say that the information available to the virtual cursor is confusing and therefore let author ...
... I am fine with the 1.1 wording

*** lunch break **

<jamesn> yes david

<dmazzoni> Scribe: dmazzoni

JN: There are a number of problems in the name calculation - complexity, implementation differences, etc.

DM: note that it's definitely a lot better than it used to be, and Bryan's examples really helped

JN: whitespace is one big issue - where to insert
... biggest issue is complexity

MK: I think we could write it more simply but we couldn't simplify the algorithm itself
... but we do have practical issues
... The most common thing authors are confused by is name from author vs from content

JD: The code is very complicated - especially the recursion - and 90% of the time we never need any of that

BG: It needs to be that complicated

MK: I just learned that you don't need to put aria-label on a tree item, because the name calculation for contents doesn't include the group
... "Hidden complexity that results in simplicity"

BG: I don't see any way around that

GG: I just want all browsers to make as much wild content to work as well as possible

DM: Let's focus on the whitespace issues

Bryan created a GitHub issue

<jamesn> https://github.com/w3c/accname/issues/16

Brian's issue just adds some comments to the algorithm, it doesn't propose a fix exactly

We're discussing the issue, trying to decide if we agree with all of the proposed fixes

or rather, the issues identified

Question: when should we ever NOT add whitespace?

Examples include spans to make something underlined, or an image for a dollar sign or decimal in a number

Should alt and title be treated differently in terms of spacing?

JD: "Be consistent with the rendered text" is a better logic

Since title is rendered separately, we should add spaces. Since alt *is* the image, we shouldn't add spaces

We need to consider whether an element is inline or block when deciding whether to add whitespace

Because the name calculation algorithm needs to handle display:none elements, you can't figure out if something is block or inline

BG has proposed test cases for block vs inline css generated text

The name calc changes should be in accname 1.2

We're going to move on to discuss aria-roledescription

<jamesn> scribe: jamesn

MK: role application - a question received... right now in the spec there is some language that implies that the application role can be applied to an element which is focusable and represents a custom widget

the definition itself says it is a grouping container...

we have actually found cases from the feedback that the implied idea is sensible... can focus something which has role application - it may or may not use aria-activedescendent.... example is a chart which is a single focusable element... only the chart is focusable... aria-roledescription and aria-activedescendent to point to things inside which would get annopunced

whatever interactivity you support for the chart widget.

first question is can we support this set of expectations for the application role.

would we have to change anything for this to work

JD: thought we had discussions to add to 1.1

MK: 2 ways to render application

example - http://www.oracle.com/webfolder/technetwork/jet/demo/demo-pieChart-default_element.html?demoTheme=none&baseTheme=alta&formfactor=desktop

MK: div aria-roledescription is slider...buttons etc... application may have aria-describedby with instructions
... a different thing from the chart where you are only interacting with 1 element....

JD: role application - orca just lets everything go to the browser and will speak based on widgety stuff.... difference between reading mode and other

pressing next item - reading mode keys. in the case of the container will come to something that says start of slide editor, buttons etc. and could read through that

different from 1 thing on the page when reading through it... wouldn't go inside it

want to make sure that can have this thing which is either a grouping element or an individual widget

would be great to have guidance for screen reader developers.... have

DMD: have a select box and the framework hides the select and shows a custom list... jaws does not move through the items

MK: not lefgit use according to the spec
... is this ok to recommend both

DM: don't think need anything from the useragent

AS: agree

DM: mostly a question for AT vendors

GG: doesn't seem controversial to me

mk: instead of a chart want to make a superbutton

role=application aria-roledescription=button

would drop into forms mode -

GG: this should not be application - should be the closest thing to what you are trying to override
... will say the name of the thing followed by the role... we make decisions based on the role.... if we are going to replace the role with roledescription.... the user needs to be able to know how to interact with ity
... could have a tutor message to say - works mostly like a abcd

MK: is incumbent upon an application author...
... not much different from the chart - but you are using application to trigger forms mode on an element

GG: afraid of role description - going to become like the Wild West...
... need the usage model to be close to another control.

DM: how is it worse than any other author error thing.... with a screen reader hat - use a description to add the other information.

MK: don't want to hear application when tab to Gantt chart

GG: can't do that as 6th time don't want so much text

<bgaraventa1979> I once had a client put role="Albert" on an element.

DM: what I am saying is that this is a custom control of some sort

MK: aria-interactive was proposed but can't remember all the nightmares
... I was a strong proponent but after trying to argue for it - I got turned against my own self
... there were a boatload of problems

DM: don't see how any complaint about aria-interactive wouldn't apply to this

MK: don't want to make a big investment in practices - can put strong guardrails in the APG about roledescription.

GG: think long and hard about role application. if choice is no additional information give some

MK: I'm a little reluctant to use role-description for things like that

JN: my 4-way slider

JD: if you call it button rather than super button

BG: we saw this when Stefan was asking... aria-roledescription is not a description of a role

MK: still a new feature... could consider a synonym in aria 1.2

JD: NVDA, Orca and I think VO support it
... back to guidance question.... if the behaviour is the same... if make a super listbox

and put some extra cool stuff in it... but if override button and make it go into focus mode then this is a specific case where guidance should be don't use roledecriptiion of button... if tell user its a foo and it doesn't act like a foo then don't do that

MK: role application is to get forms mode

GG: taking away semantic information

JN: child of role application.
... then still have button semantics

GG: I viewed application as being a container

controls in the container consume keys

MK: in 1.1 we implicitly added this concept where adding the overhead of a container
... things from the real world - Stefan wants to use role application extensively and wants to fall back on some guidance

JD: thing that concerns me that is hopefully solved by workflow - conversation now is are the things In 1.1 valid....... doing authoring guidance as part of feature development will solve this kind of thing

MK: yes

JD: this will never happen again

MK: ytes
... aria-customrolename or something

DM: reason I like roledescription is that it implies you must have a role

MK: wojuld like to spend 10 mins to ask about AOM related thing

hover/tooltip pattern

MK: tooltips that include interactive content... biggest issue is getting focus into them... Most common way is a special key - but no one can agree on the key... primary reason the tooltip pattern in the APG is not here

a gaping hole - but don't agree what should be there... does AOM provide something for us

DM: I have a philosophical objection.. I see AOM as orthogonal to aria... aria's role is to define semantics... AOM is to allow to manipulate the semantics from JS to make the DOM look like what is should
... when can't make the visual and semantic the same

dont't want the case there AOM is used cause there is no way too create DOM which would work.

MK: worried about usability and discoverability of tooltips for screen reader users.
... tooltip has interactive content.... context menu to get keyboard users maybe... possibility if we could detect the screen reader click. if click with a screen reader

DM: we give a permission dialog - for this kind of event
... I don't think this is perfect
... James Craig gave a good example - slide to unlock....

GG: 2 different actions when you happen to be in virtual mode
... when it is acceptable to be in forms mode.... 2 scenarios whether in forms mode or not

DM and GG leaving

<melanierichards> just gave status update on open MS Edge questions from yesterday about HTML-AAM: 1) no special reason for us to be exposing more info about ruby and colgroup, likely just what seemed reasonable at the time 2) open to resolution of having a specific role for fieldset, we would still map semantically as ControlType: group but provide more details thru localizedControlType (similar to what other implementations are doing)

<joanie> ttps://github.com/w3c/aria/wiki/Plans-regarding-role-parity

<joanie> https://github.com/w3c/aria/pull/718

<joanie> https://w3c.github.io/html-aam/

<joanie> https://github.com/w3c/aria/pull/718/commits/5e68010ab23f4b4f0927f15243aae8d913771a6b

<joanie> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity

<bgaraventa1979> apologies my battery is dying, will need to dial in tomorrow

ARIA Face to Face Day 2

03 May 2018

Attendees

Contents

Inconsistent support

Where CSS effects the accessibility tree

role-description

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output