<joanie> agenda: this
<joanie> agenda: be done
<scribe> scribe: melanierichards
joanie: reminder that the F2F is
coming up at the end of the month, April 30 thru May 2
... if you haven't yet registered, please do that
... james has set an F2F candidate label, if there's any topic
you think we should discuss because they're meaty, please add
the label
... james and I will add it to the wiki if we agree
<joanie> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2019-03-28+
https://github.com/w3c/aria/issues/925
<joanie> https://github.com/w3c/aria/issues/925
joanie: already set this on 1.3
https://github.com/w3c/aria/issues/921
joanie: tagged for 1.3 but I think it's a longstanding issue, not attribute parity
mck: agree, I think we had a
fundamental disagreement with HTML when we discussed this and
just left it as-is
... nothing stopping us [from picking it back up]
joanie: why I don't think this is
a 1.3 parity issue...parity is when we don't have an attribute
for something that's in HTML already. We already have
aria-required. Maybe for HTML 5.3 they need to get in alignment
with us and not the other way around
... do we want to do this for 1.2?
mck: it's going to take time to
discuss it. You don't have to do a lot of work, we need people
to agree what it means. Probably the work to be done will be in
the practices
... maybe I want to make sure this is done by June of this year
so that we can include guidance that makes sense for authors
and we're not conflicting with HTML on this topic
joanie: I'm going to set milestone to 1.2, and james and I can discuss
mck: can we put it on the agenda for F2F? Might have right people in the room
joanie: done
<joanie> https://github.com/w3c/aria/pulls?q=is%3Apr+is%3Aopen+created%3A%3E%3D2019-03-28+
joanie: both of these are our main topics
<pkra> \o/
joanie: can you make any final changes to clarify the language? Otherwise consensus is pretty much ready to land that
jongund: sure, I can do that by early next week
<pkra> hangs head in shame
joanie: minor wordsmithing comment, and merge conflict to look into. Otherwise seems we have consensus to merge.
we fixed the weirdness in preview caused by a markup issue
joanie: PR is just waiting for james to re-review
<joanie> If we were to test children-presentational=true today using the W3C's minimum-two-implementations standard, it would fail testing. Doing what is suggested in the opening report, on the other hand, would pass. Our spec is not in alignment with reality, and we have lack of interoperability. How shall we proceed?
joanie: straw poll - keep it, remove it, F2F topic?
mck: F2F topic. Will James be
there?
... I never understood why it would be children presentational
true
+1 for F2F
mck: doesn't need to be F2F but does need to include James
joanie: will try to get James's comment and go from there. Does that make sense?
mck: yeah
joanie: aria-rowtext and
aria-coltext...turns out this is already implemented in
Chromium, and I happened to stumble across it by virtue of
updating my platform's ARIA text. Those aren't ARIA props, yet
there's code for th em!
... meant to solve, in the case of a spreadsheet: you're not in
Column 1, 2, 3...you're in Column A, B, C. How do you express
that?
... coordinates are B, 1 not 1, 1
... Alex S. also mentioned chess game boards
... this seems like something we want to do. Not jazzed about
the names. Earlier versions were aria-rowindextext,
colindextext
... this seems like a valid feature, do we want to add to
ARIA?
mck: yes, absolutely, as soon as possible if we have an implementation
carmacleod: I agree with the older names
mck: +1
melanierichards: +1 to carmacleod
<joanie> https://github.com/w3c/aria/issues/667
joanie: please leave feedback in the issue and leave a comment if you plan to help develop the feature
carmacleod: Aaron might have valuable opinions from grid work
joanie: he's aware
... will definitely involve him
mck: if I were doing this, I would start by looking at where rowindex and colindex are supported, this should probably be supported in the same places
HarrisSchneiderman: this can't be accomplished by the accessible name?
joanie: that's my initial thought, but you'll have headers that are independent of the application being used, and both could be relevant
mck: also, if you're specifying the index of C5 with the label, you won't have the contents of C5
joanie: screen readers have a "where am I command"
mck: wouldn't be able to tell if A5 is the contents or the index
pkra: 2 PRs which are attempting
to capture discussion in Feb. We did have some additional
comments on the PRs. The major changes are: on the one hand,
limiting things to label and roledescription for now. On the
last call we wondered about labelledby and describedby
... valuetext and placeholder were also raised, I'll bring up
separately
... for now just label and roledescription
... I tried to cover what happens if there's ASCII in the
Braille label or roledescription
... question of whether we should skip it. In old emails, Glen
said leave it to locale to figure out and let AT work it out
that way. I'll add a comment regarding that
... there's a TBD in there, as far as what to put for
accessible name computation
<joanie> https://raw.githack.com/w3c/aria/5b3de91/index.html#aria-label-braille
pkra: would like to make progress on ASCII, and "accessible Braille name"
mck: I wasn't clear on Glen's comment on localization?
<pkra> I think that the label needs to be locale dependent. Otherwise people in one locale may see a label in another which will not make sense to them. As soon as you start using ASCII Braille you must pair it with a table that converts the ASCII to Braille dot patterns. Different locales have different tables. And within some locales, multiple tables exist. If Unicode Braille can’t work, perhaps just a textual string which the screen reader can convert to Braille using t
(above is Glen's comments)
<pkra> the active table for that locale.
mck: so he's saying, you don't
put any representation of Braille in here, you write (if you
were using English) the English characters you would want to be
Brailled into this attribute
... am I understanding that right? Let the screen readers do
the translation?
pkra: he was describing under, if
the Unicode Braille patterns don't work
... Unicode Braille patterns do work for all the platforms
mck: this feels like something
who people who work on this stuff a lot should chime in, out of
my league
... I'm not even sure what this means on the authoring side. If
you're doing Unicode Braille on the authoring side, what do you
need to know in order to get the value right
<jongund> need to leave earl
janina: Unicode would have that 1-6 character, I wouldn't know what it would it translate to non-Braille as
mck: no author's going to do this
unless they have a lot of knowledge about what's going in a
Braille name
... is our assumption here that any Braille character can be
represented with some Unicode equivalent?
<pkra> https://en.wikipedia.org/wiki/Braille_Patterns
janina: I suspect that's what Unicode Braille covers. I don't think it has any semantic knowledge other than dot patterns
<pkra> The block contains all 256 possible patterns of an 8-dot braille cell, thereby including the complete 6-dot cell range.
mck: how do we get people who know the right stuff to weight in on this?
joanie: will want to reach out to
screen reader developers
... I'm favor of removing ASCII, I want to discourage most
authors from using this
... I want authors who know Nemeth to be able to use this
... we want to prevent random authors from guessing braille
symbols and sticking it in there
mck: agree, this is for people who really know what they're doing
joanie: Peter, what do you think about limiting to Unicode Braille?
pkra: no issue with that
joanie: what I want to be able to do as a SR is not worry if something is Hungarian or not, I want to just send the dots to the Braille reader and do no processing
<janina> According to Wikipedia, In Unicode, braille is represented in a block called Braille Patterns (U+2800..U+28FF)
mck: there's a bunch of
assumptions that have to be tested. If Unicode Braille is
saying "raise these dots" and that's all you can put it in
there, it becomes the author's responsibility to localize
... that part has to be super clear
pkra: if we say that authors should only put in Unicode Braille, we should say AT should only process if there's Unicode Braille in there?
joanie: if we expand it beyond Unicode, that's when we'll have a harder time getting consensus. Should the SR translate it? etc. If all the SR has to do is raise the dots, that's easy
janina: I suppose the only issue is if you use a different code because a different language uses a different code series
<bgaraventa1979> apologies, got bounced off the call
joanie: authors who are sighted
can look on the screen and go, "yup, those are the right
braille dots"
... my understanding of consensus is that right now, this is an
authors MUST limit the characters to those unicode braille
patterns
mck: authors must encode the attribute value using Unicode
joanie: maybe also use the word 'localize' in there?
mck: 2 separate authors must?
Unicode, localize?
... do we have authors MUST elsewhere?
joanie: aria-modal, owns, for a
lot of these
... we use it when we feel strongly about it and when a
validator can programmatically validate it
... we can programmatically validate that Unicode symbols are
used
<Zakim> joanie, you wanted to suggest deleting the first TBD (the API mapping is irrelevant to authors; it's a name. Core-AAM will specify the mapping. How ATs consume the mapping is
joanie: the device that presents the name is Braille, not speakers, but it's still a name
janina: I still wonder how much
localization is involved in all these widgets we want to
identify
... is a checkbox a checkbox no matter what language you're
in?
... the same symbols
<pkra> Music, Chemistry
joanie: I think on the one hand that's important to sort out, but if we think about who's using it...educational services, I think they'll have the right knowledge to sort it out. Math people. All the people with domain-knowledge expertise will be the people potentially using this feature
janina: I can take this action item, it really is a pretty short list. Might as well put it in the authoring guide so you don't need Braille expertise to populate the attribute
joanie: I'll give you that action item to coordinate with your domain experts and Peter
mck: one last question on label,
would you ever use Braille label without using
aria-label?
... this is written as if the Braille label is independent of
other labels. But I'd think it would be a Braille alternative
to aria-label
janina: yeah, I think that's what I was trying to tease out in my head
pkra: [gave math example]
joanie: maybe in spec text, cover
both cases: sometimes an alternative to aria-label, but there
may be instances where there isn't an aria-label
... as far as property names, consensus seems to be no hyphen,
camelCase
mck: oh, I didn't know that. I
liked the dash.
... I liked grouping all the Braille stuff together for
example
... I'll chime in on the issue
joanie: #923 is PR where people are talking about microsyntax
[Peter will update]
<pkra> *blushes
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Present: Joanmarie_Diggs melanierichards HarrisSchneiderman janina Bryan_Garaventa MichaelC Matt-King carmacleod JonGund pkra Regrets: Mark_McCarthy Stefan_Schnabel James_Nurthen Charles_LaPierre Found Scribe: melanierichards Inferring ScribeNick: melanierichards Found Date: 04 Apr 2019 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]