ARIA Face to Face Day 2 -- 01 May 2019

<CurtBellew> scribe: CurtBellew

<carmacleod> https://github.com/w3c/aria/issues/893

ComboBox 1.1 pattern issues - how to resolve?

<jamesn> https://github.com/w3c/aria/issues/893

mck: quick refresher of 1.1 srt combobox

mck an edit field like a text box and that text box could open a list box

and the list box was owned by the text box

the list box had to be inside the textbox

mck we wanted to fix it so the list box could be visible outside the txt box

mck then extend it to allow things like trees and grids in the lst box

mck: compromise 1.1 - a container would hold the two pieces
... eg spin button that would contain all the pieces
... container contains the text box and the list box
... label would go on the container
... the text box would inherit the label
... that doesn't happen right now. do we want to change the spec so that we just label each part in the wrapper ? <-option 1

option 2 -> change it so accname is retrieved from the wrapper.

and the components also have labels

option 3 -> change the accname calculation so that the contained inputs get their label from the container

mck: spinbutton can contain a button. most spinbutton are usually written so that the label is onthe input. but the spec has it so the label can be on the parent
... there is a similar situation wrt to this proposal : spinbutton

bg: spin button is a composite widget? mck: yes
... the challenge from the name computation is to account for both that doesn' exclude one or the other

jamesn: simplest approach seems to be use the same text for the label

Glen: JAWS in browsers other than IE
... we actually speak all the items in the hierarchy that are changed
... works well for items in a grouping. if you want to hear the name of just the focused control adfter you have once heard the group name

jamesn: anything in the hierarchy is read if you change?

glen: yes

mck: @ glen: JAWS is coded that way - should it influence this decision?

glen: given the nature of the web it's a cause to pause for thought
... shouldn't impact this decision though
... drop down portion should get the same label

mck: isn't it really better for the user if the popup has a nice label

glen: why not leave the container and give it a layout role.

mck: keeping the combobox wrapper is almost like other comosite things like a grid
... similar to a table. rows and columns have labels also.

glen: requiring labels on all three will mean some 'creative' labeling

jamesn: what do other AT do?

joanie: same thing. read the hierarchy

mck: others seem to do the same thing

jamesn: so this isn't really a problem?

glen: the drop down portion won't have a unique label so that's an issue

mck: the wrapper pattern isn't really supported yet

<Zakim> jamesn, you wanted to ask Joanie what orca does in this situation?

bg: recommend the ability to label the input. one problem is that the combobox is written is that you could have anything in the drop down
... anything. radio buttons ,anything
... how to find and label the correct thing is difficult at best
... label the input and the combobox
... the combobox region and the listbox then are differentiated
... makes the most sense to me from a usability sense and wouldn't require a rewrite of the accname spec

bck: great example. in that all three things have a unique label

bck = mck

mck: the problem is in making the labels all unique
... what if all three were given the same label

bg: AT could filtre them out and say one instead of both

jamesn: maybe the recommendation to label them all the same isn't bad

bg: usability wise. the combobox is treated like a single line control. everything is flattened out to be a single form field.
... change it to be more like a region. you could use the arrow key to see the parts

mck: right, taht was the goal. to see them all separately

glen: what if the combobox isn't expanded

mck: then the combobox wouldn't be visible at all
... sounds like we're landing on changing the combobox spec slightly.
... the combobox has name required true. supports the aria-label and aria-labelledyby
... so maybe we just have to change the example
... if you were to read the spec for edit box and list box they already have it

jamesn: change the suggestion to make the labels all the same?

carolyn: AT don't even recognize that you've entered a combobox
... some detail comes through but that's not revealed to the user

mck: jsut an implementation detail now. we haven't worked with the AT developers to fix that so we can use that pattern

jamesn: we really need to do that

mck: yes
... no need to wait on that

jamesn: hopefully any example in the APG is now solid enough taht if you see it and feel it's not supportable by AT we need a bug
... that answer @ glen
... recommendation is to label all three with the same label

carolyn: we need to make sure that ATs understand the reason for redundency

mck: we should do some examples of both same label and different labels
... we've seems examples where both are a good idea
... leave it to the ATs to decide how they want to handle it. if the labels are they same text they decide

joanie: it could be that the AT isn't getting the focus change event that carolyn is asking about

bg: the way the combobox role currently works. if the events aren't correct then the AT won't know
... my concern is taht we don't want to break what works in 1.0
... my worry is about messing around with how the events are triggered

mck: @ bg - don't break backward compatability?

bg: yes

CurtBellew: a checker will test taht each field has an input. duplicates are definitely allowed but they have to exist? #@mck

