W3C

Site Navigation

Nearby

Results of Questionnaire Issues (18 Jan) - Accessibility Requirements for Low Vision Users

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: shawn@w3.org,jimallan@tsbvi.edu

This questionnaire was open from 2016-01-18 to 2016-01-26.

5 answers have been received.

Jump to results for question:

  1. Hyphenation
  2. Low Vision Incidence
  3. Functional Vision - movement
  4. [done] Size of All Elements
  5. [done for now] Seeing All Interface Elements
  6. [done] Proportional text increase
  7. [done for now] Margins and Borders

1. Hyphenation

Section 3.2.6 Hyphenation
Does hyphenation best fit under tracking, or is there a better place for it?

Where is the best fit for Hyphenation?

Details

Responder Hyphenation
Laura Carlson Hyphenation seems to fit in the tracking section.
Jim Allan tracking works for me.
Erich Manser Alternately, under 3.4 Spacing for Reading
Shawn Lawton Henry I don't see a better place for it.
Wayne Dick Hyphenation and breaking words without hyphens is most appropriate with re sizing text. Unbreakable text strings like extremely long words and hyper-links that include no hyphens can prevent word wrapping. Consider the word psychologically. It has 15 characters. This can exceed the screen size for 72 point font on a 13 inch screen. Typically the screen will hole 12-14 characters. The word must break. A hyperlink like http://Community_Healthcare_System_Long_Beach.org just doesn't fit. This wouldn't even fit on a 13 inch screen at 36 point font.

2. Low Vision Incidence

In Section 2.2
WHO includes correctable & non-correctable. Do we want to include statistics in region(s) where correction is more available? Is there a good stat that goes across regions, not just one country?

Thoughts? Suggestions for stats?

Details

Responder Low Vision Incidence
Laura Carlson I am not aware of any but if stats of region(s) where correction is more available exists, we could add it. But it probably is unnecessary.
Jim Allan I think it is immaterial to filter correctable/non-correctable. If you can't get correction, you still don't see well...you are impaired. This is a "First World" discussion. I am fine with using the WHO. There is also this http://www.who.int/blindness/GLOBALDATAFINALforweb.pdf that includes percentages for global regions.
Erich Manser WHO stats could add value
Shawn Lawton Henry I think stick just with WHO unless we find something else compelling.
Interesting point, Jim! https://www.w3.org/2002/09/wbs/81151/LVTF18Jan2016/results#xq2
Wayne Dick I am afraid of uncorrectable low vision not being taken seriously. I hate excluding people without choice, but there are 8 million people in the US who just do not choose to use correction.

3. Functional Vision - movement

In section 2.5 Functional Vision
* Movement, for example, reading on a train [@@ LVTF question: Is this notably different for people low vision versus people with "normal" vision?]

Is "movement" an important environmental factor -- that is, is it more of a factor for folks with low vision?

Details

Responder Functional Vision - movement
Laura Carlson I'm not sure. If low vision is combined with a vestibular disability maybe.

"balance, clear vision during head movements and correct spatial orientation entail the processing of visual, vestibular and somatosensory afferent input to produce adaptive eye and body movements and a correct spatial sensation. Disequilibrium, blurred vision and dizziness or vertigo may ensue, if there is any sensory deficit, abnormal stimulation or defective central processing..." - E. Mira
http://www.medscape.com/viewarticle/568873_2
Jim Allan low vision user (sensory system) is already working harder to see. Adding a dynamic environment (things moving - user, environment, or both) is more difficult for a sensory system that is already working harder to process information. Yes, this is important.
Erich Manser Would not expect any additional effects from movement specific to low vision users.
Shawn Lawton Henry Some research: https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Research#Movement_and_Low_Vision (found by Laura & Jim's colleague)
Wayne Dick For me movement is not the problem. When I read on public transit the problem is lack of space and removal of my best assistive technology. Bouncing and starts and stops are a problem, but the real problem not having good technology.

4. [done] Size of All Elements

Update 20 Jan: RESOLUTION: Size of All Elements - keep together minutes on size

In the User Requirements section, under the Perceiving category, there is a rough draft of Size of All Elements.

We have a separate point for increasing text size. The draft of this point covers overall zoom/magnification, as well as some specifics: text cursor and mouse pointer. Are there other examples? Do we want all the these combined? Or, do we want these separated out, e.g., since we know that some are often provided by operating systems and others by browsers? What suggestions do you have for revising this point?

