<AWK> +AWK

<AWK> Scribe: Mike_Pluke

<lisa> what is the password again ?

<lisa> for the webex

<lisa> thank u

<gowerm> That's mike gower actually

yes, but can't find the webex password

Sorry thought it had changed

Currently no consensus in surveys

]zakim, next item

Resize Content: https://www.w3.org/2002/09/wbs/35422/ResizeContent-issue77/results

Good results from the Resize Content survey - 8 ready to go

David's OK with going live with 400% even though he'd be happier with 300%

Kim felt that her company would not meet 400% without scrolling. They might have to opt out of 2.1

<davidmacdonald> mike can you mute

Kim's still OK with going ahead with this as it is not impossible

Detlev shares Greg's thoughts on lowering the bar for text that is already large. Fears that there might be some push back as it will be very hard to meet.

LV TF's proposals started at 1600%, so already signiticantly down from that.

Michael Gower's comments raised concern regarding mobile.

Michael also sees no benefit in being A rather than AA as everyone uses A and AA and not just A

<kirkwood> +1 to reflow ability

<jon_avila> It is possible to reflow but not allow resize up to 400%

Mike Gower asked What would we lose if this only specified text.

Stephen Repsher's comment reference to "conflicts" related to SCs that refer to 200%

Mike Elledge realised that he was confused between resizing text at AA and content at 400% - seems to be in conflict

<AWK> === what is a fixed spatial layout?

<jon_avila> The menu could collapse and expand

Alex asked questions related to horizontal menu bar or ribbon at the top

<Greg> Alex, I would suggest menu bars wrap to multiple lines, like other content.

<Zakim> alastairc, you wanted to talk about this

Andrew is after an answer to what is a "fixed spatial layout" referred to in Alex's question

<gowerm> +1 agreed: going above 200%, it really doesn't matter what the target is.

Alistair concludes that if you go beyond 200% it doesn't matter much if you go to 300% or 400%. 400% difference between old iPhones and a laptop.

Linearization to help LV users who tend to override layouts.

Alistair discussed A versus AA. Confusing because of not wanting to change the current SC. Lose any 2-d information when linearization.

The current resize text SC is a good fallback for things that go in the exception.

Making one a higher level than the other would mean re-writing the existing one.

The 400% is easier to test than tests related to reflow.

Dispute over whether responsive content sites lose content when reflowed.

Decided that adding an exception for mobile is not related to the content.

<AWK> === Alex also concerned about wide menubar paradigm in this case

Alex felt that his answer related to what constitutes a fixed layout has not been answered.

<Zakim> MichaelC, you wanted to say we should think of the ¨major reno¨ approach to policy targets

<alastairc> @alex_and_crystal Have you read the 'intial responses' here? https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Resize_content_issues_review

Michael C: Shouldn't use implementability on retrofit as a criteria for rejection?

<KimD> *thanks MichaelC for the clarification about retrofitting v new dev

<jon_avila> Electronic Health Records requires on Level A in the US

<jon_avila> yes

<Alex_and_Crystal> @alastairc, no I have not read it. But how does that address the questions?

<jon_avila> until 2021

<alastairc> @alex_and_crystal See the bit starting: The "fixed spatial layout" does need better definition and examples (in the understanding document), which would include:

Canada is not yet AA, but will be by 2021.

<Bruce_Bailey> Ontario started with Single A though, yes?

<Zakim> Greg, you wanted to go over my survey comments

Jason suggests that 2.1 may be a standard for new or substantially re-written content.

<gowerm> And remember that that is WCAG 2.0 targets. If we made Resize Text A for 2.1, that would not affect any jurisdictions current guidance

<Bruce_Bailey> There are a few real-world example that demonstrate that Level A and Level AA are being used separately

Greg Lowney re his comments: Agrees with Alex that more difficult for sights that already have large text - maybe an exception is required.

<jamesn> how about zoom until your text is 64px size (for example)