mck: yes
... the tihng that triggers the events is the input.
... the aria expanded spec is pretty clear
... an input text field that controls a list box then the input has aria controls
... aria expanded should be on the edit

carlyn: be careful with that.

carolyn: we have them that are impleneted with a span instead of an input
... @glen works great with JAWS

mck: doesn't follow the spec for combobox

or aria expanded

mck: it's an accident that it works

carolyn: works within nvda as well.

mck: that's ok - the combobox role should be on the wrapper
... if you have a separate text box role then you aren't using the 1.1 pattern
... the 1.1 pattern aria expanded and aria controls are on the element with the text box role
... and focus

should go to the textbox role

mr: looking at ui automation documentation and i don't think this change will work here
... the expand and collapse are expected on the main control. so I don't think this change will work

mck: @ how does that work? examples in other non-web places

mr: I'd have to find some examples

mck: in 1.0 there really isn't a text box because the text box is what has the combobox role

mr: in the tree it's combobox parent with listbox children. were you expecting a flatter structure?

mck: @melanie. 1.0 has a textbox with the combobox role
... it's all one thing. inside is a text box with the combobox role. inside it also is the listbox. so there is no textbox at all in side it (because the text box has the combobox role)
... in 1.1. The wrapper is the combobox. inside that is the text box and a sibling ot that is the listbox
... these are all distinct. individually labeled
... in 1.0 only the one thing is focusable - the combobox. that's where active descendant comes in here.
... in the case of 1.1. if aria expanded is on the outer wrapper - it doesn't control anything

glen: why can't the text box control the wrapper

mck: the popup isn't a descendent of the text box
... in teh case of the 1.0 combobox the list box is that aria active descendent of the text box
... 1.1 they are siblings. so we rewrote the active descendant spec to indicate that it can be a a child or a sibling

bg: what I've been telling people to do is if ou have a 1.1 design pattern and you change the aria controls it works

mck: if you do the 1.1 pattern without the combobox on it things work very well. but ...
... @ melanie - probably the reason why aria expanded is where it is because it causes problems for everyone other than UIA
... it really does work better on all the other platforms

glen: is there a prohibition on having aria expanded on both ?

bg: we have two different designs patterns. using aria active descendant on the input. using role list box have aria expanded on it
... you aren't actually setting focus to the role expanded element

<jamesn> cb: you were saying Matt that if you followed the 1.1 pattern and put all the stuff on combo it works well

<jamesn> mk: yes if you put it all on the edit box it works well

<jamesn> mk: aria-autocomplete tells you it has autocomplete

<jamesn> mk: to support mentions could have a multi-line input with autocomplete. Random places in a RTF with an @ sign

<jamesn> cb: when you enter the field AT will announce like in a standard list box

<jamesn> mk: select size 1

<jamesn> cb: one of things I come across are combos and have to check what kind of combo it is.... things which don't have baggage on them would be nice

<jamesn> ... I don't know that this is part of the design pattern though - it funxcitons but just kind of works

<jamesn> mk: we just haven't done it yet in the APG but have talked about things

mck: @mr. are you objecting?

mr: yes. there is a chance that we could talk to them and ask if things can be changed.

carolyn: formal objection
... my read only combobox pops up a dialog and the dialog will change the value of the input

jamesn: we don't have a formal proposal. so instead of saying we have objections on the table is inaccurate.
... they would be objections if we had the proposal

mr: yes

joanie: aria expanded is a state so AT can deal with that. but not everything can

mck: options button expanded and options button collapsed. that's how it works and that's what users expect

joanie: it's on the button yes
... on other platforms that are not UIA. other platforms can deal with this is that we don't have a pattern. these are togglable things or expandable then the pattern isn't exposed
... those are just states that can be checked for. there is no interface for UIA, as I understand it

mr: combobox control with the input text with the aria expanded state would mean mapping something to an element that it's not on. the aria expanded isn't on the combobox but ont he text box
... I'd have to talk to developers about that

<Zakim> joanie, you wanted to share a possible implementation solution

joanie: I think I have a solution
... for the expandable state for mr platform. if we ascend the hierarchy then we get the combobox. we then find the input with the aria expanded. go back up the hierarchy to the combobox role

jamesn: if it'sn ot found then it's an error case?

joanie: yes

jamesn: can it be with aria owns or not?

joanie: yes

mck: 1.0 pattern. nota problem because comboboxes are expandable
... multi line edit field.

something like a drop down that will show on a trigger. slack allows an @ to point to somone in particular and will provide a drop down

joanie: @mr - in that case what kind of api does exist in UIA?

mr: I'll have to look in to that

mck: @ joanie: from an implementation you tihnk we might be able to make the adjustment to the 1.1 pattern? aria expanded on the input that is

joanie: yes.

