W3C

- DRAFT -

Low Vision Accessibility Task Force Teleconference

27 Jan 2016

See also: IRC log

Attendees

Present
Erich, Wayne, Shawn, Laura, JohnR, AlanSmith, jon_avila
Regrets
Jim
Chair
Andrew
Scribe
jon_avila

Contents


<AWK> Trackbot, start meeting

<trackbot> Meeting: Low Vision Accessibility Task Force Teleconference

<trackbot> Date: 27 January 2016

<AWK> Chair: AWK

<AWK> +AWK

<laura> Low Vision TF Scribe List:

<laura> https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Scribe_List

survey Review Requirements https://www.w3.org/2002/09/wbs/81151/UserNeeds-Jan-27/results

<scribe> scribe: jon_avila

Who is going to CSUN?

<shawn> Shawn is going

<AWK> I am

<Wayne> wayne going

awk: who is going to csun?

I am

<AWK> Alan is not

<laura> Laura not going.

<AWK> john R not going

<Erich> Erich not going

survey Review Requirements https://www.w3.org/2002/09/wbs/81151/UserNeeds-Jan-27/results

awk: talking about the title? Are we happy with it as it is now?

User needs vs user requirements <https://www.w3.org/2002/09/wbs/81151/UserNeeds-Jan-27/results#xq2>

<Wayne> I like requiermets

awk: back to terminology, user needs versus user requirements.

wayne: likes requirements
... looks like a trial spec, I think requirements is better

awk: Shawn mildly prefers user needs
... don't have strong feelings. Doesn't appear that most people do Shawn more so internal to the document.

<Zakim> shawn, you wanted to say How about requirements for title and user needs for section -- which is what it is now

Shawn: concern that we aren't saying each one of these is a WCAG requirement. Approach have requirements in title and then have sections say user needs.

<shawn> http://w3c.github.io/low-vision-a11y-tf/requirements.html#user-needs

shawn: essentially what we have now.
... Section 3 is titled user needs

<JohnRochford> +1 to leaving it as it is

erich: want to support people first approach. Requirements could sound like people demand this.
... What are people more likely to do if the standard is rigid versus something else? Comfortable with softer wording if it make it more palatable

shawn: What we have may strike that balance

+1

awk: This document is separate from what WCAG and UAAG requires and time will tell how this maps to a future extension. Trying to position this document as a standalone document.

shawn: We should continue to position it that way in the introduction

RESOLUTION: Keep requirements in title and keep user needs in interior sections

Note title <https://www.w3.org/2002/09/wbs/81151/UserNeeds-Jan-27/results#xq3>

<shawn> The issue is "Low Vision User"

awk: no immediate consensus that emerges. I'm not unhappy with the current title. We've discussed this before. Would be happy with title or could flip to users with with lwo vision.

<shawn> ( and Laura commetns about issues with "user")

laura: like wording of people first language without user

+1 to laura

<AWK> Laura suggests: "Accessibility Requirements for People with Low Vision"

alana: people with low vision would sound better

<Wayne> +1

johnR: equivalent to saying people who are blind

<shawn> Accessibility Requirements of People with Low Vision

johnr: people first, we just happen to have a disability

awk: not a fan of the text "of"

shawn: concern with word "for" as these are their requirements

awk: It's not about presenting this gift but the other meaning of for

<Wayne> of+

<Alan_Smith> Alan: I need to drop for 11 o'clock business meeting.

<JohnRochford> I too need to drop off at 11

from reference.com intended to belong to, or be used in connection with: equipment for the army; a closet for dishes.

<JohnRochford> +1 for for

<shawn> can live with for

<Alan_Smith> welcome, try for full engagement again next week and beyond. Regards.

awk: accessibility requirements for people with low vision
... any objections?

RESOLUTION: title Accessibility Requirements for People with Low Vision

Do not include additional stats? <https://www.w3.org/2002/09/wbs/81151/LVTF18Jan2016/results#xq2>

awk: Do we want to include stats where correction is less achievable?

wayne: afraid that uncorrected low vision not being taken serious

awk: sounds like we stick with what we have unless more data that we happen upon

<shawn> +1

wayne: so hard to get careful study -- managed to get US study

shawn: want to emphasis that this is big -- but we perhaps the addition information could be in a separate place

awk: sounds like it a useful additional resource that we could put the AMA study there on the WAI pages.
... any objections to sticking to what we have?

RESOLUTION: stick with what we have for low vision incidence - stick with stats we have

Leave movement? <https://www.w3.org/2002/09/wbs/81151/LVTF18Jan2016/results#xq3>

awk: is movement when reading on a train different for people with low vision for people who do not? Is it an factor that effects users with low vision?

shawn: what if we shortcut this. This is a pretty minor thing. I wonder if we have an objection or concern with leaving it. It's a minor point in the document.

awk: just in 2.5 under environmental factors include... we talk about it anywhere else
... next we talk about how people sometimes have control over environmental factors.

no thoughts either way

awk: any objections to leave it as it is as a minor note?

RESOLUTION: Leave movement bullet as is

Leave hyphenation in tracking? <https://www.w3.org/2002/09/wbs/81151/LVTF18Jan2016/results#xq5>

awk: hyphenation currently under 3.2.6 -- is it best under tracking or somewhere else?

wayne: most appropriate with resizing text and large hpyerlinks can affect word wrapping

shawn: text size is under perceiving. No main heading for resize text. Hyphenation becomes more of an issue when text size increases.

wayne: doesn't say what issue it is. Could imply that you shouldn't use it. You need hyphenation to get more words on page with large print.

<shawn> current wording: "Some people with very large text may prefer hyphenation on so that more characters fit on a line of text."

