Accessibility Guidelines Working Group Teleconference -- 04 Apr 2017

<Joshue108> trackbot, start meeting

<trackbot> Meeting: Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 04 April 2017

<scribe> scribe: jamesn

Reminder about GitHub issue updating for SC managers

<Mike_Elledge> How swede it is!

AWK: sent out a notice email on friday?? If you find your name on it then it tells you what items you need to update

if you are confused then let us know and we will help

it really helps if we don't have to do it all ourselves

helps if you let me know so i don't bug you again once it has been done

any questions?

as of next week will start asking for good excuses

Scribes

awk: out of people for scribes

need people for the next 3 weeks

<AWK> https://www.w3.org/WAI/GL/wiki/Scribe_List

<Kathy> I will do next week

spaces are available up to may

<laura> I will

<Mike_Elledge> Mike E will do the 25th

if you haven't scribed this year yet then go to the list and add yourself

COGA SC prioritization survey

<Joshue108> scribe list updated

awk: survey didn't get made so didn't send it out

Top three SC to review - https://www.w3.org/2002/09/wbs/35422/2017April5_top3/results (20 minutes each maximum on the call)

awk: looking at the results

have 3 items - going to try to do this for a while.... have 55 SCs - and have 13 weeks. If we were able to do 3 a week we could get through all of them

it is hard to focus on them all - so trying to focus on a few for a week

further hindered by sending out the wrong item for the last one

Target size

<Kathy> The size of the target in relation to the visible display at the default viewport size is at least 44px by 44px for pointer inputs except: when a link or control has an alternative method that has 44px by 44px touch target link is part of a block of text and it has 44px x 22px touch target

awk: that text is the entire text

<Joshue108> https://rawgit.com/w3c/wcag21/target-size_ISSUE-60/guidelines/sc/21/target-size.html

<Joshue108> JN: This isnt' what we reviewed in the survey..

<Joshue108> JN: I'm concerned by that.

awk: sent an email asking if current language

what is in github is different from the current language

awk: was a miscue
... what I or Joshue will be doing when we hear what are the priority items - we will ping the Factilitors and SC managers

<Joshue108> +1

to get language up to date

Kathy: new language - based on last set of comments there was concern about corse and fine - reviewing that. Have changed so no longer looking aqt course vs fine pointer input

have taken the least size overall

has 2 exceptions when controls have an alternative method to access it and then the big question that is still outswtanding is that when a link is part of a block of text - if there are overlapping touch target sizes. can't space those out based on fluid and responsive layouts

doesn't make sense when links are close together

talking to users and in the MATF - discussion about where the major issues are for users

a link or a button would be difficult overall as there are multiple things that are active at the same time

other places you could magnify and then activate things - such as links in a body of text

<AWK> https://rawgit.com/w3c/wcag21/target-size_ISSUE-60/guidelines/sc/21/target-size.html SC now updated in Github

if you were going to reduce the requirements anywhere blocks of text would be a place

<Zakim> JF, you wanted to ask if Key-board accessible = "alternative method"

JF: havea requirement that links need to be keyboard accessible - is that an alternative method

<Lisa_Seeman> sorry i am late folks. meeting ran over

kathy: need to update language to be an alternate control - not an alternative method

it does say that the alternative method has a 44x44 touch target

need to update that to clarify

JF: have an issue dictating sizes to web designers - going to get a lot of pushback

<Joshue108> JN: I've a couple of comments but we need an exception when the only layout that makes sense is an on sceen keyboard.

<Joshue108> JN: If that is 44px each that wont fit on an iphone.

<Joshue108> JN: Dont see how that will work. There are also issues with wearables.

<Joshue108> JN: Is that covered by our language?

<Joshue108> JN: I don't think so.

<Joshue108> KW: We'll have to look at that.

<Joshue108> JN: These are dealt with by recovery and correction - small touch targets.

<Joshue108> JN: So hitting the right thing isn't the main thing - as long as its close enough.

<Joshue108> JN: Error correction methods are used in small keyboards etc.

<Joshue108> KW: They also have auto correction etc

<Lisa_Seeman> autpo correction fix it to the wronge word for me most of the time

<Joshue108> JN: Yes.

Kim: have 2 questions

<Zakim> KimD, you wanted to ask if this requires multiple UI's now - especially with a touch laptop...

