W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

25 May 2017

See also: IRC log

Attendees

Present
jasonjgw, steverep, Laura, MichaelC, Joshue108, alastairc, ScottM, chriscm
Regrets
Chair
Joshue108
Scribe
Laura

Contents


<ScottM> Is there updated call info?

<AWK> +AWK

<scribe> Scribe: Laura

<davidmacdonald> I'm not able to join, says meeting hasn't started

<Joshue108> thats not the right channel

thanks, jim.

ACT TF Update

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

<AWK> Current version: https://rawgit.com/w3c/wcag21/resize-content_ISSUE-77/guidelines/sc/21/resize-content.html

joc: this issue 77
... wwe had vetted and approved this issue. Now we are having further discussion.
... thumbs up so far. It is improving.
... what is the current staus?

AC: has gone thruough the comments.
... rephrased for exception. instread of fix spaiial layout.
... Now at level AA
... 1.4.4 is still needed.
... now “zoom content” instead of resize content
... some remaining issues:
... What if the text is already huge?
... would need examples
... What if the text is already huge? open to suggestions.
... Is it ok to have the 1280px starting point in the testability section but not the SC?
... If not, should we move to saying, "content should work at 320 CSS pixels wide".

<Zakim> AWK, you wanted to suggest changing "which require two-dimensional layout" to "which require a specific two-dimensional layout"

joc: good work. Thanks.

awk: editorial comments.
... should say specific dimensional layout.
... little concerned 2.0 resize text now 2.1 zoom content.

<Zakim> steverep_, you wanted to say I think single line inputs are already covered in the exception

steve: single line input is already covered. add it to an example.

<allanj> +1 steve 2d layout for single line input form control

AC: happy with that.

<Crystal_Jones> how do i put myself in queue?

AC: It is about native text inputs which are only one line, as filling it in will require scrolling.
... happy to have it as an excception.

awk: shouldn't be an issue.

<Zakim> Joshue, you wanted to say what does this mean in relating to hard resize vs zoom?

joc: what does this mean in relating to hard resize vs zoom?

ac: curernt SC is still needed as a fallback.
... currrent one still needed. and promoted.

<Zakim> Crystal, you wanted to say

cj: what is the test scenario?

<alastairc> First line of the testability: Display content in a user agent capable of zooming 400% and start with a window width of 1280px at a 100% zoom level.

cj: will it be spelled out?

ac: it is in the testability section.

awk: wouldn't be applicable to all scenarios.

AC: See FAQ: Mobile devices start smaller, how does that work?
... not a content issue.
... The main principle here is that the web content must be capable of resizing, it is not a device-specific issue.
... have a note to that effect.

<alastairc> NB: Mobile devices are by necessity more limited in how they can resize content. This success criteria is to ensure the content is capable of resizing to a reasonable degree. In practice people will need to use a device or user-agent capable of reflowing content such as a desktop or laptop computer.

awk: needs to be in the SC text.

cj: doesn't have to be on mobile to fail.
... will get different results.

<alastairc> The original exception: If the user-agent fits the layout to the viewport and does not provide a means of reflowing content, bidirectional scrolling is exempt.

cj: if you decrease the size of the window still not on a 1280 display.

<allanj> change screen resolution to 1280 x 720

cj: another issue does the device support it?

<alastairc> Or, we start the SC text with: Content displays at 320 CSS pixels wide without loss of content or functionality

joc: sounds like a contrived issue.

<allanj> I just tested on my machine. changed resolution of monitor to 1280 x 720. responsive site is still responsive to 500% in chrome

cj: SC does not spell out the environment for testing.

joc: we need to be technology agnostic.

wayne: could create a table.
... come up with a formula for it.
... can do the calculation for it. It is fairly accurate.

david: can get different results based on screen size.
... starting to see the concern.
... we need to be super clear. maybe in the language of the SC.

joc: maybe have exemptions?

david: make a condition.
... when tested on a 1280.
... when viewed on a 1280 content can be magnified by 400 percent.

ac: appreciate the concern.
... device independent test.

<Joshue108> +1

<AWK> Can we see that in IRC to digest?

<alastairc> Content displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.

david: maybe have an or clause.

AC: propose SC text “Content displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.”

<davidmacdonald> Content can be zoomed to 400% OR displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.

chris: scaling down. Mac can do down pretty low. Don’t want to focus on this issue. If the OS is capable we should consider it.

<chriscm> McMeeking

wayne: we can refer to a table in the SC.

<alastairc> Note - resolution is a different things from what size web content works at.

wayne: we need to think about if we should tie the SC to a number.
... need to think about forward comaptiablity.

awk: 320px width on a small phone. This SC wouldn’t impact it.

AC: yes. need to define pixel width. Question on id it is the SC text or technique.

<AWK> Content can be zoomed to 400% OR displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.

<AWK> vs

<AWK> Content displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.

joc: likes david’s suggestion.

<alastairc> Should it still start with Zoom content: Content display at...

<alastairc> ?

<wayne> +1 to zoom

<Joshue108> Content can be zoomed to 400% OR displays at 320 CSS pixels wide without loss of visibility or functionality [...]

david: Having it in SC will be less problematic.

<wayne> +1 to zoom 4 or 320

<AWK> Rethinking and liking the specific testability of just the 320px, without the 400% zoom

<Rachael> possible editor note: Should it be displayed (vs displays)

JOC: preference for which goes first?

<AWK> Content displays at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require a specific two-dimensional layout for usage or meaning.

AC: no.

joc: helps having both clauses in the SC text.

<Zakim> steverep_, you wanted to say that specifying a CSS pixel width is one option, but another might be to better define zoom

steve: agree with AC. an’t test the or statement.

<AWK> +1 to Steve

<alastairc> q_+

steve: maybe better to define what zooming really means.

wayne: maybe do need to define zooming.
... 400 percent should be in there. so the intent is apparent.

<davidmacdonald> Content can be viewed at 320 CSS pixels wide without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning. Note: 320px is a 400% zoom at 1280px

wayne: for legislators.
... okay with the OR statement.
... need normative definition of zooming.

awk: comming around to definition of zooming.
... need “at least” in SC text.
... qualifier can help make the percentage clear.

AC: resolution vs CSS pixels. Conern of including both.

<alastairc> Content can be zoomed to at an equivalent of 320 CSS pixels wide without

AC: maybe have “Content can be zoomed to at an equivalent of 320 CSS pixels wide without”
... zoom increasing the size of pixels.
... we need a starting and ending point.

<alastairc> starting OR ending point is needed

david: like AC’s proposal.

<AWK> "Content can be displayed at a minimum width of 320 CSS pixels without loss of content or functionality…"

al: also CSS pixel forward compatibility is an issue.

AC: CSS pixel has been stable.

David: think we should go forward with this language.

AC: will incorpoate.

RESOLUTION: Leave open, alastair to work on edits

RESOLUTION: Leave open.

Summary of Action Items

Summary of Resolutions

  1. Leave open, alastair to work on edits
  2. Leave open.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/05/25 16:32:29 $

Scribe.perl diagnostic output

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

Present: jasonjgw steverep Laura MichaelC Joshue108 alastairc ScottM chriscm
Found Scribe: Laura
Inferring ScribeNick: laura
Found Date: 25 May 2017
Guessing minutes URL: http://www.w3.org/2017/05/25-ag-minutes.html
People with action items: 

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


[End of scribe.perl diagnostic output]