mr: consistency across everything that consumes this API. I'm worried. UAI now has a proxy that allows clients that are using UIA to interact with IA23

IA2

mr: does it create complications for AT clients as well

mck: one other question before going forward with this. a 1.0 pattern and a 1.1 pattern. rather call this a bug in the pattern and keep it as a 1.1 pattern. not the 1.2 pattern

jamesn: confusing to have a 1.0 and a 1.1 pattern. they all should work

bg: glad you brought up that. it is allowed just not documented. we have a lot of patterns that are allowed in the 1.0 spec
... We hav ethings that aren't documented because we aren't changing the 1.0 spec. people assume that the 1.0 spec and 1.1 spec are totally different. that's not true

jamesn: true we should document that

mck: we can document things that are hybrid but do actually work
... we didn't build APG with all of these examples
... can we consider this a bug in aria 1.1? the fact that aria expanded is on the combobox instead of the input

<carmacleod> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm

mck: the bug is to correct and put the aria expanded on the 1.1 spec

carolyn: link is to bg aria combobox read only. same as what I'm talking about
... this comcobox works perfectly with AT. we are talking about rewriting this one

mck: in 1.0 the combobox owns everything. so taht is the 1.0 pattern

bg: the reason this works is because it contains aria-owns. i use aria controls
... that's why it works

carolyn: @bg : so this example is a 1.0?

bg: yes

mck: move forward calling it a bug

jamesn: can you create a PR

mck: yes

mr: can we rewind to why we're doing taht?

mck: it's what has focus. and the spec says we put that on the controlling element

mr: the spec actually says you can it on both

mck: that's issue 681. we have an item to discuss that

CB: in the 1.1 pattern where does the aria owns go?

mck: implementation perspective it doesn't matter.

bg: if you're using the 1.0 pattern. don't use aria owns

mck: forward with the pr so support aria expanded on the text box

jamesn: for that we need to file implementation issues etc

carolyn: it'll be on the combobox for the 1.0

mck: yes

mr: we would need to file an issue on core aam

<jamesn> GitHub: https://github.com/w3c/aria/issues/893

Differences between modal and non-modal dialogs

<jamesn> scribe: jamesn

<carmacleod> https://github.com/w3c/aria-practices/issues/1021

GitHub: https://github.com/w3c/aria-practices/issues/1021

bg: problem having is that role dialog seems to automatically assume it is always modal
... restricts reading focus into container
... aria practices says to do circular tab order.
... problem is that we have some non-modal dialogs which don't fit into other widget types... popups, overlays
... help icon that opens up a div etc.

there may not be a close icon but because it has active elements is not a tooltip either

gg: do you need to close b4 you interact with other stuff?

bg: no
... that fits the non-modal paradigm better than anything else. fro now named regions seem the best way that works
... practices has lots of verbiage which says non-modal need to be tr=eated like dialogs

gg: how can non modal confine you?

mk: a dialog in aria is intended to be a window - something that is consxtraing, When reading inside the window don't want to read stuff outside the window.
... difference between nonmodal and modal is that everything else is inert. non-modal is more like spellchecker in word... when you interact with it it has its own tab ring - but you have no need to close it can go back to main window and do stuff
... can continue working - can leave the non-modal open and interact with stuff inside and outside.
... in native apps can move back and forth - haven't settled too much in aria - no pattern. Comments window next to document - list of comments which are being made and want to go the point in the document references by comment - there should be ways of moving back and forth which are relevant to the dialog as well as a key.
... in some cases don't have to go back and forth if a mouse user - mechanism we don't have right now in screen readers for non-modals is the ins+F10 for windows itself... list of windows etc.
... the defining feature of the dialog is that it has boundaries
... the top of a window , not all the way to the top of a giant thing
... other kinds of patterns - some cases you might want to use a dialog - once focus leaves it it can disappear.... your solution of a named region that appears at the right place in the DOM makes sense

bg: I'm ok with doing that but don't have anything in authoring practices
... a soft dialog

mk: a form of tooltip etc....

bg: problem with tooltip is that they don't convey things
... critical aspect of these sections

mk: groups or regions are better
... tooltip region we haven't defined maybe?
... or enhance def of tooltip so more useful
... tooltip role has no use

bg: I agree

<Zakim> jamesn, you wanted to ask about aria-modal

bg: the way screenreader work - aria-modal false

mk: purpose of a window is to restrict user to that area

jn: kind of like a properties pane
... a region landmark for examopkle
... tooltip has little purpose

gg: does jaws restrict non modal dialog focus or not?

bg: have seen this - modal where focus is not restricted and opposite where non-modal does restrict

mk: need element type where window that parallel where everything you read is inside a window but you can move outside it
... want to be able to stay only within the source

