W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2011

minutes 13 October 2011

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 13 Oct 2011 13:35:49 -0500
Message-ID: <CA+=z1WmrO+P2V7CZ9URwktpd2_7xg48vBOowPr_NVRJhWyNRhQ@mail.gmail.com>
To: WAI-ua <w3c-wai-ua@w3.org>
from http://www.w3.org/2011/10/13-ua-minutes.html
User Agent Accessibility Guidelines Working Group Teleconference
13 Oct 2011

See also: IRC log http://www.w3.org/2011/10/13-ua-irc

    Jim, Kim, Kelly, Jan, Simon, Mark, Wayne, Greg
    Jim Allan, Kelly Ford
    kford, greg


        Discussion with Wayne Dick - UAAG and Low Vision users
    Summary of Action Items

Summary of Action Items
[NEW] ACTION: Kim to write SC on creating bookmarks for orienting
users after scaling or other navigation [recorded in

<trackbot> Date: 13 October 2011

<kford> Scribe: kford

JA: If you are working on mobile browser uaag review, we need to get
that going for next week.
... Looking like we will have a lot of attendance at our TPAC meeting.
Goes over names. We have 10 people asking to observe.

<JAllan> TPAC participants and

<JAllan> TPAC participants and observers
Discussion with Wayne Dick - UAAG and Low Vision users

JA: Intro for Wayne.

Wayne: Was a professor at Cal State. Have low vision. Have worked a
lot in the area of user stylesheets.
... Always interested in talking with people about this. I'm a member
of WAI's EOWG group.

Group introduces themselves.

Intros finish.

JA: Wayne, you sent in a bunch of comments. We appreciated what you had to say.

<JAllan> wayne's comments

Wayne: I only looked at your part 1.

<JAllan> Greg's comment on Wayne's stuff:

JA explains that we'll take more comments any time.

<Wayne> Can you see me

<JAllan> yes we see you

Wayne: Low vision is not a single disability. It is a cluster needing
a wide range of accomodations. At least the power of a user stylesheet
is necessary.
... For example the WCAG contrast requirmenet for 4.5 contrast would
be painful to a sizable low vision population.

Wayne goes through other examples where low vision users need varying display.

Wayne: Many low vision users use the mouse. Part of why they don't use
screen readers is because the screen reader makes the mouse tough to
... Many low vision users stick HTML pages in word and the adjust
things in word to read.

Wayne goes over various AT products like Home Page Reader, something
from Viki Handsom (sp) adapt to me.

Wayne: The need for internal AT is important. I'll send you an essay
on my thoughts there.
... It seems that many of the requirements needed for successful
reading for low vision are at triple a, and it is too low.

GL: We appreciate the comments. We have a balance between the
population that the SC will impact and the degree to which
somethinething is actually out there in the world.

KP: If you know of extensions that help here let us know.

Wayne: I'll dig up what I know about.
... My stylesheets might look like one offs but that's what needed.

Wayne gives an example of a situation where reflow of a document
skipped some key points he needed to read.

<JAllan> kf: wayne motivated to create style sheets. what is
perspective on user population knowledge of css and how to implement.

Wayne: It took me two years to get effective stylesheets for myself.
... I've spent a year studying Javascript to get things working.
... I've learned some interesting things. At times there is an
absolute need to reset an author style.
... I have a complicated sheet for example that does a reset to I can
then start at 0.
... The variance here is so wide. This is a group of people where
glasses don't work to the only thing we have left to adjust the

<JAllan> ack

JAN: Just want to make sure we note what Wanye said but there there
are other solutions. One that might work well is sharing.

Wayne: Talks about a solution he'll be presenting soon.

<Jan1> JR: User CSS is only technique of a more general SC that
requires user control of typography

Wayne: What ultimately works is that you need to allow the user to
create the optimal seeing environment for that person.

JA: Waynce, one of your comments on tooltips.
... We've talked about this that they are not available from the keyboard.
... and that users can not modify them.

<JAllan> there are also author tool tips created with javascript, that
scale with the viewport

Wayne: It would be nice if I could put my mouse over an image and get
the alt text.

<JAllan> wayne wants a setting where the 'alt' will show up instead of title

GL: Waynce you talk about this broad spectrum a wide range of people.
We love to talk about this in our intent document.

<JAllan> greg suggests adding character spacing and leading as part of
user modifications

<KimPatch> +1

GL: Third, thinking about the process, what is the best way to capture
the full list of Waynes' comments.

Kim: You were talking about how low vision were 30 different groups. I
think it is neat when we can merge. Losing focus when you go from
large to small and lose focus is a big impact on speech users too.
... Focus being constent matters across groups.

<JAllan> loosing point of regard when scaling window

Kim: Scrolling as little as possible for speech users is important.

<Greg> Greg's second point was that we love adding examples showing
wide range of needs and accommodations, so if Wayne can provide more
that would be great.

Kim: When you talk about switching something into word, seems like
some annotation tools around that might help?

Wayne: When you go large and lose focus it is bad. I had to do 47 page
downs one time when I shifted to the size I needed.
... A couple years ago I demonstrated a clipper product. You pick part
of a web page and say I want to read this.

Waynce: This let you keep things small while you selected and then
getting big when you started reading.

GL: This focus is really talking about not losing the point in content.

<JAllan> kim suggests having a place marker

Kim: Scrolling repeatedly is tough. Cases where is can take out your voice.

Wayne: On the iBook, they keep focus when you enlarge. They also have
good bookmarks.

<Greg> That is, as I described in my reply to Wayne's comments, was
that an SC should say the point of regard should be scrolled to be
within the visible portion of a viewport when the viewport is resized,
and when the presented size of the content within the viewport changes
due to changes in view options (e.g. zoom ratio) or content formatting
(e.g. in a word processor, rich text edit field, of...

<Greg> ...browser window set to edit mode, the user or script changes
the font size attribute of some text).

<JAllan> kf: zooming in a browser. 3/4 down the page, if you zoom do
you go to the top of the page

<JAllan> kf: ideally want to remain where you where after zooming.

<Greg> JA: What about putting something in Intent document about
maintaining point of regard?

<JAllan> gl: this needs an SC. this is a problem in FF. side bars are
especially troublesome

<Greg> GL: Strongly feel it should be an SC requirement.

<Greg> Jim: Has styler add-in that remembers what user style sheet you
want for a particular site.

<JAllan> wayne: problems with IE, FF, opera, safari

<JAllan> chrome seems to do it right.

<Greg> KP: Has users who change things breaking accessibility, and
they don't remember what they changed. Having a timeline where you can
see, or undo configuration changes, would be extremely useful.

<Greg> Jim: We have SC saying that you can make changes and reset to
default, but sounds like Kim's asking for multiple level of undo for
configuration changes.

<Greg> Kim: the concept of "Discover, Adjust, Organize and Share"
should be applied to navigation as well as to configurations (user

<Greg> Kim: That is, capture what you did so you don't have to
remember that you were 10 pages down before you got moved.

<mhakkinen> History?

<Greg> Kim: Easy way to get and use history to get back to where you were.

<Jan1> Greg: agreed

<JAllan> history is a single line. kim wants a tree

<Greg> Greg: Go Back and Forward again history commands are useful but
fall apart when you go back then take a different link, as you lose
all the places you visited after that. A more comprehensive history,
rather than just a single forward and backward list, would be more

<Greg> Jim: Sounds like Kim's suggesting quick, easy to use bookmarks.

<Greg> Kim: Bookmarks (temporary or permanent) are useful, search is
also useful, and timeline would be useful. All would be good, and
would be used by wide swatch of people.

<JAllan> scribe: greg

Greg: Could add a very general SC about providing means for users to
get back to places they'd been; might not want to be too technology
specific (e.g. browser book marks, history). Might also do specific
ones where appropriate.

Wayne: Loves ability in VoiceOver to set temporary bookmarks and jump
between them.

Jim: We've talked about how for LV users, many need modified screen or
UI but don't use AT.
... Trying to capture that in a lot of our documents.

Wayne: Also experienced adding panel or other things that change size
of viewport.

Kim: Users in Acrobat have trying to do searches, find a place, go
elsewhere, and try to search from new location it still searched from
previous search results.

Jim: Difference between where cursor is, where focus is, and where
point of regard is, and users have trouble keeping those straight.
Knowing which will change, which one is start of search or navigation,
... Anyone want to take action regarding bookmarks?

Kim: Will try.

Wayne: Will help.

Wayne sending link to his short list of stylesheets for us to look at,
as well as his style test HTML document.

<JAllan> ACTION: Kim to write SC on creating bookmarks for orienting
users after scaling or other navigation [recorded in

<trackbot> Created ACTION-622 - Write SC on creating bookmarks for
orienting users after scaling or other navigation [on Kimberly Patch -
due 2011-10-20].

Jim: Re point of regard, Wayne talked about things being truncated,
has he had problem with losing customization when content is printed

Wayne: Yes, content often truncated on the right. His style sheets
compensate for this.

<JAllan> greg coments:

<JAllan> greg coments:

<Wayne> http://www.csulb.edu/~wed/Dylan/css/

Wayne: Those style sheets work very well at Opera, but unfortunately
other browsers don't turn off their styles, so to get things to work
you have to mark everything as !important. The ones with I appended to
end has !important on everything to work better with IE, Firefox, etc.
... VRLV really want tools that provide voice only when and where
needed, not all the time.
... Most commonly get books from bookshare.org, convert to epub, apply
own style sheet, move onto iPad. Works well unless you want light on
dark, where iPad iBook reader insists links must be dark blue, ruining
light on dark configurations.

Jim: When reviewing the UAAG20 document, we have lots on navigation
and structural navigation in particular, such as navigating by
headings, and would appreciate your feedback on that because of its
importance to low vision readers.

Wayne: Critical, as when you look at sight range for "low vision" you
get roughly 100 to 25 words per page.
... His own vision varies during the day from roughly 100 down to 50
words per page (screen).
... Discussing how different access methods work best for different tasks.

Jim: Be warned that numbers have changed in the document since the
last time he reviewed it.

Wayne: Uses VoiceOver in lightning reading mode to go through it
quickly to get overview, then go back in detail.

Jim: If Wayne is willing, would like feedback on the Implementing
document which has more explanations, rationales, and examples.
Anything he could add would be greatly appreciated.

Wayne: Should be working on it by the end of the month.

[End of minutes]

Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Thursday, 13 October 2011 18:36:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:40 UTC