W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

19 Feb 2019

Attendees

Present
AWK, SteveRepsher, alastairc, Rachael, JakeAbma, Detlev, Brooks, JF, MarcJohlic, stevelee, Laura, david-macdonald, kirkwood, Mike_Elledge, gowerm
Regrets
Rafal, Bruce_Bailey, Chuck, Kathy
Chair
SV_MEETING_CHAIR
Scribe
JakeAbma, Brooks

Contents


<JakeAbma> scribe: JakeAbma

Justine: introduces herself

CSUN Registration https://www.w3.org/2002/09/wbs/35422/2019-03_FtF/

AWK: please fill in survey for CSUN

Open CFCs

AWK: If your new to CFC, do a +1, or -1

<JF> +1

Issues Survey: https://www.w3.org/2002/09/wbs/35422/Tech-Under-Prop-Feb19/results

Issue 619

" labelled navigation landmarks should be added to sufficient techniques for 2.4.4""

AC: more appropriate for 1.3.1 because it's applied for link, not context

AWK: ARIA 13 is for regions and landmarks
... there are situations for links ambiguate from each other

Rachel: shoud be a sufficient technique for 2.4.4

AC: see theoretically the point, but not sure if it works in practice
... don't see technology support for now, but there may be some

MG: not sure if we want to promote such techniques

Brooks: a programmatic relationship I would support, take as example two credit card in two different groups. a technique to group programmatically makes it more clear

AWK: possible response, ask a live example to see how it works, and we may recommend

AC: happy to re-draft, unconvinced that lots of navigation landmarks are added
... ... will help what we try to achieve

<Rachael> +1 to redraft

Brooks: leaning to 1.3.1, accessible name will not be adjusted for the links when grouping, so may be reason not to add it to 2.4.4

AWK: response to get more information first...

<alastairc> https://github.com/w3c/wcag/issues/619#issuecomment-465203072

RESOLUTION: leave open

Issue 618: definition of presentation in SC 1.3.1

AWK: most seem to like the response

RESOLUTION: accepted as proposed

Issue 613: 1.3.4 Orientation - applicability to native apps

AWK: WCAG not spplying to native, WCAG2ICT is the document or how it might apply to native

<JF> +1 to accepting

AWK: seems like all are accepting

RESOLUTION: accepted as proposed

Issue 612: Fixes to WCAG 2.1 Understanding 2.4.6 and 3.3.2

AWK: Patrick asked to adjust and already made a PR

MG: definition of label is where we need to have some caution about
... we have some discussion where a label is OR pure visible, or also in other SC something everyone will perceive (also invisible ones)

<david-macdonald> someone is eating