in the proposal I wonder what it is in the text.

will be impossible for some types of content like footnotes

2nd question is does this require a seperate UI

Kathy: lots of different ways to accomplish that

Kim: if they are smaller than the size you couldn't use the overlap. That is where we would mandate the 44x44 pixel

<Joshue108> JN: Just to comment on the footnotes one - you can scroll down to reach those.

<Joshue108> JN: The alternate here is scrolling for example.

Kim: in a legal document could have another button to allow to get to those footnotes

Kathy: if you have a bunch of footnotes which have a small touch target it is an issue for an end user - if there is another way such as scrolling then that would be an alternative way to get them

Kim: the footnote itself - not the link to the footnote itself. Those can contain links. If the whole paragraph is ID and a link to something then you can't rteally fix that by scrolling to the bottom

AWK: it might be helpful with an example dcocument

DMD: this came out of the mobile TF. Trying to fix that people on small screens - that was the primary reason as i understand it

Kathy: could be shaking etc. not just a big finger on a small screen

DMD: what we are now proposing is to adopt the apple mobile SC and port those to desktop environments

<jon_avila> or a person with low vision or problems with depth perception that may not be able to precisely touch the exact area

this is a perfect example( footnotes) where little tiny lines would have to be much bigger. Most sites would fail this right now. We would be talking abotu a major rewite of the entire web. Would be lots of buy-in for small screens but lots of orgs wont want this on desktop environments

<JF> +1 to DMD's concerns

<JF> this appears to be over-reaching

DMD: understand there are difficulties - not a perfect answer but may be a way through

AWK: can you think of any language which may help clarify this

DMD: my proposed compromise doesn't seem like it would fly from certain members of the list

AWK: we need to do some more work - and need to move on

<David-MacDonald> The compromise would be to use mobile break points. Small screens have large target requirements.

LS: was going to suggest using a mechanism and then personalization could take care of it

Adapting Text

<AWK> Major items to address in previous item

<AWK> exception for mandatory layouts

<AWK> sizes and viewport sizes and personalization

<AWK> language around alternative methods and what that is

<steverep> Add exception for math content to that

AWK: seems to be a little bit closer due to raw numbers

<laura> A proposed edit to address Bruce's suggestions is at:

<laura> https://github.com/w3c/wcag21/issues/78#issuecomment-290810047

AWK: is the GH version the current version

Laura: just rewording

<Joshue108> AWK: James you had issues..

<Joshue108> JN: It could work fine for HTML content.. but dont know about Flash JAVA etc

<Joshue108> JN: It looks like it could be widgets etc , which we dont want.

<Joshue108> JN: But if platforms aren't going to do this, how it this going to work.

<Joshue108> JN: You would need a customisation to support this, right?

<Joshue108> AWK: Getting that stuff into Flash, JAVA etc would be difficult.

<Joshue108> LC: Alastair is working on something for this.

<jon_avila> the content would support it

<Joshue108> JN: I didn't know that.

<Joshue108> LC: Look thru the thread.

LS: so my question would be that we wanted paragraph spacing and blocks of text

<David-MacDonald> Here's that discussion about mobile https://github.com/w3c/wcag21/issues/78#issuecomment-268001666

<laura> The Low Vision Task Force discussed Lisa's request to add an extra bullet for extra spacing between columns and resolved not to do so.

<laura> https://www.w3.org/2017/03/30-lvtf-minutes.html#item01

Laura: LVTF discussed at last meeting - resolved not to add that bullet point

<laura> As Alastair pointed out it impacts layout far more than the other bullets and is a step up in requirements.

<laura> https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/

it would be higher impact than what we want to do for this SC

LS: means we still need that as a seperate SC then

AWK: Detlev raised another issue

I find the addition of the "at least one different..." confusing.

Why not just plain font family, foreground colour, background color?

I tried to diligently read through the comments in issue 78 but at some point lost nerve, or lost track; so while there must have been a good reason to include this, I am pretty sure users of WCAG will find it quite confusing.

<laura> At one time for color we had used Wayne's suggestion of the ability to override "text color and background color to a single different text color and a single different background color".

Laura: at one time had different text (above)

<laura> David objected to that.

<Joshue108> -q

laura: just have to prove that each one can be overriden

<allanj> https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/

