Meeting minutes
Address PR status
Matt_King: 1st 3 are lightweightfixes to examples
Updated disclosure button for FAQ and Image Description examples by jongund · Pull Request #1814 · w3c/aria-practices
Matt_King: If there are visual changes need to look at WHCM and other contrast
Matt_King: in 1814 what needs reviewing?
Matt_King: code changes - needs code review
jongund: was a separate PR which was done automatically for inline SVG
jongund: inline SVG in the CSS files was done elsewhere
Matt_King: small amount of doc changes under a11y features
<siri> https://
jongund: need to look at in light of chrome
jongund: proposed changes in thermostat
Matt_King: are there WHCM changes in this that model the thermostat slider one
jongund: these are old now
Matt_King: are there WHCM bugs now that there is SVG here
Matt_King: don't have to fix in this PR
<CurtBellew> For some reason I'm not able to get the Call details link in the email to work. Could someone please provide the URL?
Matt_King: didn't introduce that bug
jongund: they disappear in some high contrast modes - the twisties
<CurtBellew> Thank you, Mark
Matt_King: can someone raise the high contrast issues
<MarkMcCarthy> Of course Curt!
Matt_King: my proposal is to merge with those bugs as known bugs
Matt_King: these code fixes didn't cause those bugs
Matt_King: going to be bocoup to review
Matt_King: maybe should leave HC mode doc out for now
jongund: ok
Updated checkbox example to restore visual keyboard focus styling feature by jongund · Pull Request #1802 · w3c/aria-practices
<MarkMcCarthy> https://
jongund: added focus around the label as well as the checkbox
Matt_King: should this have all of the reviews?
Matt_King: should have no aria AT impact right?
jongund: only change to RT is can't send key.space - have to use the space character
Matt_King: visual design, high contrast, code and test
Matt_King: I'll add after the meeting
Matt_King: imagine will be the same for 1801
<MarkMcCarthy> I'll take Windows HCM reviews on these, will be quick
Matt_King: need volunteers
Fixes and updates to index files:
<MarkMcCarthy> https://
Matt_King: I think we want to merge HCM infofirst
jongund: no
jongund: intertwined... fix for `aria-label` first.... then other
need to make sure index is accurate
Matt_King: need to make sure index is accurate
Matt_King: a few ways to review... make sure it matches - then checking the result of that is the part I was finding to be very tedious
Matt_King: is something as we look at redesign that indexing is robust
jongund: code is succinct
Matt_King: sarah_higley do you have time to look at #1709
sarah_higley: sure
Matt_King: should reference the wiki page
Matt_King: roles, states and properties that are included in heading or code tag, anything in table of role, states and propreties - then the meta tags (actually data attributes)
jongund: think that is correct
Matt_King: 1709 first
sarah_higley: my comment was about adding tooltips to every link
jongund: I think we added it as the Screen reader wasn't picking up the abbreviation
Matt_King: my comment was that needed it defined somewhere
Matt_King: outside the link and next to it is fine
sarah_higley: `aria-describedby` if that is a good idea?
siri: could provide the abbreviation for HC at the top
Matt_King: if you read through the table then will hear the HCs but wouldn't hear them in the list of links
Matt_King: ok
Matt_King: taking the titles off the links
Matt_King: work on 1709 first then 1607
Jump to main content
https://
jongund: don't think we need the show all landmarks and show all headings
<Jemma> you can see live example here https://
<Jemma> you tab into and can see landmark and page outline
jamesn: not really intended for screen. reader users
Matt_King: visually persistant
Matt_King: no logo on these pages do we
jongund: visibiltiy is important - for keyboard only
jamesn: accesskey sounds good
jongund: in this version it is a title attribute - would include a generated tooltip when it gets focus
Matt_King: how do you know what to put in
jongund: calculated base on OS and browser
Matt_King: you have to hard code it
jongund: yes i'm computing it
removing the collapsible list box
sarah_higley: burn it
Matt_King: would like a PR to deprecate it
sarah_higley: keep the page link but have it being a note about the deprecation
Matt_King: want to reference the select only combobox
sarah_higley: I'm happy to do the PR
Matt_King: lets get a proposal
revisit accordion behaviors on demo page
ARIA 1.3 First Working Draft Prep
MK: What we need for annotations, there are room for a lot of guidance
MK: It should be similar to our labeling and describing section, rather than functional example
MK: That is the first item
JN: I think prose is good, but we could link to an example document
JN: A page with static annotations
MK: Kind of like what we do for landmarks
JN: I have some ideas for this
MK: Some borrowing from what Aaron has done
MK: We might get contributions from many people, JN can you start off
JN: Do we want a super annotation issue that covers all of these things
MK: COmments and suggestions go together, aria-details is an interesting beast,
MK: Isn;t aria-details used to link... termonology
MK: ONe is the annotation and ..
JN: aria-details references the thing you are annotating and the annotation
MK: It feels like for that use case, the details should be specifically fot annotations
JN: We have other uses for aria-details, but this is the primary use case
JN: Aaron needed it
MK: What are the use cases related to suggestions...
JN: Let me look
<Jemma> here is info for aria details annotation https://
JN: The two use cases, not specially annotations, when you have some other user editing the text,
JN: There is inline stuff...
<Jemma> "aria-description="[localized string]" (similar to how aria-label can be used instead of aria-labelledby). This is a generically useful attribute that has been requested for years, and can be placed on any element.
<Jemma> Note for authors: aria-description should not be used when there is a more specific semantic to express the same information.
<Jemma> Order of precedence for description fields in accessibility APIs: 1) aria-describedby, 2) aria-description, 3) native markup such as HTML's @title"
MK: Is it the case we put aria-description in two places and they reference each other
JN: I will do 2 PRs, so they are not so big
MK: Let's address annotation first
<Jemma> Thanks so much, James!
JN: I will get something for us to comment on
MK: What is the direction aria-braille* , since there are lot of warnings in the spec
MK: It should be about when to use it or why to use it
JG: I am concerns about people using without understanding them, since they have label and descrption in the text string
JN: We need people who use Braille to give the examples, where these would be useful
<Jemma> jn: I would like to propose simply putting braille name and description with intended purpose with caution
JN: I think we could add a caution in the naming and description section about the using them without expert knowledge
JG: Have these attributes been socialized with Braille users
revisit accordion behaviors on demo page
MK: We need to vet them through the spec process
JN: The practices should reenforce the need for caution
MK: We need to reach out to Sina and Peter