shawn: It says that some people may prefer hyphenation because you can get more characters on a line.

wayne: long hyperlinks stretches out the page. Things that don't break mess up text size.

shawn: Is this related to tracking b/c when it does not wrap it causes issue with tracking? Perhaps we could add explanation.

<Zakim> AWK, you wanted to say that our "perceiving" section refers to recognizing characters

<shawn> ACTION: shawn & wayne write for WAI page hyphenation and word breaking, e.g., URI screws up wrapping overall https://www.w3.org/2002/09/wbs/81151/LVTF18Jan2016/results#xq2 [recorded in http://www.w3.org/2016/01/27-lvtf-minutes.html#action01]

<trackbot> Created ACTION-30 - & wayne write for wai page hyphenation and word breaking, e.g., uri screws up wrapping overall https://www.w3.org/2002/09/wbs/81151/lvtf18jan2016/results#xq2 [on Shawn Henry - due 2016-02-03].

awk: we don't talk about identifying words only characters in perceiving

+1 to awk

<shawn> +1 to awk

shawn: took and action to write up with Wayne to explain overall issue more
... would be good to point to WAI page with some images.

awk: Right now support seems to support in leave in tracking

<shawn> +1 to leave in tracking

awk: Erich what do you think?

Erich: tracking is good

awk: any objections to leaving hyphenation in 3.2?

RESOLUTION: leave hyphenation in Tracking

Visual Acuity section heading <https://www.w3.org/2002/09/wbs/81151/UserNeeds-Jan-27/results#xq6>

awk; bouncing to other survey

awk: balancing clarity with accuracy
... Jim says acuity is more accurate and known

<shawn> jon: low vision misunderstood... blurry... functional vision more important than visual acuity

<Wayne> I like clarity in parens

<shawn> I'm OK with "Visual Acuity (Clarity)"

awk: people seem to be ok with adding clarity in paranthesis

Field of Vision section heading <https://www.w3.org/2002/09/wbs/81151/UserNeeds-Jan-27/results#xq7>

RESOLUTION: Add in clarity in parenthesis in section on Visual Acuity with editorial permission

erich: my feelings where similar to acuity
... think of addition term we could put in parenthesis

<Zakim> shawn, you wanted to say perceptual area seems too awkward (unlike clarity). field of vision is clear enough

wayne: field actually makes sense to what I experience

shawn: perceptual area is confusing. Don't think people will say that.
... why add another term that we have to explain

awk: I think we were trying to distinguish between field versus ability to obtain clarity. Field loss can be a side effect

shawn: makes sense now. At one point we had combined functional limitations and now it is split up. Happy to take action to cover that second aspect.
... before it was called perceptual area and now it may make sense to just be visual field

laura: should be ok if we remove perceptual area

awk: any objections to remove perceptual area?

<shawn> ACTION: Shawn check that issue of people with large text have small bit of info is covered well [recorded in http://www.w3.org/2016/01/27-lvtf-minutes.html#action02]

<trackbot> Created ACTION-31 - Check that issue of people with large text have small bit of info is covered well [on Shawn Henry - due 2016-02-03].

awk: Shawn will make sure we discuss types of field loss

RESOLUTION: remove perceptual area parenthetical text when talking about field of vision

shawn: items are in most important order

corrected terminology <https://www.w3.org/2002/09/wbs/81151/UserNeeds-Jan-27/results#xq5>

awk: one more -- corrected terminology

shawn: this was question #4 on survey

awk: corrected or not corrected. Jim says used in field and in documentation.

<shawn> Wayne: I am in favor

wayne: will take note to check terminology -- this should be ok here. Was thinking to expansive when I made that comment.

awk: Laura says she can live with it if it is consensus

+1

<shawn> shawn OK with it

awk: any objections to go with corrected?

RESOLUTION: Go with "corrected" terminology

awk: thank you everyone. Plan on meeting same time next week.

trackbot end meeting

Summary of Action Items

[NEW] ACTION: shawn & wayne write for WAI page hyphenation and word breaking, e.g., URI screws up wrapping overall https://www.w3.org/2002/09/wbs/81151/LVTF18Jan2016/results#xq2 [recorded in http://www.w3.org/2016/01/27-lvtf-minutes.html#action01]
[NEW] ACTION: Shawn check that issue of people with large text have small bit of info is covered well [recorded in http://www.w3.org/2016/01/27-lvtf-minutes.html#action02]
 

Summary of Resolutions

  1. Keep requirements in title and keep user needs in interior sections
  2. title Accessibility Requirements for People with Low Vision
  3. stick with what we have for low vision incidence - stick with stats we have
  4. Leave movement bullet as is
  5. leave hyphenation in Tracking
  6. Add in clarity in parenthesis in section on Visual Acuity with editorial permission
  7. remove perceptual area parenthetical text when talking about field of vision
  8. Go with "corrected" terminology
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/01/27 16:45:40 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/hyphenation in 3.2/hyphenation in Tracking/
Succeeded: s/corrective/corrected/
Found Scribe: jon_avila
Inferring ScribeNick: jon_avila

WARNING: Replacing list of attendees.
Old list: AWK Laura John Alan Andrew Shawn Wayne jon_avila
New list: Erich

Default Present: Erich

WARNING: Replacing previous Present list. (Old list: Laura, John, Alan, Andrew, Shawn, Wayne, jon_avila, Erich, JohnRochford)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Erich

Present: Erich Wayne Shawn Laura JohnR AlanSmith jon_avila
Regrets: Jim
Found Date: 27 Jan 2016
Guessing minutes URL: http://www.w3.org/2016/01/27-lvtf-minutes.html
People with action items: shawn

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


[End of scribe.perl diagnostic output]