Accessibility Guidelines Working Group Teleconference -- 07 May 2019

<AWK> Scribe: Justine

<alastairc> scribe:jpascal

Silver requirements update

<jeanne> https://w3c.github.io/silver/requirements/index.html

<jeanne> https://w3c.github.io/silver/requirements/index.html#scope Scope section

Jeanne: new scope section in requirements document intent to draw attention to differences around Silver and provide some clarity
... guidelines will be content oriented with methods around testing

<jeanne> https://w3c.github.io/silver/requirements/index.html#design-principles Design Principle #9

Jeanne: Design Principles 9 - data informed and evidence based whenever possible

<jeanne> Be data-informed and evidence-based where possible. We recognize that research and evidence are influenced by the number of people with a particular disability, by the size of the body of research, and by the difficulty in capturing data regarding some disabilities or combination of disabilities. The intent is to make informed decisions wherever possible to ensure that the needs of all people with

<jeanne> disabilities are prioritized, including needs that differ from the majority. In situations where there is no evidence or research, valid data-gathering methods should be used to obtain and evaluate information from advocacy groups, people with lived experience and other subject matter experts.

<Detlev> JF noise?

Jeanne: techniques of research/valid data gathering methods is a flexible term that is recognized as specific in the academic research community. It allows for new types/techniques of research/techniques of research

<jeanne> https://w3c.github.io/silver/requirements/index.html#technology-neutral

Jeanne: reworked "technology neutral"

<jeanne> Guidance should be expressed in generic terms so that they may apply to more than one platform or technology. The intent of technology-neutral wording is to provide the opportunity to apply the core guidelines to current and emerging technology, even if specific technical advice doesn't yet exist.

<Zakim> david-macdonald, you wanted to ask about non-normative vs normative methods. If methods are not normative, then will a soft requirements guideline be sufficient.

David: user agent guidance - how will we create normative guidance that is specific enough? Guidelines are generic and methods are like success criteria. Is that right?

Jeanne: Not quite. Guidelines will be worded in plain language and methods will be mostly tecnhiques and success criteria that are platform specific

David: Needs clarification on what will be normative and what will not be.

Jeanne: Have not worked out the details of what will be normative and what will not be. Personal opinion that methods will not be normative but we can't work it out today. Requirements need to be done first.

<AWK> https://w3c.github.io/silver/requirements/index.html#scope

David: How do we prioritize all disabilities? Is that the right way to phrase it?

Jeanne: No one group has a higher status than another group. Not setting up a heirarchy of disabilities.

Placeholder: Not a numbers game. Don't want to leave out specific disabiltiies.

Jeanne: Can you live with this David?

AWK: This is not carved in stone. We can change it if needed.

<Detlev> considered?

<Detlev> taken into account?

David: We want to treat all disabilities equally

<Detlev> covered?

<AWK> suggest the word "addressed" but don't mind either way

<johnkirkwood> provide equal access for all disabilities

<Detlev> +1 to addressed

JF: Equal prioritization across the board. We went through a lot of wordsmithing on this point in particular. We are splitting hairs. Are we in agreement on principle?
... You are hearing desire and intent on this call, that all disability groups are being treated equal and the needs of the few are as important as the needs of the many.

Jeanne: We have a hard timeline that needs to be met for rechartering. I am backing up those timelines and we need to finish this. It is putting the charter timeline in jeopardy.

Thanks, AWK

AWK: We can put out a CFC to the working group. Jeanne, what happens after that?

Jeanne: Put our attention on making a first editors draft.

AWK: Any other objections?

<JF> +1

<alastairc> +1, and I like the new scope section.

RESOLUTION: WG is happy with the updated to the silver requirements and we will do a CFC

Jeanne: Thank you to the group, I am grateful for the group's input. The Requirements are much better because of your input.

WCAG 2.2 Q&A on process and templates

AWK: We talked last week about people beginning development in small groups around WCAG 2.2

Alastair: I did sent an email with suggestions around how people might approach it. John from COGA has written a draft of the top part of the template and shared for review. Have others found any issues with templates?

AWK: Any questions?

<alastairc> Link to the drafting overview email: https://lists.w3.org/Archives/Public/w3c-wai-gl/2019AprJun/0031.html