<gowerm> @Bruce_Bailey, agreed, but again, those are WCAG 2.0. If we move something in 2.1, that doesn't affect any current jurisdiction

<AWK> AWK: for a wide menu I'll add that the developer would have a variety of options, from adding a single menu button that then exposes the list of top-level menu items, to adding a "more"-type icon to show the next set of menu items, to wrapping the menu.

Greg Lowney: The role of native controls. The content of a field may be wider than the visible screen and may need scrolling.

<AWK> === what is the role of the UA for web content? Implication for mobile UA....

Greg wanted Clarification on the role of web-based user agents. Clarify what is required of them.

<Alex_and_Crystal> @alastairc, thanks for that. I am looking for something along this line. Of course, we need definition text, not just examples.

<adam_solomon> native controls should come under the exception of spatial layout

<alastairc> Just to note, I've answered most things, but I do need to go back and address comments from Greg (Lowney) and JakeAbma

RESOLUTION: Leave open

Plain Language: https://www.w3.org/2002/09/wbs/35422/plainLanguage-min-Issue30/

<Greg> See my my survey comments for more details.

<alastairc> @Alex_and_Crystal sure, does that need to be in the SC text or understanding?

<Bruce_Bailey> @gowerm, I am just saying it feels premature to me to give up on A/AA/AAA for 2.1 at the moment...

<Alex_and_Crystal> @alastairc, either in sc text or definition

Laura's question about who is going to maintain the 1500 word vocabulary

Lisa: The answer is that the 1500 word list has to be publicly listed.

A lot of concerns over the 1500 word concept - either not enough compared to say what WCAG has

Lisa says that all comments have been dealt with, but Andrew suggested that ongoing comments suggest that this has not been fully resolved.

<Alex_and_Crystal> Is 1500 a number derived from research & which language?

<Zakim> JF, you wanted to ask "In the public" how? where? in what format?

Stephen Repsher wants to see at least something in the normative test about where the list comes from

<Ryladog> http://www.lflegal.com/

<lisa> all non testable

Katie suggests that having a summary and a link

<Zakim> Bruce_Bailey, you wanted to ask where 1500 came from

<lisa> there are brudcasting program tha do that too

Bruce wonders where the 1500 number came from (could be smaller or much larger). Some books provide a list of words used at the end (maybe an approach).

<JF> +1 to Jason

<Bruce_Bailey> I would like to know if it is allowed for the content author provide the list of 1500 words they used.

Jason Concerns about internationalization because of lack of word lists in different languages. Different vocabularies used in each language. Also still issues with different application domains.

Lisa suggests that if we don't get the word list idea in, there won't be a significant benefit for many users.

Lisa suggests that need to separate concerns regarding how the word list concept can be implemented versus those that think that there is no value in the concept at all

<jon_avila> seems like instructions would include words like checkbox, radio button, button, drop down. So we'd need to make sure common core words include all control names.

Lisa argued that after 1500 words, the extra words are relatively obscure. Should allow general communication with this number of words. Additional context specific word lists can be added to this.

<Bruce_Bailey> Here is an example of ten hundred words in English:

<Bruce_Bailey> https://simple.wiktionary.org/wiki/Wiktionary:Most_frequent_1000_words_in_English

<Alex_and_Crystal> Is it just me or did the audio dropped?

<lisa> just you

<gowerm> 3.1.5 Reading Level: When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available. (Level AAA)

<lisa> reading level is not helpful

<lisa> also does not work internationaly

Mike Gower thinks that this is an important topic. Wondered how Headings and Labels is of a similar level of generality compared to other SCs got into WCAG 2.0.

Also questions why reading-level could not be used - never heard the full rationale against.

<lisa> words can be easy to read and not simple, such as the word "mode"

<gowerm> "Reading level is not helpful" is not a helpful explanation

<gowerm> right, and "mode" at a elementary school level would not be on the list

Adam solomon that the 1500 word list would come from the body acquiring the system.

<AWK> === concern about internationalization - do we know?