gg: jaws does restrict you

mk: can use ins+r to get out

bg: a lot of users don't know that ins+r can get you out. changing mode to let yourself get out

def of modal has nothing to do with screen readers

s/def og/mk: def of/

bg: in a keyboard trap if don't know...

mk: may be an a11y bug
... can't accidentally create a keyboard trap
... app says that non-modal has to restrict focus
... also have to be able to move out of it

bg: in a way that doesn't need lots of extra keys

mk: how to support non modals well for users

bg: right now not discoverable
... non modal dialog, once invoked the outside content is not discoverable

mk: I think those are screen reader problems

bg: when outside of a dialog and arrow down just says dialog - and none of it seems to work right

mk: how do you give access to both places? these problems are already solved elsewhere
... this is F6 etc - this is why ins+f10 in jaws etc... but none of these work on the web yet
... non modals are not supported on the web
... unless there is no reason to interact with both bits of content at the same time. like notifications dialog - overlays notifications on the page.

<Zakim> jamesn, you wanted to ask why not just a landmark then and to

jn: trying to clarify modal vs non-modal vs region

bg: exactly the problem - comes down to discoverability
... how do you know things are there

mk: there are problems with non modals on the web
... unsolved problems
... one of the reasons apg does not have the pattern
... use cases exist
... the one you are describing bg I don;'t think is one of them
... they wouldn't offer any useful info

bg: why not?

mk: wouldn't have the benefit of a window - only defining charactersirtc that sepeatates non modal from a region

bg: encountered so many times - if don't know something is there it is completely inaccessible;e

mk: problem with non modal windows today
... if people are using dialogs where navigating outside is critical shouldn't be using a dialog

jd: could use a non modal dialog BUT APG needs to sort it out
... using thesaurus example - say F6 is best practice what would then happen is that focus would go back to content discovered .... that is what meannt to happen

mk: yep

jd: when aria "dialogs" appear will show up somewhere in the tree - where everything else is is up.... we can do the thesaurus example or find/replace
... don't want to cliose the dialog -if solve the focus manageability then screen readers do the right thing

mk: in VO has a list if windows
... jaws has a list of windows across the system
... not windows in a browser

jd: like the list of windows

gg: having something switch focus to the area is necessary

<joanie> jn: The reason I have previously used regions for non-modals is for things like iOS.

<joanie> jn: You don't have an F6 key so you can instead use the list-of-landmarks feature

<joanie> jn: It's not necessarily a tiny screen

<joanie> mk: There is a long list of issues with non-modals that just haven't been solved on the web.

<joanie> mk: If you want a non-modal experience on the web today, you're kind of stuck with it having to be a region.

<joanie> jn: I'm wondering if a non-modal dialog should be a landmark.

<joanie> jn: That allows a screen reader user to use its standard functionality.

<joanie> mk: Moving to the top/bottom of a landmark region is kind of hard.

<joanie> bg: I use those commands all the time

bg: have had regions and landmarks for a long time
... discoverability

mk: what I think is important is a semantic that says this is not a region but is a window

JD: landmark navigation - screen readers are not storing location of a previous landmark... nothing to switch back to

mk: has a split view controller - on iOS - doesn't do a fabulous job of keeping in current view
... that concept is kind of existing - iOS inside of safari - they don't map things the same way they do natively

<joanie> jn: I'm still having a really hard time working out what the difference is between a region of the page and a non-modal window is.

<joanie> jn: Many non-modal dialogs can be dragged and become regions

mk: when look at the virtual buffer and if it had every window as a region

gg: win 32 apps were convenient as you were much more guided
... one control was a window - you were locked there
... have sprawling complicated webpages where many users overwhelmed - if can bracket things into containers
... dialogs have semantics to lock you - there are keys to move in and out of regions

bg: how would novice users know to do this

gg: was hoping there would be info to help someone

mk: would be possible for verbose modes of screen readers to Read things.

bg: that doesn't really happen in native apps
... f6 is already taken
... can't hijack browsers

gg: would love if tabbing didn't include browser chrome
... also release F6 for us to use

bg: something so process intensive F6 allowed me to get out of it

mk: chrome fixed a bug where tab bar now in f6 order
... I use f6 constantly in chrome

jd: bookmarks is in a panel

hs: could a pattern suggest to use a simple control like a button to move from pane to pane

mk: could have a hotkey assigned to it
... if thesaurus is open move focus into thesaurus

general consensus is that this may work in some circumstances but not applicable to many more

Accname simplification and white space issues

<mck> jd: At last f2f in Toronto, discussed white space and consensus was that

<mck> ... when colapsing whitespace, go with how appears on screen. If white space is on screen, include in name, but collapse if not.

