LVTF Documents
User Requirements Doc
- Editors' Draft: Accessibility Requirements for People with Low Vision Draft
- Published Working Draft: Accessibility Requirements for People with Low Vision
- The details below were discussed in 4 Nov 2015 telecon and some in 13 Jan 2016 telecon
Purpose
- Document low vision user needs/requirements related to web accessibility
- Provide the basis for future work on possible WCAG techniques, understanding, extensions, and other guidance
Out of scope for this doc - to be elsewhere:
- Help developers, designers, etc. understand generally how people with low vision use the web
- comment: Realistically, how many developers, designers, etc. will actually read this Note? Instead of trying to reach this audience with this Note, do we want a different publication/format for which they are the primary audience? e.g., a WAI Resource page or a Tutorial or such that doesn't have the front matter and rigidity of a Note? Perhaps EOWG could help with that? {shawn}
Audience
Primary:
- Standards and guidelines developers – including LVTF for WCAG materials, as well as others beyond WAI
Secondary:
- Content developers, designers, writers, etc. (might have different resource where they are primary audience)
- User Agent developers, designers, etc. (might have different resource where they are primary audience)
Scope
- Cover broad issues, including what might be provided by content, user agents, authoring tools
- Minor mention of hardware aspects (like turning down screen brightness) and OS aspects (like high contrast mode)
- This Note will be focused on a short overview of low vision and explanations of user requirements. Additional details will go in separate non-TR pages on the W3C/WAI website. (13Jan2016 minutes)
Content Notes
- Overview of low vision issues
- What users need in interfaces (see Scope above)
- Focus on general needs. Mention but not focus on specific problems in current environment (e.g., mouse pointer covers tooltip text).
- Not include specific potential techniques, SC, etc. at this point — that will be separate.
- Leave out for first draft but possibly include later: Impact/priorities (e.g., no horizontal scroll is high and justification is lower).
- Provide checklist someway (could be filter just the user requirements or an appendix list or whatever)
Out of scope for this doc - to be elsewhere:
- User experience stories (not the specific issues that we have documented in US-UC wiki page, but more general experiences)
- Supporting Research
Title ideas
brainstorms:
- Low Vision User Accessibility Requirements or Low Vision User Requirements
- comment: although it's simple, does it put the emphasis on the users instead of accessibility ? some of the others do, too. {shawn}
- +1s in 4 Nov 2015 telecon
- comment: some concern that "low vision users" is not people-first language {shawn}
- Low Vision Accessibility User Needs
- Low Vision Accessibility Requirements
- Accessibility Needs of People with Low Vision
- Understanding Low Vision Accessibility
- Accessibility Requirements of People with Low Vision
- Web Accessibility Needs of People with Low Vision
misc notes
Previous thoughts on structure for user needs note:
- these are who LV users are (overview)
- functional limitations (e.g. low acuity - larger font size)
- these are their visual content needs
- appendix: map functional limitations to low vision conditions
from 30 Sept agenda
Archive: Deliverables
The LVTF initially considered the following possible deliverables:
- User Requirements doc
- Delta/Gap Analysis - user requirements covered in existing WCAG, UAAG, and ATAG
- WCAG 2.0 Extension
- WCAG 2.0 Techniques – edits to existing techniques and/or new techniques – including sufficient, advisory, failure
- WCAG 2.0 Understanding – edits to existing and/or new
- WAI resource - maybe tutorial or other type - that is less formal and easier to update than a TR publication, and is specifically targeted to designers & developers
- Wiki - Some wiki pages are just internal information gathering and processing, and others we might want to be more polished to point to, e.g., the research page