See also: IRC log
<David-macdonald> what is the webex number... can someone send an invit tot the list?
<ScottM> +ScottM
<David-macdonald> can someone please send an invite to the list?
<Joshue108> Scribenick: Glenda
<David-macdonald> IS THERE ANYONE HEARING ME!!!!!!!!???
<Joshue108> https://github.com/w3c/wcag21/issues/60
Josh: Kathy has updated to the text for Target Size. Any points from discussion on Tuesday that anyone wants to go over or carry on today?
JF: struggle with a target size
that always has to be a size of 44 css pixels square.
... worried about onscreen keyboard with this SC would make the
size of that onscreen keyboard so big, it would require
horizontal scrolling.
... mobile device breakpoint of 360px and keyboard with 10 keys
on top row 44 css px wide = 440 p = scrolling
Wayne: we have reached breakpoint of technology and agnostic. When you start talking about SC that are visually based, and you have to take into account 40 inch display to 4 inch display. This is a new space. We may be forced to revist technology agnostic when there are such vast differences.
<Lisa_Seeman> option one "a mechanisim is availible so that"
<Zakim> Joshue, you wanted to ask about using relative sizes
<Lisa_Seeman> option 2 " unless......."
Josh: is the problem that we are setting a specific CSS px size?
<Lisa_Seeman> options 3: give two alterntives
Wayne: Alastair addressed this with css px and the expected viewing differences for that device.
Josh: can we drop a hard size, and go with a relative size?
Lisa: 3 mechanisms that I can
think of that may help experts solve the problem. 1) Problem
with approach we prefer, add “one of the following is true”.
Think of something that maybe isn’t as good, but could
work.
... giving two options can allow an SC to get through
2) If you word it as “a mechanism is available” you can perhaps solve it through personalization
Lisa: 3) Use of an exception (when you can quatifiy where it does not work)
<laura> mechanism sets off the unending widget discussion.
Jason: Already have ability to
detect interactive elements. Someone could write a technology
that alllows for a preference to just enlarge target size, or
enlarge the control and the target size and allow scrolling.
Possibly devide this SC into two pieces.
... Good idea to step back and think which of this SC would be
better addressed by User Agents versus Content/Developers.
<Zakim> Greg, you wanted to say that perhaps if a page wants to be truly touch accessible it needs to react to small screen sizes and wrap intelligently, rather than say it can use
<Greg> Perhaps if a page wants to be truly touch accessible it needs to react to small screen sizes and wrap intelligently, rather than say it can use controls too small to be targeted easily
<Greg> That is, a page with an on-screen keyboard can use any keycap size it wants, as long as it provides the option to make them at least 44x44 (per bullet 2) without requiring horizontal scrolling (in order to comply with another SC).
<Greg> Language like “A mechanism exists to let the user access all functionality through targets that are at least 44 by 44 CSS px” would let bullets 2 and 3 go away.
<Greg> On the other hand, as someone replied to my comment on Tuesday, we can certainly keep it as it is without breaking anything, merely requiring some pages to claim conformance only on devices with screens above a minimum size.
JF: understand Greg’s direction. Question: How do you apply this to responsive design? Concerned about applying this at scale on large sites and this is too subjective. Which is more important, avoiding horizontal scroll or making sure that targets are large enough?
<Greg> "A mechanism exists" also handles text links by allowing the user to bump up the text size to get link 22 or 44 px tall.
Josh: we will resurvey this again.
<JF> There was also the problem with native controls
<JF> and their size
RESOLUTION: Working group will resurvey this item language proposal
<Greg> John, I believe that for pages which want to use inaccessible design by default (e.g. small targets), they should have to support or provide alternative presentation options. The user should be able to to choose which SC they want to comply with, based on what's important to them at that time in their situation.
<Joshue108> https://rawgit.com/w3c/wcag21/adapting-text_ISSUE-74-78-79/guidelines/sc/21/adapting-text.html
<laura> Proposal D
<laura> https://github.com/w3c/wcag21/issues/78#issuecomment-291618718
<laura> Proposal E F
<laura> https://github.com/w3c/wcag21/issues/78#issuecomment-291918379
<laura> Jon Avila had an idea on how to deal with scoping
<laura> https://github.com/w3c/wcag21/issues/78#issuecomment-292174184
Laura: Tuesday call has main issues in minutes. See github issue URLs Laura just entered here.
<laura> “If the technologies being used can achieve the following, text styles of the page can be overridden as detailed below with no loss of essential content or functionality.”
<steverep> Proposal G is now on GitHub with the following exception: Content presented in a technology which does not support changing text syles is exempt if either (a) a supported technology could not achieve the same content, or (b) text styles are not applicable to the content
<Ryladog> "“If technologies being used can achieve it, text styles of the page can be overridden (without losing <https://www.w3.org/TR/WCAG20/#essentialdef> essential content or functionality) as follows:”"
Josh: can you distill the difference in these proposals.
Laura: proposal D - when a
mechanism is used, emphasis on when.
... proposals E and F are in tandum.
... and to E and F add Katie’s refinement “If technologies
being used can achieve it, text styles of the page can be
overridden (without losing <https://www.w3.org/TR/WCAG20/#essentialdef>
essential content or functionality) as follows:”"
<JF> I note there is now a Proposal G
<Ryladog> 1.4.5 uses "If technologies being used can acheive" text
Laura: Level A - without a mechanism
Katie: Avila’s suggestion is
great.
... likes Avila’s suggestion here “If technologies being used
can achieve it, text styles of the page can be overridden
(without losing <https://www.w3.org/TR/WCAG20/#essentialdef>
essential content or functionality) as follows:”" and then she
massaged it a bit to get this : add Katie’s refinement “If
technologies being used can achieve it, text styles of the page
can be overridden (without losing <https://www.w3.org/TR/WCAG20/#essentialdef>
essential content or functionality) as follows:”"
SteveRep: I don’t want to give a blanket exceptoin for technologies when it could be achieved otherwise. Look at proposal G.
<David-macdonald> https://github.com/w3c/wcag21/issues/78#issuecomment-292222640
steverep: Proposal G is now on GitHub with the following exception: Content presented in a technology which does not support changing text syles is exempt if either (a) a supported technology could not achieve the same content, or (b) text styles are not applicable to the content
<laura> https://github.com/w3c/wcag21/issues/78#issuecomment-292222640
<steverep> Technology exception proposal for adapting text: Content presented in a technology which does not support changing text syles is exempt if either (a) a supported technology could not achieve the same content, or (b) text styles are not applicable to the content
<Wayne> Rough Concept-The user can change the font for text to any one of a set of fonts for their language groups.
Wayne: couple of ways to scope it. you can scope by technology. Or you can limit the choices the author has to make. Example, for font family (don’t have to be responsible for every font family that occur anywhere), maybe for each language type we could come up with a list of font families in a technique.
<Zakim> Joshue, you wanted to ask if many devs know how to ensure HTML or CSS content can be overridden.
Josh: concerned that developers would feel lost and konw how to accomplish this SC. Is this approach moot if user can override with their own stylesheet. What would block a user from overriding and getting what they need with a personal style sheet.
David-macdonald: it is a big requirement, we should weigh it very heavily. The impact on all PDFs is very high. Can this be achieved in that PDF viewer?
<allanj> with a good pdf and VIP-PDF free application. You can do all of Adapting Text SC
Laura: most of these things can be overridden in that PDF viewer.
<Joshue108> +1 to JF
<shawn> [ Shawn thinks there is still an issue with PDFs that includes forms, etc. ]
Wayne: we are not going to write off PDFs. Optimistic that PDFs can be marked up accessibly and most of these parameters can be changed. Still some work to be done, but hopeful.
<Wayne> trx.knowbility.org
Wayne: See Typographical Prescription (TRx) at https://trx.knowbility.org How a user can choose their best profile for reading.
<allanj> VIP-PDF windows, mac, linux http://snab.ch/en/hilfsmittel/digital-tools/the-first-pdf-reader-for-visually-impaired-people/
<laura> Yes. We need techniques.
Wayne: This TRx is almost ready for public consumption https://trx.knowbility.org (just working out a few more things).
<allanj> write techniques - https://www.w3.org/WAI/GL/wiki/Technique_Template
Jason: General trend is in the right direction. No lose of content or functionality when these parameters are overriden. Author’s responsibility is not to break it. We need to define how you can confirm you’ve met the requirement.
<Joshue108> +1 to Jason for common failures.
Lisa: not sure we need to create exceptions for some technology, since some companies may make changes as they see the WCAG 2.1 SC being finalized.
<steverep> +1 to that - putting a little pressure on technology developers to support this is not a bad thing
Josh: yes, that ties into the user agent responsibility to do their part too.
RESOLUTION: Options for Adapting Text to be surveyed
Jim: will we be surveying new SC? Or are we still focused on these.
Josh: we will be adding 2 new SC from COGA and 1 from LV. We are picking up new proposed SC.
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) Default Present: Greg_Lowney, MichaelC, Glenda, Laura, jasonjgw, david-macdonald, Joshue108, steverep, ScottM, JF, erich, Shawn, Katie_Haritos-Shea, kirkwood, KimD Present: Greg_Lowney MichaelC Glenda Laura jasonjgw david-macdonald Joshue108 steverep ScottM JF erich Shawn Katie_Haritos-Shea kirkwood KimD Found ScribeNick: Glenda Inferring Scribes: Glenda WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 06 Apr 2017 Guessing minutes URL: http://www.w3.org/2017/04/06-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]