<mck> Some UA are have some unspecifed white space logic.

<mck> They may already be doing this, maybe not exactly the same, but some could pass a new spec that does this.

<mck> BG: agree

<mck> Brian working on prototype that does this.

<mck> Difficulty is describing the algorithm at spec level.

<mck> Need consensus on the results for specific test cases.

<mck> jd: How long might it take to have a draft of spec text to put in AccName spec.

<mck> bg: Not sure where this fits into the description of the accname algorithm

<mck> ... kind of papplies to the whole thing

<mck> For instance, it doesn't matter how the text itself is included, aria-label, aria-labelledby, label, etc. this white space insertion applies.

<mck> jd: any place where it says append result with a space is where yo put it. It might have its own algorithm for determining if white space is needed.

<mck> mk: will ths be easier if we simplify first?

<mck> jd: separate topic that will apply no matter how simple the presentation of th ealgorithm is

<mck> This should be in first PWD of AccName 1.2

<mck> bg: next thursday could have sme for consideration

<mck> jn: regards to simplification, why can't we do that

<mck> It could be possible we break some backward compatibility.

<mck> Look at places where we do noto have consistency, if that is because of complication, maybe we consider removing the complication to get rid of the inconsistency.

<mck> We would be breaking something that is already broken.

<mck> bg: If we leave any kind of ambiguity, it leads to issues. So, clarity is a priority.

https://www.w3.org/TR/html52/tabular-data.html#forming-a-table

<mck> jn: HTML examples of algorithms

<mck> considering what other specs do for algorithms

<mck> bg: There are so many if, and, or logical statements, it is difficult to make clear in prose.

<mck> It has an established structure, like 2f, which is meaningless. But, other specs refer to them.

<mck> jn: if we want to make it simpler, we cannot constrain ourselves to that structure.

<mck> Other specs should be pointing to a TR version.

<mck> jd: It is not our job to be on top of how other specs reference or quote our spec. If we know that we are breaking something, we can riase an issue or pr for that spec.

<mck> jn: An individual step is not relevant without the whole.

<mck> Other specs should probably not refer to a specific step.

<mck> bg: When we remove the ambiguities and inconsistencies, the result may be larger but still be simpler

<mck> jd: anything would make the possibility of infinite recursion go away would really help

<mck> That's where we need simplification the most.

<mck> bg: I experience the same thing.

<mck> Its really hard to track

<mck> jn: Thtml table formation algorithm is literally a table of spec

<mck> it code put into words

<mck> is that good?

<mck> mc: I don't think should be the olnly representation of the algorithm

<mck> jd: If I cna't figure out what the name is going to be by looking at my own code, then I think there is a problem.

<mck> jn: how many of the things that are really hard really exist in the wild? Or are they just our own test cases that do not rep things that really exist.

<mck> bg: when writing the code for the algorithm, if the algorithm is robust, if the code is robust, it doesn't matter how complex the real world implementation is.

<mck> jd: Not sure we can truly simplify

<mck> My fear is that most or all use cases are valid

<mck> jn: the ones with lots of recursion I wonder if they are valid in real world

<mck> bg: recursion is not necessarily complex, 1 level or 100 levels are equally simple

<mck> gg: If you simplify, how can you avoid breaking things?

<mck> jn: Suggesting we only simplify where things are already inconsistent across across browsers

<mck> bg: Example is aria-hidden='false'

<mck> jn: If we removed that case and simplifies, maybe we should do that since it is already broken

<mck> mk: aria-hidden=false works in IE ... was decided that display:none and aria-hidden=false should show content to screen readers at f2f in toronto 4 or 5 years ago.

<mck> still does not work anywhere else today.

<mck> maybe we should get rid of that feature if it simplifies.

<mck> bg: firefox ignores it

<mck> jd: good that we are adding name from encapsulation, legend, but that does not simplifiy

<mck> jn: It's a separate branch, that is isolated

<mck> jd: it could be combined with other techniques

<mck> jn: maybe we should disallow aria-labelledby pointing to somethat gets its name from encapsulation

<mck> bg: it would work

<mck> gg: James is saying that you shouldn't have two levels of redirection, right?

<mck> jn: perhaps

<mck> gg: it seems right that legend or encapsulated labels should be able to be combined with other techniques

<mck> jn and jd: Brian, when working on rewrite, do not hold yourself to the current structure

<mck> bg: proposes a specific idea for the structure, asking if would be more simple

<mck> jn: anything is worth a try

https://code.fb.com/android/android-accessibility-debugging-with-stetho/

<mck> gg: the complexity is not in number decisions is it?

<mck> isn't it the number of things can be chained together?