<alastairc> +1 to accept (wtih Rachael's modification), think we need a label clean up later.

<JF> +1

RESOLUTION: accepting as amended with Rachels change

Issue 599: Is using the track element to provide audio descriptions sufficient? (Was "Retire H96?")

AWK: seems like we've done last week, and yes, it was but got some responses
... could condired to make it a sufficient technique, but a bit too much, so stays advisory

JF: agree for advisory technique

RESOLUTION: accepting as proposed

ERRATA – Issue 582: 1.4.13 Content on Hover or Focus - hoverable requirement, clarification of point "persistent"

<JF> +1

AWK: discussed couple of times, about errata for "trigger"
... MGower thought all was covered already

Detlev: It could be misunderstood, but not go horribly wrong
... can live with leaving as is

AWK: we can leave as is, or even change for a possible 2.2, or if errata is clear ad it to the errata list

DMD: is there proposed text for errata

<alastairc> https://github.com/w3c/wcag/pull/603

MG: I see the SC wording is not accurate, but removing trigger will not make it more clear

<Detlev> let's leave it for later then it is not urgent

MG: gets a bit wordy if we do the errata suggestion

<alastairc> Mike's comment is closest to an official response: https://github.com/w3c/wcag/issues/582#issuecomment-462393140

<alastairc> plus we would consider update in a 2.2

MG: also good to change / clarify SC text in future release

RESOLUTION: Alastair and Andrew will add response on basis of Mike Gower's response

Issue 581: Misleading info in "Understanding 2.4.4: Link Purpose (In Context)"

AWK: unanimous response

RESOLUTION: accept as proposed

WCAG 2.2 Survey: https://www.w3.org/2002/09/wbs/35422/WCAG22_yesno/results

AWK: surprised everyone agreed
... explaining about suggested proposal
... roughly speaking a 40/40 approach and some other work to be done

JF: there's a misconception on where they are, based on what I see they make progress but chapter one on a 10 chapter book is not even done right now
... a lot of work needs to be done still

AWK: at CSUN there will be substantial time to kick off work for WCAG WG and SIlver project

<Brooks> scribe: Brooks

AWK: any other comments? This is a major decision that this group will make as result of this survey. We will do a CFC for this.

Issue review

AWK: I've been trying to craft responses to a number of old issues in GitHub. Anybody on the working group is welcome to go into GitHub and assisgn themselves to issues.
... There are number of issues that are currently active out there. We want to check in to see what the status of these items are, and assign working group members to address the items the still need to be reviewed.

MarcJohlic: Would it be helpful to put a link to the proposal on the questionnaire?
... Or change the link to have an underline to make it more obvious.

<MarcJohlic> s/MarcJohlic: Would/Mike_Elledge: Would/

AWK: what else do we have that's ready to go? Issue 614?

gowerm: I would welcome group review of this one.

<AWK> https://github.com/w3c/wcag/pull/627

AWK: Issue 627 is a pull request which would be beneficial to review. -

<AWK> Needs people to review

AWK: By the way Issue 615 goes with Issue 614 - https://github.com/w3c/wcag/pull/614

<AWK> https://github.com/w3c/wcag/issues/623

AWK: Do people know if Issue 623 needs more time to perculate?

JF: That was only four days ago.

<alastairc> Looks like a tricky one, overlapping with user-agent aspects.

AWK: We'll wait and see on that one.

<AWK> https://github.com/w3c/wcag/issues/605 - SteveRep?

AWK: Steve you've got issue 605. Will we have proposal on that one?

Steve: Working on it now.

<MarcJohlic> @AWK, 536 and 537 will be ready for next week's call.

AWK: Issue 598, that's yours Mike Gower.

Issues 591, 592 and 593 are also assigned to you and related to the same topic - labels.

JF: On Issue 598 - there's an argument about whether font icons are text. We need some clarity around this issue.

<AWK> JF, what is a font icon?

JF: One of the ways we can label something is through font icons. In some of the examples that Mike Gower showed, such as the AA button font sizing button, raise some issues that need to be addressed.

Alastair: Regardless of how its implemented, the representations of the label look like text. The results of this thread is that we are treating them as symbols. Font icons is a different type of issue. There is another technique, which we are working on is role of image when it is a font icon.
... In the context of this thread, though, those things are treated as symbols rather than text in how they should be treated in the accessible name algorithm.

JF: Have we gotten to an answer here?

Gowerm: The issue becomes more scattered, when we are talking about letters where they are representing something different that the letters alone.

<alastairc> Examples where they are symbols, aA = text size or headings

Gowerm: I put the focus on determining what the text is that should be included to meet label in name SC.

<AWK> https://github.com/w3c/wcag/issues/585

AWK: Issue 585 does not have anyone assigned to it now. Relates to Understanding 2.3.1

Alastair: May be a discrepancy between older versions of how screen dimensions were considered and current considerations

AWK: Anyone want to take this issue on?
... Maybe we should check with Patrick to see if a language change would suffice here?

<alastairc> https://github.com/w3c/wcag/pull/583

Alastair: Should we speak to the color focus indicator techniques? Issue 583? I took David's technique and made a pull request.

<AWK> about "Creating a two color focus indicator to ensure sufficient contrast with all components"

Alastair: Would it not be suitable to have a double border?
... It seemed to be another example we could add to the same technique. If thatseems suitable, can I leave it with you David, for an update?

David: I can do that.

<AWK> https://github.com/w3c/wcag/pull/584 - Detlev?

AWK: Detlev, Issue 584 is yours. Are there any other changes that have happened with this one, which we need to discuss?

<AWK> last survey on this: https://www.w3.org/2002/09/wbs/35422/issue-responses2-jan19/

Detlev: I'd like to have an easier way of checking for this, but not sure if anyone else has a better idea of how to test this.
... How do we cover the situation where some browsers will respond to some shortcuts where others don't?

AWK: It's a good question to ask. Do we feel like Shift would be a non-printing modifier key? In other words, would we not be violating this SC by using Shift in this way?

<AWK> https://www.w3.org/TR/WCAG21/#character-key-shortcuts

<AWK> "If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:"

<AWK> (including upper- and lower-case letters)

Detlev: The single key shorcut SC says no single key shortcuts are allowed. We want to find a way to see if page scripting uses single key shortcuts. This is difficult to test for in practice. Maybe its just a single key that needs to be tested. No need to take into account the capital version of a letter, for example.

JF: I'm doing Shift + S in Firefox, and nothings happening for me.
... I don't think Shift+S would ever be considered a modifier key, in the context of firing an event.
... On the windows platform, you've got Ctrl and Alt and the windows key as modifiers.

<Zakim> alastairc, you wanted to ask if voice input differentiates lower/upper case?

Gowerm: Shift is a non-printable character key, but then you have the capitalization function of the shift key. But Ctrl + Shift + another key is an example of where Shift is being used as a valid modifier key.

Alastair: With JavaScript, if you press the key s, does that generate different info than Shift+s?

<gowerm> On a US keyboard keyboard, the Question mark is Shift+/

JF: There could be some internationalization issues that are causing inconsistent outcomes in our impromptu keyboard shortcut testing.

Alaistair: I feel like we need to know more to determine whether we have to test every keystroke with the addition of the Shift key.

JF: Testing for specific failure techniques is difficult. I'd rather test for positive outcomes.

Detlev: That's hard to do for this specific SC.

<gowerm> Where the shift transforms the character printer (i.e., Shift+7 is the ampersand) it obviously produces a different character. This happens with numbers. That is different than Shift+S that just capitalizes the S.

Detlev: How does anyone else on this group test this SC?

Alastair: It would be great to have a way of understanding of how all of the events are scripted on the page, so that we could see the mapping to shortcuts.

David: It would give a better understanding of which interaction patterns should be included in the page documentation for users.

AWK: Some of the language of the SC makes it difficult.

<Zakim> gowerm, you wanted to say that we have had similar discussions at IBM about how difficult/impractical it is to test some of these new SCs are in verification testing

Gowerm: The Shift key is a non-printable modifier, but logically since upper-case letters need the Shift key to exist but are still considered character keys in need of modification, then Shift must not be included in the non-printable charaters for remapping It's not practical to fully test all of the possibilities raised in this SC.

<AWK> https://github.com/w3c/wcag21/issues/769 - related

AWK: Doesn't sound like we are going to come to a resolution on this today.

<AWK> https://github.com/w3c/wcag/issues/538

<AWK> Detlev

AWK: Issue 538 is also Detlev's. Detlev what is the update on this issue?

Detlev: Someone else has redrafted this response and has changed it slightly. I think it will be ready for a survey.

AWK: Issue 553 seems the same as Issue 585. That might be one we can resolve after talking with Patrick.

Issue 551 is assigned to Alastair. What's the status of this one?

Alastair: This one seems defunct, because the examples aren't there any more. There have been some more comments, though.

AWK: This one sounds like it might be easy to resolve.

<MarcJohlic> https://github.com/w3c/wcag/pull/629/files?utf8=%E2%9C%93&diff=split

MarcJoholic: Issues 536 and 537 are mine. There may be some issues with some of the editing. Might be good to delete the pull request and do over?
... I'll just go in and change it. It does not cover Issue 539. I'll go in and look at that one separately.

AWK: If people have issues ready to go, it might just be easiest to email the chairs.

<Zakim> JF, you wanted to ask Marc about these changes

<AWK> https://github.com/w3c/wcag/issues/526

<AWK> https://github.com/w3c/wcag/issues/522

<AWK> Need volunteer

Issue 522 came from Mike Gower and Detlev's been involved in the discussion. Anyone want to volunteer to dig into this one and come up with a response?

<AWK> https://github.com/w3c/wcag/issues/521

AWK: Maybe the recommendation is to talk about Issue 522 next time.
... Issue 521 is about alt attributes and aria-label attributes and conflicting values. Anyone want to look into this one?

Summary of Action Items

Summary of Resolutions

  1. leave open
  2. accepted as proposed
  3. accepted as proposed
  4. accepting as amended with Rachels change
  5. accepting as proposed
  6. Alastair and Andrew will add response on basis of Mike Gower's response
  7. accept as proposed
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/02/19 18:01:12 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

FAILED: s/MarcJohlic: Would/Mike_Elledge: Would/
Succeeded: s/that's /that/
Succeeded: s/If shift is a modifier key, then Shift + s is a modifier key that doesn't fail this SC./The Shift key is a non-printable modifier, but logically since upper-case letters need the Shift key to exist but are still considered character keys in need of modification, then Shift must not be included in the non-printable charaters for remapping/
Present: AWK SteveRepsher alastairc Rachael JakeAbma Detlev Brooks JF MarcJohlic stevelee Laura david-macdonald kirkwood Mike_Elledge gowerm
Regrets: Rafal Bruce_Bailey Chuck Kathy
Found Scribe: JakeAbma
Inferring ScribeNick: JakeAbma
Found Scribe: Brooks
Inferring ScribeNick: Brooks
Scribes: JakeAbma, Brooks
ScribeNicks: JakeAbma, Brooks

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 19 Feb 2019
People with action items: 

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]