<Joshue108> JN: The issue is saying that mobile would be exempt?

<Joshue108> LC: It was

<Joshue108> JN: Is that still the case? Requiring that for all sites on mobile wont happen.

<Joshue108> LC: This could fly in the face of current a11y support.

<Joshue108> JN: For AAA this may be ok.

<Joshue108> LC: The Low Vis need is for desktop at the moment.

<Joshue108> LC: They can do other things on mobile.

<Zakim> Joshue, you wanted to say that maybe it is sufficient for a user to be able to modify these things.

<jon_avila> I wonder if there are different languages that require different fonts and changing to one font on the page would cause content to be missing or unusable

JOC: giving the capability to change things is good. Would be an open door. There would be a question mark over measuring conformace.

DMD: support this SC. I'm interested in a mobile exception. If there is language in the SC to override the accessibility support - then get back into that mobile vs desktop thing

Laura: bruce was really against that

<jon_avila> If the content support adaption it should pass even if it doesn't work on mobile

<jon_avila> it's about the content supporting the capabilities

DMD: was bruce's concern leaving out people or that WCAG couldn't support the ability to do thaty
... we can scope an SC to size of screen\

<Zakim> Greg, you wanted to get ensure there is consensus that this requires the page to provide an override mechanism where the UA doesn't provide it, rather than just to be compatible

<Joshue108> +1 to Greg

Greg: former is asking a lot - and might be contentious. Requiring pages to still work when overridden is much more reasonable.

<Greg> Is there consensus that this requires the page to provide an override mechanism where the UA doesn't provide it, rather than just to be compatible when attributes are overridden at the client side? Last week it seemed some people disagreed.

AWK: when adaptations are put in place the content still can be used is the 2nd one

<KimD> +1 to Greg (require supporting browser/OS changes, not customization settings w/in website, app, etc.)

Greg: if at the client side things are overridden - things still work. That acknowledges that there are clients this will not work with - but can still get the majority of the SC through.

essentially a non interference

<Greg> I consider the highest priority be that a page remains fully functional when the formatting is overridden. Even if mobile UA doesn’t support such overriding today, that can be changed over time.

AWK: I don't think that is what the SC is saying today

<Greg> The current wording is ambiguous.

<Lisa_Seeman> issue with that is you dont know how the user will do it

<Zakim> relates, you wanted to the discussion about personalisation

JF: want to say (Jon Avila) stated this. jon_avila> If the content support adaption it should pass even if it doesn't work on mobile

<jon_avila> it's about the content supporting the capabilities

JF: I don't believe we have an issue

kathy: in the accessibility settings there are ways of doing things today
... we don't mandate accessibility support - that is up tot he organization

<JF> I don't see anything in the current text that suggests the author needs to provide a widget to provide the customization

LS: an exception could be along the lines of unless not supported in the native platform

Laura: that is what bruce objected to on the last survey

<Zakim> Joshue, you wanted to say this relates to the discussion about personalisation

JOC: in terms of direction - it is useful as a teachable moment of how things can be customized in the browser

Mike: thinking that can - when we talk about silver - look at UA requirements

JF: at risk of people throwing things at me. could say only use linked style sheets not inlinestyles

<jon_avila> It's more than that though -- it's fixed size containers -- no overflow off

<Joshue108> JN: You can override inline styles with a user style sheet also.

<Joshue108> JF: Yup

<AWK> Main issues:

<AWK> Applicability to mobile, Flash, Java, etc when user agents don't support

<AWK> conformance being superficial (only one option)

<Greg> Ideally we would split this into two SC: Level A to work when author formatting is overridden, and Level AAA to provide its own mechanism to override the formatting.

<AWK> Greg's point - perhaps this should be an SC to speak to non-interference where adaptability is used

Greg: wan't talking about exceptions for mobile or otherwise

<JF> +1 to Greg's suggestion (A and a AAA SC - 2 in total)

RESOLUTION: Needs more work.

Accidental Activation

<David-MacDonald> https://github.com/w3c/wcag21/issues/65

<David-MacDonald> https://rawgit.com/w3c/wcag21/accidental-activation_ISSUE-65/guidelines/sc/21/accidental-activation.html

Kathy: language is the most current version