Question to Lisa - is this cross-language threshold?

<Ryladog> Interesting comment from Adam Solomon: "that the 1500 word list would come from the body acquiring the system."

Would it be possible to raise the language a bit for any languages where it might 1500 words might not be appropriate (e.g. to 1600/1700)

<Bruce_Bailey> Maybe OT, but here is the Saturn V rocket explained with ten hundred words:

<Bruce_Bailey> http://xkcd.com/1133/

English, Hebrew and Arabic are languages that have been considered.

<gowerm> @lisa This is the note from Reading Level. "According to the Open Society Mental Health Initiative, the concept of Easy to Read cannot be universal, and it will not be possible to write a text that will suit the abilities of all people with literacy and comprehension problems. Using the clearest and simplest language appropriate is highly desirable, but the WCAG Working Group could not find...

<gowerm> ...a way to test whether this had been achieved. The use of reading level is a way to introduce testability into a Success Criterion that encourages clear writing. Supplementary content can be a powerful technique for people with some classes of cognitive disability. "

<lisa> that is why we have a scope

Alex - a hammer looking for a nail situation. Comprehension is a complex issue - every time you draw a line there is a significant cost to things like freedom of speech.

<AWK> === should this be a personalization issue instead of a defined threshold?

<laura> SC is scoped to: error messages that require a response to continue, instructions, labels and navigational elements

Alex - ought to be a personalization issue - not convinced by the universality of the 1500 words limit.

Scope doesn't make it a freedom of speech issue - e.g. for buttons, etc.

<gowerm> don't know

<AWK> Is there a chance of a 1500 word limit getting through?

<JF> -1 (sorry)

<KimD> -1 I cannot support the 1500 words at this time

<JakeAbma> -1 for now

<Alex_and_Crystal> -1

<Bruce_Bailey> +1 yes, with the edits I proposed in survey

<jamesn> -1

<AWK> -1

<Rachael> -1

<lisa> also in the tecniques you can add it as an attribute fso you can use wnay text you like

<Kathy> -1

<gowerm> 0 still waiting

<Detlev> abstain

<jon_avila> 0

<davidmacdonald> In today's technology environment -1 Maybe in future

<Ryladog> +1

0

RESOLUTION: leave open

<alastairc> -1 at the moment, just not clear on who would be responsible for it.