Details

Responder [done] Size of All Elements
Laura Carlson Unless a compelling advantage for separating exists, combining is fine with me. Are we going to identify separate OS, browser, and author requirements?
Jim Allan Keeping separate makes sense. different responsibilities. see https://lists.w3.org/Archives/Public/w3c-wai-ig/2016JanMar/0081.html
Erich Manser
Shawn Lawton Henry
Wayne Dick We may need to add some elements. When appropriate, scroll bars. Also, there are important UA items like tabs, and titles within tabs.

5. [done for now] Seeing All Interface Elements

Update 20 Jan: To be tweaked based on input from minutes on seeing all

In the User Requirements section, under the draft Work with User Settings category, there is a rough draft of Seeing All Interface Elements.

UAAG has a specific requirement for scroll bars, but in the 13 Jan call, we talked about making this more broad rather than specifically requiring scroll bars. Above is a rough draft idea combining this with the previous point "flexible text areas". Should this be one point or more than one? Ideas for rewriting or polishing this?

Details

Responder [done for now] Seeing All Interface Elements
Laura Carlson Broad rather than specifically requiring scroll bars could be a more future proof approach.

I noticed a couple of typos:

"When the areas cannot be resized to accommodate all content, usually a a scrollbar..."
Should be:
"When the areas cannot be resized to accommodate all content, usually a scrollbar..."

"Scrollbars generally provide the additional benefit of communicating where the user is is an interface."
Should be:
"Scrollbars generally provide the additional benefit of communicating where the user is in an interface."
Jim Allan
Erich Manser
Shawn Lawton Henry
Wayne Dick Language: text areas is not <textarea>.
This may sound excessive, but you cannot believe the nit-picky way serious concept papers of mine have been dismissed for simple confusions like this.

More important this is a proximity issue in which users cannot even reach the necessary items.

6. [done] Proportional text increase

Update 20 Jan: RESOLUTION: This is adequately covered. Don’t need 3.5.2 "Proportional text increase" as a separate point. minutes on proportional

In the User Requirements section, under the Identifying Elements category, is a point on Proportional text increase.

Perhaps this user need is sufficiently covered in other points: Zoom would provide proportional zoom; Text size lets the user text an overall text size; Element-level customization lets the user set size on headings. This was included in UAAG, but maybe we don't need a separate point for it?

Details

Responder [done] Proportional text increase
Laura Carlson It is beneficial to make authors and vendors aware that headings can become too big. Many are not aware of that fact.

The "Element-level customization" point in the January 17, 2016 Editor's Draft seems to cover that sufficiently. I currently don't see a need for a separate point.
Jim Allan
Erich Manser
Shawn Lawton Henry
Wayne Dick Shawn's point of ease of customization is important and should not be lost, but full element level access means that one can choose to set the enlargement percentage to the same value for all elements.

7. [done for now] Margins and Borders

Update 20 Jan: Leaving it as a separate point in readability section (and leaving it as subpoint in identifying elements) and to be tweaked to make it more clear how it relates to readability. minutes on margins

In the User Requirements section, under the Spacing for Reading category, is a point on Margins and Borders.

Does it make sense for these to be together, or would it be better for them to be separate?

Details

Responder [done for now] Margins and Borders
Laura Carlson It seems to make sense for "Margins and Borders" to be together, if we are hinging the borders requirement on wide margins as the draft currently does. It says: "margins could make line length too short...Therefore, some people might need borders."

I noticed a typo:

"to separate clocks of text.."
Should be:
"to separate blocks of text..."
Jim Allan separate make sense. keeps things cleaner.
Erich Manser
Shawn Lawton Henry
Wayne Dick Margins make lines find able, and borders help to bracket sections of related material. This needs to be clear.

More details on responses

  • Erich Manser: last responded on 20, January 2016 at 20:55 (UTC)
  • Shawn Lawton Henry: last responded on 20, January 2016 at 21:39 (UTC)
  • Wayne Dick: last responded on 21, January 2016 at 23:24 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Katie Haritos-Shea
  2. Bruce Bailey
  3. Alastair Campbell
  4. Jonathan Avila
  5. John Rochford
  6. Scott McCormack
  7. Rachael Bradley Montgomery
  8. Charles Adams

Send an email to all the non-responders.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.