<Kathy> Up-Event: The activation of a component when the trigger stimulus is released. On different platforms the "up-event" may be called different things, such as "touchend" or "mouseup". Example: For touchscreen interaction, the event is triggered when a finger is lifted from the touchscreen at the end of a tap.

david had suggested some new language

<David-MacDonald> https://github.com/w3c/wcag21/issues/65#issuecomment-277798644

<Joshue108> JN: I've issues with this - I don't like the single pointer activation.

<Joshue108> JN: It needs to be defined more.

<AWK> Issue: defining single-pointer activation

<trackbot> Created ISSUE-47 - Defining single-pointer activation. Please complete additional details at <http://www.w3.org/WAI/GL/track/issues/47/edit>.

<Joshue108> JN: There are things currently known - but may not have the down up model.

<Kathy> https://github.com/w3c/wcag21/issues/65

<David-MacDonald> https://rawgit.com/w3c/wcag21/accidental-activation_ISSUE-65/guidelines/terms/21/up-event.html

<Joshue108> ISSUE: How to tighten conformance model for Adapting Text SC

<trackbot> Created ISSUE-48 - How to tighten conformance model for adapting text sc. Please complete additional details at <http://www.w3.org/WAI/GL/track/issues/48/edit>.

<Joshue108> JN: Defined as it is, is good. I'd not seen that.

<Joshue108> JN: This will be modality specific and limits it from having negative consequences.

<Joshue108> JN: Should be ok!

<Joshue108> JN: I don't want to require keyboard interfaces etc for things.

<JF> +1 to James

<Joshue108> AWK: Is this tech specific or modality specific?

<Joshue108> KW: This is just specific to single point activation.

<Joshue108> JN: What about eye tracking etc?

<Joshue108> JF: Speech?

<Joshue108> JN: It clarifies that it doesn't apply as there is no contact with the screen with eye tracking.

<Joshue108> JN: What is the mapping to up events with eye tracking for example?

<Joshue108> KW: This is specific to pointers only.

<Joshue108> KW: We would not want to open that up further.

<Joshue108> JN: We don't want to limit new technologies.

<Joshue108> KW: We've spent a lot of time working this out.

<David-MacDonald> >One point of contact with the screen, "contact" is in the definition

<David-MacDonald> It could be further described in the understanding

KW: it is narrow already

<Joshue108> JOC: Are you comfortable that it relates solely to pointer type devices?

KW: may find we want to exapnd in the future - but for now this is very narrowly focused

AWK: would this cover a mouse?

<Zakim> steverep, you wanted to ask about platform assistive technology restrictions and drag and drop events

steverep: wondering about definition for platform assistive technologies. If something remaps the touch gestures which is not the OS shipped screen reader - are they responsible for it?

KW: have touch with AT - and no accidental activation. The 2 are very close. Put that note in - to say there is another one which uses that note

steverep: if i need to remap touch that is on the user not the content

other thing is if there is a missed opportunity for DND events. Would be exempt by the timing exception. If you accidentally DND something the uzser could benefit by being asked to confirm or reverse it

<Zakim> Greg, you wanted to say the first bullet item should be reworded to "Activation is on the platform's generic activation/click event, or explicitly on the up-event", so that the

<Greg> Given the second bullet covers when the page explicitly makes activation on up-event, the first bullet can be simply "Activation is on the platform's generic activation/click event;".

Greg: could be simplifed as the 2nd bullet makes the activation on up - the first bullet could be using the click

<Joshue108> KW: They are different scenarios.

first bullet is using the platform event

the 2nd is a mechanism of doing that

greg: I don't think the wording does that
... way i read the current wording - if I use the standard click event i would not comply as I have not satisifed that

I would need to go with one of the other bullets to comply

greg: the first is applicable only on closed systems

KW: can't mix acccessibility support - can't require any specific platform here.

if the generic platform one isn't on up event and haven't done it on up event then need to do one of the other techniques

greg: if i have a generic plain html document i would have to do 2-5

KW: could do touch up event

greg: can't be sure we are running on a browser where activation is on up.

you cannot be sure there is not a browser where you can't do it on the down event

<Joshue108> +1 to Kathy

KW: could say IE period
... not clear on anything

DMD: this is a non issue to me

AWK: no time to wrap and do the CFC

<Mike_Elledge> bye all

- DRAFT -

Accessibility Guidelines Working Group Teleconference

04 Apr 2017

Attendees

Contents