<mck> bg: Explains some example of complexity related to both recursion and condionality

<mck> Melanie: I'd like to make aflow chart ... just want to give it a try

<mck> could include examples

<mck> mk: we are creating accname light explained in APG

<mck> it will have examples

<mck> jd: but implementers still have to understand every detail

<mck> bg: authors do not have to understand how recursion works to use aria-labelledby

<mck> gg: only when things do not work as expected

<mck> jd: so we will have a flow chart and white space inserted

<mck> jn: and we will look at bugs and decide if simplifying the algorithm could fix them. It might break a correct implementation of the complex version but eliminate a bug for an implementation that did not implement the complex version.

<mck> discussion of adding role label and label from encapsulation and how much complexity that could add.

<mck> When adding new stuff, try to find ways of preventing usage that adds complexity.

role parity - List types

GitHub: https://github.com/w3c/aria/issues/961

<mck> jd: general topic, not list type, we have some things where parity achieved achieved, some with none, and some partial

<mck> UL and OL have partial parity. We have one role for both.

<mck> Is that enough?

<mck> Anoter option is to add an another attribute.

<mck> Joanie triaged all the partial parity issues and suggested attributes for each.

<mck> The goal now is to decide whether these partial parities issues need resolution.

<joanie> https://github.com/w3c/aria/issues/961

<mck> First talk adding an attribute for distinguishing UL from OL

<mck> jg: Has anyone aksed for this ability to distinguish?

<mck> gg: we would like to continue to have this disctinction. today we have to look at the tags.

<mck> jd: Orca doesn't, but this could make it easier for me to make it do it.

<mck> jn: Glen what do you do differently?

<mck> gg: can't tell you why we actively need to know diff between UL and OL

<mck> Would like to have the info available to JAWS.

<mck> jn: if no one is doing anything with it today, why provide it.

<mck> gg: get your point. But, the only way we can get the info today is via the tag.

<mck> gg: give hypothetical reason

<mck> In word, we optionally identify the bullet type.

<mck> jg: wyswyg editors allow you to picka type

<mck> jn: you can tell the difference from the items.

<mck> gg: other thing we can use it for is flexible web

<mck> there we key on what the tags are to disambiguate

<mck> every bit of info you have makes it easier

<mck> jd: If there is a custom list then you would not have the tag to distinguish

<mck> gg: could there be a possibility of having a single attribute that applies to multiple roles that would give this more specific descriptive info

<mck> cm: authors can turn off the bullets, and numbers but might want to keep the semantics

<carmacleod> +1 to add aria-listtype

Straw poll: do we need aria-listtype

<joanie> 0

<HarrisSchneiderman> 0

<melanierichards> +1

<mck> +1

<CurtBellew> 0

<bgaraventa1979> 0

<jongund> -1

<Glen> +1

<joanie> +1

<HarrisSchneiderman> update: +1

<carmacleod> +1

<HarrisSchneiderman> https://github.com/w3c/aria/issues/960

text attributes

<joanie> https://github.com/w3c/aria/issues/960

GitHub: https://github.com/w3c/aria/issues/960

<mck> Proposal for an aria-textattribute property.

<mck> Mostly for generic roles.

<joanie> abbreviation

<joanie> address

<joanie> bold

<joanie> italic

<joanie> keyboard

<joanie> mark

<joanie> preformatted

<joanie> quote

<joanie> strikethrough

<joanie> sample

<joanie> small

<joanie> underline

<joanie> variable

<mck> Except for abbr and address, these are all about what text looks like

<mck> In attempt to reduce number of attribs needed, included those two.

<mck> Do we want na attrib to expose this formatting stuff?

<mck> gg: what is the alternative?

straw poll do we want an attribute to expose at least one of these?

<mck> jd: They do not get exposed, exposed through existing platform API text font or format, which would not happen in canvas, for instance.

<joanie> +1

<HarrisSchneiderman> +1

<carmacleod> +1

<Glen> +1

<CurtBellew> +1

<melanierichards> +1

<jongund> +1

<mck> +1

<joanie> So given foo, we'd just have one generic element?

<mck> gg: do not want a generic role where the text run has different attributes on each char in the run

<mck> jd: let's say it is a single attrib run.

<mck> +1

straw poll 2: is text attribute a space seperated token list (+1) or a single string (-1)

<Glen> +1

<HarrisSchneiderman> +1

<joanie> +1

<jongund> 0

<carmacleod> +1

<CurtBellew> +1

section type

<joanie> https://github.com/w3c/aria/issues/963

GitHub: https://github.com/w3c/aria/issues/963

<mck> jd: doen't like the name sectiontype

<mck> found some sectiony things that may have the generic role

<mck> thead, tfoot, header, footer, has partial parity

