<scribe> Scribe: Wayne

Section 2.5: Functional Vision https://github.com/w3c/low-vision-a11y-tf/issues/73

<ScottM> +1

RESOLUTION: Accept point 1a

<ScottM> Did te meeting start before 11?

RESOLUTION: Accept point 1b

<shawn> ok

<allanj> will change effective to functional

<allanj> wd: visual clutter is a design issue

shawn: What is the user need?

<allanj> lc: do we address clutter in the document...need to add visual clutter as a term

laura: a way to remove clutter.

scott: After my surgery my brain would shut down with too much clutter.
...: Give guidelines as to what is color.

<allanj> ja: add 'visual clutter' to 'other factors'

<allanj> wd: yes, but we need explanation and perhaps a user need (explains his issues with clutter)'

<allanj> sh: is a user need, separate or expansion of another.

<allanj> wd: clutter is separating figure from ground

<ScottM> Aree it's both

sh: It is tha aspect of the information design.

<allanj> wd: the architecture of the environment - doesn't matter how or what caused the clutter. Clutter is still an issue

Sh: We all agree it is a user need.
..: We are just talking about physical environment.

<shawn> SM: then it's a user need, not environment

sh: The point is so important we don't want to just add it to our list, we aer making it a UN.

<allanj> ja: change 'Environmental factors include:' to 'Environmental factors include (but not limited to):'

ja: Change title of list to include but not limited to.. should do it.

<allanj> sh: make it too formal

<ScottM> I think we just need to make sure it states that environmental factors are PHYSICAL (real world) environmetal factors and not design elements of a page

<allanj> sm: we are not trying to be all inclusive. clutter is a design aspect, not a physical environmental factor.

<ScottM> •Clarity of the device, for example, dots-per-inch (dpi)

<allanj> ... we need to clarify that we are talking about Physical environment

<laura> Physical Environment: http://www.wmpho.org.uk/topics/page.aspx?id=1538

<shawn> I'm OK with "Environmental factors include:"

<shawn> I'm OK with "Physical environmental factors include:"

<ScottM> Environmental (Physical) Factors include: ?

RESOLUTION: We will create or extend a user need regarding clutter.

<ScottM> Visual clutter on a web page = ADS

Disclaimer draft (action-58) https://github.com/w3c/low-vision-a11y-tf/issues/67

<shawn> action items in GitHub: https://github.com/w3c/low-vision-a11y-tf/issues/73#issuecomment-224936049

<trackbot> Error finding 'items'. You can review and register nicknames at <http://www.w3.org/WAI/GL/low-vision-a11y-tf/track/users>.

<shawn> How about something simple like this for a short paragraph right under the [h2] Overview of Low Vision?:

<shawn> This section provides basic information about low vision related to information and communication technologies. It is not intended to provide formal definitions of terms. It is intended to provide background information for understanding user experiences and user needs.

<shawn> in this section: http://w3c.github.io/low-vision-a11y-tf/requirements.html#overview-of-low-vision

RESOLUTION: Adopt disclaimer language above.

User Access to Necessary Customization

<allanj> https://github.com/w3c/low-vision-a11y-tf/issues/74

<shawn> WD: ok if acceprt principle that users adjust doc to meet their needs. that's kinda an overriding guideline

<shawn> "Users must be capable of adjusting the visual interface to meet their exact visual needs."

<shawn> ACTION: Shawn consider how the main point of <https://github.com/w3c/low-vision-a11y-tf/issues/74> is addressed in current User Needs doc - probably in text under 3. User Needs <http://w3c.github.io/low-vision-a11y-tf/requirements.html#user-needs> (see also 9 June minutes) [recorded in http://www.w3.org/2016/06/09-lvtf-minutes.html#action01]

<trackbot> Created ACTION-62 - Consider how the main point of <https://github.com/w3c/low-vision-a11y-tf/issues/74> is addressed in current user needs doc - probably in text under 3. user needs <http://w3c.github.io/low-vision-a11y-tf/requirements.html#user-needs> (see also 9 june minutes) [on Shawn Henry - due 2016-06-16].

<shawn> ... [Wayne more about this GitHub issue]

<allanj> wd: interface with COGA and Personalizations

Begin working on SC - acceptance criteria (review), walk the gap analysis (proposed - WCAG needs SC before Dec 2016)

<allanj> Acceptance Criteria WCAG 2.1 (very draft)

<allanj> Ensure that requirements may be applied across technologies including markup and not markup, open and proprietary, web technologies.

<allanj> All success criteria will be mapped to the function requirements it aims to meet.