AWK: please get the discussion going with others if you are leading one of the groups. We would like to have an editors draft of 2.2 for the charter. We would like to populate new content.

Bruce: Do you need suggestions for the charter in regards to 2.2?

AWK: No. Its beneficial for us to say we have an editors draft. I expect/guarantee that we will not have all SC in draft before the charter period is done. Our plan for 2.2 was that group would be recharted as of this coming October.
... Any other questions?

Issues (https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/results) (#’s 3,5,6,7,8 only)

Survey for new techniques (https://www.w3.org/2002/09/wbs/35422/New_techs1/results)

AWK: We received 4 responses on the survey. If you haven't hit submit, please do so.

Pull Request 649: General techniques for label in name

<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/New_techs1/results#xq4

AWK: Approved with changes but there are edits to work through

Mike: I'm not at my desk but I will listen and incorporate points

AWK: Example 2, let's avoid using "crappy"
... Next technique, what do people think about using ARIA label and the title attribute rather than just title attribute?
... want accessible name and pop up/tool tip. What do people think?

<bruce_bailey> i think we should avoid title attribute unless that is the point of the example

David: There is still animosity against the title attribute. NVDA and JAWS will ignore title attribute if same as ARIA label. I think we can use them both. I'd like to include the ARIA label to be "cleaner".

<bruce_bailey> i think it confusing to use both

David: I'd prefer just title but I anticipate push back

<Zakim> bruce_bailey, you wanted to say i think we should pick on or the other

Bruce: I think its confusing to use both. Its like not having any faith in ARIA if we are sticking a title in everywhere.

AWK: ARIA does not result in a tool tip.

Mike: Screen reader user will get accessible name via Title element. Can lose functionality for anyone navigating with a mouse.
... I only recommend title being used

<johnkirkwood> +1 to Mike

<MichaelC> https://w3c.github.io/accname/

<MichaelC> http://w3c.github.io/aria-practices/

MichaelC: We should look up spec and make sure technique is reflected. A lot of testing has been done for the way that screen readers render accessible name. ARIA authoring practices may address keyboard function. I think we have a coordination issue with ARIA working group we need to look at.

Mike: We have to give one of the fields a label name. For a screen reader user, they will hear ARIA describedby and title information as a supplement.

AWK: Okay. My concern is that its not so great. Seems like a good rationale exists for using title and I'm okay with that.

Sorry about that.

AWK: In procedure for first technique, each input matches accessible name for input. Feedback?

Mike: I think it applies to #4 as well

AWK: Any objections?

<jon_avila> should we say anything about whitespace?

AWK: should we update language for #4?

<bruce_bailey> +1 for keeping [text inside brackets] in final version

AWK: Example 4 -- legend but no field set. Should we add field set? Example 5 doesn't seem to be referenced by either technique.

Mike: I'll check that.
... No way to get around repeats where most screen reader won't repeat....
... question about example 4. Are those available to someone use voice recognition software?
... I'm working on a research project to confirm. My experience is that it will navigate to first field and then user will move by keystroke.
... We are adding a specific ARIA technique for this

AWK: Not fair to say implementation causes issues without considering others.

Alastair: Can interfere with adjacent text even if visually obvious. Not fair to call out in terms of creating accessibility issues. Change I'm suggesting is to remove reference to causing accessibility issues.
... I was suggesting a change to the first step which does reference adjacent text. Move up before step 1.

AWK: so that's a change to #1?

Alastair: Yes, in the one that has 4 steps.

AWK: Alastair might be suggesting to remove the word "adjacent"

Alastair: Yes, that will do.

Mike: If you remove "adjacent" someone could argue that anything on the page could be a label.

Alastair: Not sure what solution is but it needs to match examples above it.

<david-macdonald> How about "nearby" instead of adjacent

<Chuck> AWK we are at top of hour, and should change scribe.

Alastair: is it worth mentioning how a voice input user would use it? Wasn't clear. How do you select middle ones because they don't appear to have physical labels? Just add a sentence that people can arrow down to field using voice input.

<david-macdonald> For input controls, examine each input that has nearby text which serves as its label

Mike: I'll create some text

AWK: Steve, are you referring to screen reader users or screen reader users who also use magnification?

Steve: mostly just screen reader users. If you hear label when you're on the input and that doesn't match what you heard before reading text, that could be confusing.

AWK: Got it.
... A screen reader user may hear text and then hear again associated with a label.

Mike: That is in the understanding document.

AWK: If in the understanding document, we do want to avoid repeating content. Steve, are you happy with this?

Steve: Yeah but why long explanation?

AWK, I have a conflict and will need to switch to another scribe.

<alastairc> Where it says "it can cause issues for the user", perhaps expand to "... for voice input and screenreader users."

[missed some conversation]

AWK: I see them as spin buttons as well

Steve: There's a number restriction on the input

Bruce: Is NVDA taking max/min as numerical values as opposed to number of digits?

<mbgower> scribe: mbgower

Detlev: I couldn't figure out what example 3 was for. The min max values need adjustment

<bruce_bailey> max min are numerical range, not number of digits for validation

mbgower: I will ensure the examples are correctly cited. There was an additional technique which is not yet in survey they might applied to.
... I will remove min max

RESOLUTION: Accept as amended from survey responses.

Pull Request 531: Semantically identifying a font icon with role="img"

AWK: Mike Gowerasked what SC is this related to?

<JakeAbma> some history: https://github.com/w3c/wcag/issues/144

<JakeAbma> https://github.com/w3c/wcag21/issues/296

Laura: 4.1.2

<JakeAbma> https://github.com/w3c/wcag21/issues/297

<AWK> and 1.3.1

Laura: Also 1.3.1

AWK: Mike points out some minor editorial and asks 'how do you determine it's a font icon'

Jake: It can be clear. You have to inspect all items and see if they are placed with an image element or svg or the :before in CSS.
... If you have 300 icons and use multiple techniques to place items, you have bigger problems.
... Most of the time, it's clear

JF: I agree with Jake that one of the ways is the :before pseudo class
... There are multiple ways of providing css background images. At Deque we use a browser-based tool bar that disables background images as a first step to ID the font icons.
... We could include identifying the font icons as a first step

Jake: It could be part of the testing procedure.

<Zakim> mbgower, you wanted to say it would be an idea to just cover this a bit in the technique. It doesn't have to be in the procedure.

<alastairc> mbgower: not essential to be in the procedure, but should cover in the technique itself.

<alastairc> ... can we use background images as an equivelent?

<Zakim> steverep, you wanted to clarify they are not background images

Steve: they are provided by CSS as part of the style, but not necessarily background images
... I don't think we should use 'background images' as a synonym. It's content provided by a stylesheet

<Detlev> Also, icon fonts do not disappear when using web dev toolbar and turning off background images...

AWK: I'm in agreement with that, but if someone is using a Dingbat font -- some kind of a symbol font -- that works for them, which is referenced by css.... That is something else, but I assume something that we want to address with this technique

Jake: I think we can add something into the test procedure. I don't see that as difficult

<Zakim> alastairc, you wanted to say that overriding fonts is probaby quickest.

AWK: Alastair asked about the bad practices

Alastair: I don't think it is a synonym. svg icons can be foreground or background. It might be that we want background svgs as an image.

Alastiair: The driving force for this was similar to Text Spacing, which originally had overriding fonts. That got taken out. This technique helps fill that gap.

Jake: The basic of where this came from is many sites use icon fonts.
... even where there is no accessible name, they still want to keep the icon fonts.

<AWK> Jake: I created an example where you can click on the item where the role=img is added

<AWK> ... there is a special case where you have a parent item

<AWK> ... where each uses an image

Jake: For my last example, if you just put img on there, it doesn't work. So these are the edge cases used for icon fonts.
... we need these four to cover the scenarios that exist

JF: I think Jake has covered a lot of it.
... The distinction to me is between foreground and background.

<laura> +1 to Jake. Keep the bad practice examples first.

<laura> In the original technique we had This technique relates to:

<laura> * 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

<laura> * 4.1.2 Name, Role, Value

<laura> https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg

<alastairc> Jake: https://github.com/w3c/wcag21/issues/296#issuecomment-351861635

Jake: I couldn't find where to assign this technique for a SC. Maybe we make the technique and figure out what the SC is for 2.2?

<steverep> It's 1.3.1

Alastair: I put a link in showing the issue where this is tracked.

AWK: To resolve the 1.3.1, you add a role which makes it sound like 4.1.2

Jake: But there is one example where the technique does not result in anything that would apply to 4.1.2
... It's an awkward technique, but it is a known problem and this is the best solution.

<Zakim> mbgower, you wanted to say I am having problems seeing how this is 1.3.1 or 4.1.2

Steve: It's an image. It needs to be marked as an image. It needs ALT text.
... I think it falls under 1.3.1.
... 4.1.2 only covers UI components. But it may be an accent icon with no interaction.
... If it looks like a graphic, it needs to be semantically marked as a graphic.

<Zakim> alastairc, you wanted to say it is about identifying the semantics of something that isn't a foreground img, but should act as one.

Jake: If you don't add it to icons which may be use as some sort of background image, you get all those squares on your screen.

<alastairc> not all font-icons are 'user interface components'

Jake: It doesn't _just_ fall under 1.3.1. It's an odd one.

AWK: What do people think about this?
... It sounds like there's some uncomfortable agreeement that this is 1.3.1. Do we need to see this again after addressing comments?

<bruce_bailey> +1 that it is good enough to go

<alastairc> Happy to publish (noting we can update later). Withdraw my comment about the bad examples.

<bruce_bailey> +1 to keeping bad examples (because they are very common)

Good to go with changes, I think: and address how to determine font icons in the technique a bit more, I think. Doesn't have to be in procedure, for me.

<laura> +1 good to go.

Steve: This is why I pushed for repeating it. It's not in an understanding document becuase this isn't a technique that is discussed in 1.3.1
... I don't understand why we wouldn't repeat relevant information in the technique from the Understanding document.

In the technique. The Understanding doc is already massive

<Detlev> +1 to Steve - no harm adding benefits for navigation

Actually, it's true 1.3.1 Understanding is pretty short. The techniques are just numerous

Steve: I can use the graphics for navigation. It can increase my ability to jump around, where there are way more links than images.

<alastairc> suggest adding to the desc at the end: "An easy way to identify icons created with fonts is to override all fonts on the page using a browser plugin."

Steve: I will look through the examples. I do think the benefits to other users should be detailed.

Jake: This was aimed at avoiding all the squares left from missing font icons.

Detlev: I think there is no harm to add in information about the img being useful for screen reader users.

<laura> +1 to Jake on orignial aim.

Jake: My last question would be: you mean adding role="image" to a background font generally? We use this as a trick.

Detlev: The icon font is an image, so I don't see the harm as sign-posting it as an image to allow that affordance to screen reader users.

<AWK> How about adding to the second paragraph of the desc: In addition, screen reader users also benefit by being able to identify a font icon as an image and can locate it using a graphics search capability of the screen reader.

Steve: Something used as an image needs to be marked up as an img. That falls under 1.3.1.

Jake: I understand that icons which _are_ required to understand need the image. But on the other hand, the decorative images are also covered here.

Steve: Why is it important for decorative?

Jake: All decorative images will get the squares.
... In the github issue discussion, there was a wish to keep decorative font icons alive.

<Detlev> q

<alastairc> Images conveying information / relationships... not decorative

Steve: Why aren't they both covered by 1.3.1?

AWK: 1.3.1 doesn't deal with decorative because it only deals meaningful presentation.
... The more detailed discussion can happen in 1.3.1 Understanding document.

<AWK> "In addition, screen reader users also benefit by being able to identify a font icon as an image and can locate it using a graphics search capability of the screen reader."

<laura> +1 to adding awk’s sentence to the technique.

<Detlev> +1 with addition

<alastairc> +1, and raise an issue to add more changes...

<laura> +1

RESOLUTION: Accept pending edits form the survey as well as the additions to the second paragraph from the call.

<laura> Many thanks to Jake.

<Detlev> mbgower: The sentence you wanted was at 18:52

<laura> bye.

trackbot, end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

07 May 2019

Attendees

Contents

Silver requirements update

WCAG 2.2 Q&A on process and templates

Issues (https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/results) (#’s 3,5,6,7,8 only)

Survey for new techniques (https://www.w3.org/2002/09/wbs/35422/New_techs1/results)

Pull Request 649: General techniques for label in name

Pull Request 531: Semantically identifying a font icon with role="img"

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output