<mck> Some forms are not landmarks but AT may care about a from that is not exposed

<mck> Not voting on name, just concept of whether we need an attribute that

<mck> does this

<mck> -1

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

<joanie> Section without name is mapped to all platforms as divs

straw poll: should we have a "section type" ish attribute

-1

<joanie> -1000

<carmacleod> 0

<HarrisSchneiderman> -1

<bgaraventa1979> -1

<Glen> -1

<mck> -1

<CurtBellew> 0

Partial parity triage needed

<joanie> a (no href)

<joanie> bdi

<joanie> bdo

<joanie> dfn (currently it is mapped to term)

<mck> jd: pretty sure a11y apis give correct offsets in rtl langs

<mck> leaning toward leavin these alone.

<mck> gg: not using

<mck> jn: is there an internationalization group we can contact

<mck> Melanie: seems academic at this point.

<mck> all: group leaning toward no action on these now.

input type

<HarrisSchneiderman> github: https://github.com/w3c/aria/issues/962

<mck> jd: Do AT need to know that it is an email input or url input? partial parity is textbox role.

<joanie> Create dedicated roles for them (e.g. because input type='color' is a very distinct widget type from input type='date')

<joanie> Punt on them until 1.3 because technically the type attribute of input is an HTML attribute, and attribute parity is the main focus for 1.3.

<mck> currenlty exposed as object attribut in webkit and gecko

<joanie> Add an aria-inputtype (or something like that) property now.

<joanie> Some combination of the above.

<mck> Don't know what we are doing with date picker and color picker. diff UAs do in different ways.

<mck> We could do different roles for each one.

<mck> Or, could punt until 1.3 because these come about because of the type attrib on input.

<mck> Or, maybe could have roles for some and attrib for some.

<joanie> color

<joanie> date

<joanie> datetime-local

<joanie> email

<joanie> file

<joanie> month

<joanie> telephone

<joanie> time

<mck> Curt: asking if this is complete list.

<joanie> url

<joanie> week

<mck> jd: all but password

<mck> jd: already have total parity for input type checkbox and radio.

<mck> gives background on password role, so not going to include it.

<mck> This is list is either we do not have full parity or it is not password.

<mck> bg: sees value in exposing email and url because some kebyoards change keys they expose based on that.

<jongund> https://github.com/w3c/aria/pull/951

<HarrisSchneiderman> scribe: HarrisSchneiderman

description lists

<jamesn> GitHub: https://github.com/w3c/aria/pull/951

jongund: the biggest discussion at this point is naming these 3 roles
... the other part is the 2 other roles: term and definition. I believe when they were originally conceived, they were meant to be a part of this pattern
... potentially out of sync with html's dfn tag

mck: it seemed like everyone was leaning towards option 2 - not reusing

<jongund> https://raw.githack.com/w3c/aria/issue504-description-list-roles/index.html#descriptionitem

mck: the more I was looking at it...it seemed like the arguments were that we needed to add list semantics
... and that the list semantic was as important
... a list item is made of at least 1 of each dd and dt
... there was concern that definition and term, because they don't have a list semantic, they do not distinguish themselves adequately from dfn and term
... is it a bad idea to have a role which, when used inside of a def list, and otherwise not

jamesn: the other complexity is - we've had a hard enough time defining the existing ones (term and definition)

jongund: with the current proposal it is really clear what these roles are for
... It'd be hard to use these incorrectly

mck: the naming is unfortunate. the term definition is loaded in the accessibility world

jamesn: we shouldn't use the term that html has rejected
... I'm not opposed to coming up with something different though...

carmacleod: what about "dlist"?

mck: I was trying to avoid the word description
... aria-describedby...the way we talk about descriptions of elements...

joanie: "termlist"?

jamesn: according to the spec, it represents an "association list"
... we definitely shouldn't use term and definition

mck: "listitemname" and "listitemvalue"

joanie: thats why I'm thinking "dictionarylist"

carmacleod: "associationlist" is pretty generic and applies to all of the above

jongund: I can see the confusion with "description"
... the closer to the tag we name it, the more likely developers are likely to use this properly

joanie: we should definitely be in favor of documentation...but as a developer, if you have to go find/read to figure out what a thing is then we've done it wrong
... whatever we come up with should be a self-contained thing and "dlist" is not

jamesn: on the other hand, if someone is using this, they better be reading documentation

mck: the only thing people will find intuitive is "dl"
... "assocationlist" seems like a good candidate to me
... my only request about the things inside (children) is that I think the rolename should start with listitem to avoid confusion
... to avoid "Is this the first part? or the second part?"
... It can be any combination of <dt />s and <dd />s within the item
... appending the 2 different things with "listitem" will make purpose clear