<Mike_Elledge> -1 I think it will rely too much on others creating controlled vocabularies :^ (

Target Size: https://www.w3.org/2002/09/wbs/35422/SCreview_May_17/#wbsq4

<Kathy> Several points of clarification: - Target does not mean size of the link or button. Can have padding or spacing around the interactive control for the touch target area - Increasing the touch target size, does not necessarily mean larger keyboard focus indicator – see Patrick's mock up- http://codepen.io/patrickhlauke/pen/aBNREe - Increasing target size to 44x44 CSS pixels can be accomplished using CSS using pointer events and does not require scripting

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

<AWK> https://github.com/w3c/wcag21/issues/60#issuecomment-301830356

Kathy clarifying that 44 pixel does not mean the focus indicators etc. get bigger - just the target size

So really a CSS change to accomplish this. Proposals that should not just be links, so example also includes blocks of text

<davidmacdonald> Option 1 +1 exception for links in blocks of text

3 options described

<Bruce_Bailey> +1 for Option 1: Inline: The target is a text link in a block of text.

James Nurthen can do padding using CSS only, but that is inflexible. If change extra size of the padding to suit the circumstances cannot be done entirely in CSS.

<JF> native controls today (<button>, <select>, etc.) will all fail this SC out of the box

<Zakim> steverep, you wanted to correct that it is not guaranteed that the visual indicator does not expand

<Ryladog> +1 for Option 1: Inline: The target is a text link in a block of text.

<Bruce_Bailey> I don't object to exception for In-Page (The target is a text link where the destination is on the same page), but where did that come from?

Steve Repsher - visual focus indicator expands and overlaps the words?

<jon_avila> so it sounds like you are talking about NVDA's focus ring plug-in?

<Kathy> yes I think it is NVDA focus ring

John - if start doing reflow you will have 2 links overlapping, and the second link will overlap the first - making it much smaller such that it will fail

<jon_avila> agree with John -- I think we should just exempt inline interactive content as z-index overlap will be issues

<AWK> === concern about overlapping items creating a smaller target for overlapped item

<AWK> === impact on native controls?

<Zakim> Bruce_Bailey, you wanted to ask if full-screen interactives (every pixel is a touch point) fail this?

John has real concerns that everything out there is going to fail

Bruce - does something like Google maps will fail?

<Detlev> Can we have a vote on acceptance of excluding targets in blocks of text?

<Kathy> Option 1: Inline: The target is a text link in a block of text. Option 2: Inline: The target is in a block of text.

Kathy - No as the interactive targets are essential

<alastairc> I'd prefer option 2, followed by 3.

Not worrying about in-line items in a line of text is one possible exception.

Alex - have you looked at a target that is not a square or rectangle and the spacing between targets?

<AWK> === question about non-square targets

The studies done my the TF suggested that the actual target size is more important than the spacing

<jon_avila> Perhaps a radius of 22 css pixels from a centroid

<jon_avila> the finger contact though is translated as a point - so the shape of the finger is not relevant

Looked at the industry standards and these were all looking at square targets. Alex was actually more concerned with non-rectangular targets such as a circle.

<Alex_and_Crystal> @jon_avila, but the accuracy changes over a radius, not square

<laura> Spacing metrics in the Adapting text SC are currently: line spacing 1.5, letter spacing 0.12 em, word spacing 0.16 em.

Kathy suggests a slider up the page may fall into the essential layout exception. Andrew concerned that this is a narrow control.

<laura> may be some synergy between this SC and the adapting text SC.

<jon_avila> agree with Detlev

<AWK> Straw poll: Option 1: Inline: The target is a text link in a block of text. Option 2: Inline: The target is in a block of text. or 3=not sure/something else

Detlev interested in thoughts on option 2 - to fully exclude targets in blocks of text

<Ryladog> 1

<Bruce_Bailey> +1 to option 1

<gowerm> Option 1 preferred. Can live with 2

<Detlev> 2

<jamesn> 2

<jon_avila> 2

<laura> Option 1 preferred. Can live with 2

<KimD> 3

<Rachael> 2

<JakeAbma> 2

<jamesn> (can live with 1 though)

<AWK> 2

<Rachael> (also can live with 1)

<Ryladog> I can live with2 also

<steverep> 2 (I think?)

<jasonjgw> 3 - I worry that the exceptions tend to cover too many of the cases where this will be a problem for users.

2

<Bruce_Bailey> Option 2 permits small gifs inline with text. Those seem problematic to me.

RESOLUTION: Leave open

<laura> bye

<Mike_Elledge> Bye all

trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Nurthern/Nurthen/
Default Present: AWK, JakeAbma, Laura, alastairc, MikeGower, Bruce_Bailey, MelanieP, Detlev, MaryJoMueller, marcjohlic, Rachael, ChrisLoiselle, KimD, Katie_Haritos-Shea, Elledge, Pluke, steverep, Greg_Lowney, MichaelC, kirkwood, adam_solomon, JF, jamesn

WARNING: Replacing previous Present list. (Old list: (no, one))
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK

Present: AWK JakeAbma Laura alastairc MikeGower Bruce_Bailey MelanieP Detlev MaryJoMueller marcjohlic Rachael ChrisLoiselle KimD Katie_Haritos-Shea Mike Elledge Pluke steverep Greg_Lowney MichaelC kirkwood adam_solomon JF jamesn
Regrets: Makoto Lauriat Glenda Pietro
Found Scribe: Mike_Pluke
Inferring ScribeNick: Mike_Pluke
Found Date: 16 May 2017
Guessing minutes URL: http://www.w3.org/2017/05/16-ag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.