<allanj> Ensure that the conformance requirements are testable (Automatic or human)

<allanj> Utilize the WCAG 2.0 A/AA/AAA structure.

<allanj> Success criteria need to be as broad as possible without becoming a 'catch-all' for any given requirement. (But the wording must be such that it CAN apply to all — or wording has to limit its application to what it should (can) apply to )

<allanj> Candidate success criteria will be peer reviewed and if too great in scope will be broken into more granular requirements.

<allanj> They must not be technology specific.

aj: W3 wants to get out the requirements for 2.1 by the end of 2017 (DEC)

<allanj> They should be worded as statements that are true or false.

<allanj> They are statements of 'what is'- when the statement is true - then you have met the SC.

<allanj> All in proposal stage - Strawman

aj: The proposed structure for SCs is still in draft (straw person)
... Proposal: Starting with gaps try to work in SCs to fill in the gaps.
... WCAG is going to want WCAG SCs. However, we should write UA changes while we are at it.

<allanj> wd: user need element navigation apart from AT

<allanj> sh: user needs X, that need may be met by UAs, given current state of real world do these things still need to be in WCAG.

sh: We need to talk about. In the real word people need. Do user needs need to be located in WCAG.
... Users can do X then content developers can determines if UA does it.

<ScottM> Content autors are not locking things down more now than less

<allanj> accessibility supported covers "until user agents to X"

<ScottM> sorry content authors are locking things down more now than not

<allanj> wd: most of the user needs can be accomplished in HTML. If a site meets responsive design, then can replace style sheet to do whatever through media queries.

<allanj> ... technology independent. must have structured content.

<allanj> ... UAs have lots of information about structure.

<allanj> ... many are look to WCAG:Next

<allanj> ... currently the burden is on the author

<ScottM> the average user is going to be totally dependant upon their UA or AT to make customizations

<allanj> sh: what can be done vs what the average user can do

<ScottM> authors are locking things down blocking UA changes even with responsive design, for example some users are using desktops at 1024x768 and then getting tablet pages

<shawn> not thinking of adding burden to authors

<allanj> wd: if you design your page properly much is easy to do.

<allanj> sm: even with responsive design, authors are locking more things down. Making it difficult to change

SM: Authors lock down displays. The issue is that the average user is going to be dependent on the user agent.

<allanj> sm: authors looking at screen dimensions not UA identification for presentation
..: Some users need low resolution. As a result where the RWD force him onto mobile. Things are locking things down.

ja: In many cases RWD can be inflexible design.

sh: We need to give the user the choice.

<allanj> sh: user should be given the choice as to what view the user wants at whatever resolution

sm: BART in sf gives you a mobile site.
... They did RWD, the user must go through a lot of UI oberhead.

<allanj> THIS IS A GOOD SC - authors should give users a choice of view (desktop, tablet, mobile) depending on viewport size

SM: At lower screen size functionality is lost.

<allanj> wd: agrees with SM. things have gotten very complicated with stylesheets

<shawn> ACTION: Shawn think if choice of view in a responsive design (desktop, tablet, mobile) is a user need? [recorded in http://www.w3.org/2016/06/09-lvtf-minutes.html#action02]

<trackbot> Created ACTION-63 - Think if choice of view in a responsive design (desktop, tablet, mobile) is a user need? [on Shawn Henry - due 2016-06-16].

<allanj> +1 to action 63

<allanj> wd: users will never write their own stylesheets. just like they dont write their on screen reader. Users need a profile.

<allanj> wd: authors cannot limit users ability to change visual environment

<shawn> ACTION: Shawn consider with action 63 "authors cannot limit users ability to change visual environment" [recorded in http://www.w3.org/2016/06/09-lvtf-minutes.html#action03]

<trackbot> Created ACTION-64 - Consider with action 63 "authors cannot limit users ability to change visual environment" [on Shawn Henry - due 2016-06-16].

<ScottM> +1

<ScottM> Do we have a list of tese SCs we need to write?

<allanj> https://w3c.github.io/low-vision-a11y-tf/WC-UA-alignment.html

trackbot, end meeting

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/It is tha aspect of the environmental design./It is tha aspect of the information design./
Succeeded: s/We all agree it is an environmental factor./We all agree it is a user need./
Found Scribe: Wayne
Inferring ScribeNick: Wayne
Default Present: Jim, Wayne, shawn, Laura, Scott
Present: Jim Wayne shawn Laura Scott
Regrets: JohnR JonA
Found Date: 09 Jun 2016
Guessing minutes URL: http://www.w3.org/2016/06/09-lvtf-minutes.html
People with action items: shawn

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