glen: can you put listitem term inside of a plain list?
... it doesn't make it clear that the key/value belong in the associationlist

mck: this is complicated because we have 2 different things that can be within an item
... Think "menu" and "menuitem"

jamesn: are we good with what is in the current PR?

melanie: in html aam definition list maps to list, dt maps to role=term, dd maps to role=defintion. so why are we changing it now?

jamesn: the 2 above have a use still (outside the scope of dl)
... dfn maps to term, which is maybe wrong

mck: to answer melanie, it'd be too complicated to write the definition role so that it can be used both within and outside a list

melanie: maybe its a bug within aam if/when we add these

mck: the one thing it should not be a "descriptionlistdescription"

joanie: thats why i like key/value

bg: what about the actual word "definition"?

jongund: html5 rejected it

mck: "descriptionlistitemkey" / "descriptionlistitemvalue"

parent would be "descriptionlist"

joanie: does this role need to be contained within some sort of "descriptionlistitem"?

mck: this is just like "menuitemradio"/"menuitemradiocheckbox"

melanie: I was thinking "keyvaluelist" "keyitem" "valueitem"

mck: in reality, theres no excuse for not using a p tag instead of role=paragraph

jongund: there are other ways to do this in html...if you read the dfn element spec, you can use it to identify the term and the <definition> is contained within that
... and all of the above would be contained in a list item

mck: the reality is that no one will type these attributes

jongund: what would AT call an "associationlist"?

glen: I'd call it an "Association list" because that makes sense from a technical perspective

<jamesn> <dt><dfn>Apartment</dfn>, n.</dt>

<jamesn> <dd>An execution context grouping one or more threads with one or

<jamesn> more COM objects.</dd>

<jamesn> <dd>A deflated tire.</dd>

<jamesn> <dd>The user's login directory.</dd>

jongund: Lets ask this again to screen reader creators: what would AT call an "associationlist"?

mck: in the FAQ case, theres no way for JAWS to know that we've got questions

jongund: when you render a dt...do you tell people you are on term x of y?

bg: from a user perspective, I'd like to see AT saying "term" and the name (content) and arrows would take you to each value that would apply to that

jongund: the benefit of the user of these is that they'd hopefully be exposed to this useful information

bg: they need to differentiate these

glen: this is going to break things...older versions of screen readers will not be compatible
... it depends on what the platform maps it to...
... if we map it to something new, this could be problematic

joanie: in terms of acccessibility APIs, for the most part there haven't been many new roles created
... For atk, its role descriptionvalue

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

joanie: for the above aam definition: the dd element wai-aria definition role

mck: so the above definitions occur within lists...melanie would you know this type of thing?

<joanie> https://w3c.github.io/core-aam/#details-id-16

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

bg: in my firefox example, looks like the dl element maps to role=list, dt maps to role=listitem, and dd doesn't map to anything

<joanie> https://w3c.github.io/core-aam/#details-id-75

joanie: there is no spec here saying that these things map to a listitem

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

mck: option 1 is don't create roles for the things inside of the list

bg: theres value in distinguishing these
... its not so easy to identify where the term is and where the value is

glen: i don't think jaws currently distinguishes these

jongund: what does jaws do with role=definition / role=term
... it seems to me that if it is a definition list, you should be able to use list item navigation

jamesn: We seem to have a number of things here...creating the role parity with the current dl,dt,dd can be separated from how well browsers/AT support them
... what we need to come up with here are the names of these attributes

melanie: what if we create a couple different options and ask for dev feedback?

jamesn: <head shaking no />

mdk: if you see it in code, you want to understand what is going on

jongund: people shouldn't really use these roles anyway...

"associationlist" is at least similar to whatwg html spec...

mck: can people live with "assocationlist", "assocationlistitemkey" and "associationlistitemvalue"

hs: are we all agreeing out of exhaustion??

melanie: what I worry about more after seeing "associationlist" and not realize that they are dealing with a dl alternative

jamesn: do we have a conclusion?

jongund: what about the our definition role and our term role?
... you have some type of container element (li for example) and inside you have a term

<jamesn> definition = A definition of a term or concept. See related term.

<jamesn> Authors SHOULD identify the element being defined by giving that element a role of term and referencing it with the aria-labelledby attribute.

joanie: we'll need a PR to fix these tables

jamesn: are the mapping in html amm correct?

joanie: yes

ARIA Face to Face Day 2

01 May 2019

Attendees

Contents

ComboBox 1.1 pattern issues - how to resolve?

Differences between modal and non-modal dialogs

Accname simplification and white space issues

role parity - List types

text attributes

section type

Partial parity triage needed

input type

description lists

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output