Re: Fwd: Comments on UUA 2.0 Draft 6/11

Hi! I really appreciate Wayne's input and opinions. Here are his comments with some of my initial thoughts/responses inserted in curly braces with my initials, as in {GCL 2011-10-12: ...}.

<http://www.csulb.edu/%7Ewed/public/UAAG_2-1Comments-8-19-2011.html>

I am focusing on the impact of these guidelines on one specific disability group: Visual Readers with Low Vision (VR/LV).


        Guideline 1.1


Does the rendering include tool tips?  Visual readers with low vision (VR/LV) need alternative text for icons especially.  Currently the "title" attribute is displayed as a tooltip.  However, since the there is no guideline mandating use of "title" , tooltips may or may not be present in WCAG conformant documents.

*{GCL 2011-10-12: This gets tricky. Tool tips are not default content, they are a means of presenting content (alternative or otherwise). Tooltips are often used to present title attributes, which are alternative content, and should be covered by 1.1. To look a little deeper:*

**

*Icons in HTML content typically have their names given with a title attribute, which the browser presents as a tooltip. If he can see them and use a mouse, fine. If he needs to he can change the text size, colors, or font (1.4.1). If he cannot use a mouse, he can use the mouse to both navigate to the icon and activate its tooltip (2.1.1). He can also choose to have the title attribute displayed with (1.1.1) or in place of (1.1.2) the icon. These would apply regardless of how the content was implemented, even if in formats other than HTML.*


*Icons in the UI typically have tooltips giving their names. If he can see them and use a mouse, fine. If he cannot use a mouse, he can use the mouse to both navigate to the icon and activate its tooltip (2.1.1). Unfortunately, there is currently no SC that requires or even recommends that the user be able to adjust text size, color or font for user agent user interface elements such as toolbar buttons, nor is there anything requiring that the user be able to have such UA UI elements be supplemented or replaced by text alternatives; these omissions should probably be corrected.}*

The concept of substation for non-text data is faulty.  VR/LV definitely benefit form seeing both.  The an image may contain some information, but still may need information from the alt-text or long description.


*{GCL 2011-10-12: I thought we had discussed the idea that 1.1.1 should give users the options to render alternative content with or replacing its primary-content equivalent; I agree with Wayne that the user should have both options.} *

A good example is UML (Unified Modeling Language) diagrams.  For databases these can be represented with text as Data Dictionaries in a long description.  To a user with low vision, the graphical relationships expressed in the UML may be conceptually useful.  The user will see the nodes and edges even if the user cannot read the text embedded in the figure.  The figure combined with a text based data dictionary would give complete access to the text.


        Guideline 1.2 and 1.3


I am sending this in late. So, let me just overview these.

I was always taught to set alt="" when I meant the content was for decoration only.  I don't see why the image would ever be necessary. Saying anything for such an alt-text does not seem like a repair.  Repair is a murky world -- good luck.

*{GCL 2011-10-12: Users should be able to get the image name or other informative text because authors or authoring tools sometimes assign empty alt text when they should not.}*

Highlighting is a painfully urgent need for low vision.

*SC 1.3.2* is an excellent addition for low vision.  Many UA interfaces allow a nice set of fore and back color choice only to fall flat on highlighted colors.  Border is an essential color independent way do distinguish objects.


        Guideline 1.4


*SC 1.4.1* --- Global adjustment is fine, but local adjustment is also necessary.  For people in VR/LV visual semantics are as important as they are for fully sighted people.  Specifying one size for all elements eliminates on entire dimension of visual semantics.  Perhaps another criterion say Level AA permits element level configuration.  It could limit itself to: h1--h6, p, list objects, form elements (input and textarea especially), pre and <a>. *SC 1.4.2* actually gets it wrong.  The experienced visual reader with low vision will choose the paragraph and list as the optimal font to read.  That is where the heavy lifting takes place.  Headings and links are important but less dominant in terms of eye strain.  Many people make headings only slightly larger, or even smaller. The normal scale difference between heading and paragraph is usually so great that enlargement usually wastes pages of space.  It is very disruptive.  VR/LV does not need normal style but bigger.  They 
need modified style.

*{GCL 2011-10-12: Re 1.4.1, specifying one size for all elements is definitely not for everyone, or even most users with low vision, but specifically for readers with extremely limited vision who need text to be the largest possible size accommodated by their monitor. It could potentially also be useful for users of screen enlargers if they want the magnified text to be the largest possible size that fits in the magnifier window. These examples are discussed, but your concern about people thinking of it as a broad solution could be better addressed in the Intent paragraph.}*

**

*{GCL 2011-10-12: Re 1.4.2, it does not say the ratio between paragraph/body text and headings be preserved, just that the user has the option of having the two categories distinguished by size (preserving "distinctions in size"). This could be clarified in the Intent and/or Examples.}*

Here is a missing criterion. *1.4.?* (level A) When a user chooses to modify text size and / or font the users position within the content is not lost.  Currently in most browsers a zoom in moves your position pointer back as may a 40 screens, a zoom out can jump you to the bottom.  This is a real kick in the ??? for workflow.  People have great need to resize while reading.  A table or preformatted element may force size reduction.  Simple fatigue can require enlargement.

*{GCL 2011-10-12: I believe we were either talking about (or I was thinking about) the need for an SC that said the point of regard should be scrolled to be within the visible portion of a viewport when the viewport is resized, and as you suggest this should also be true 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 browser window set to edit mode, the user or script changes the font size attribute of some text). This is definitely of mainstream benefit as well as for people with visual impairments, particularly when pop-up sidebars frequently change the width of the viewport.}*


        Understand 1.5


        1.6


Excellent! Very nice.


        1.7


*SC 1.7.1* is good and necessary.

*SC 1.7.2* is very incomplete.  (1) There must be a reasonable mechanism for identifying user style sheets, e.g. the Safari Preferences>Style Sheets, or IE's Tools > Internet Options > Accessibility.  This must be changeable within one session, as with Safari and IE.  (2) Users should be able to (a) turn off all author styles, and (b) invoke a user style sheet simultaneously. This eliminates the necessity of using !important excessively. Often messages generated by active content are blocked because the user must use !important excessively to neutralize the author's style.   (3) Most authors are not qualified to develop alternative style sheets for low vision.  The decision of user styles choice should be determined by the user and low vision specialists.

I know about user style sheets, I write them and use them.

*{GCL 2011-10-12: The text Dick reviewed is obsolete; it was discussed and should have been replaced per the 2011-09-08 conference call. The new text is to be:*

**

*"Summary: The user can choose which if any author-supplied (1.7.1) and user-supplied (1.7.2) style sheets to use.*

**

*1.7.1 Author Style Sheets: The user can turn off the use of author style sheets, and for every author style sheet defined the user can choose whether or not it should be applied to (a) the current page, or (b) all pages for which it is defined.*

**

*1.7.2 User Style Sheets: The user can turn off the use of user style sheets, and for every user style sheet defined the user can choose whether or not it should be applied to (a) the current page, or (b) all pages on specified web sites, or (c) all pages."*

**

*We had decided that we don't need to address where in the cascade these come because the CSS spec already ensures that user styles with !important take ultimate precedence.
*

**

*That being said, re Dick's comments #1 I'm not sure what he's specifically suggesting. Similarly I'm not sure I understand comment #2; the proposed wording allows the user to turn off author style sheets and invoke one or more user style sheets, although not necessarily invoking this option with a single command. Which does Dick mean by "simultaneously"? Also I note that, as Dick surely encounters, turning off author style sheets altogether renders some pages unusable, such as when the author uses styles to hide large amounts of content, unavailable menu items or controls, etc. Similarly re comment #3 I'm not sure what specific changes Dick would suggests, although I'm certainly open to hearing them; I'm sure this guideline could be improved with his input.}*


        1.8


*SC 1.8.1--3* are good to go. I suppose that *1.8.4* is necessary, but incomplete.  If the user enlarges to viewport to the entire usable screen (minus chrome) there should be no horizontal scrolling.  The UA should wrap hyperlinks, break words, fix the widths of tables in short, do what it takes to make a full space viewport wrap to fit. <pre> elements should be wrapped line by line. There is nothing, nothing, nothing worse than horizontal scrolling to read.  No workflow whatsoever is possible.

I don't have other comments on 1.8 at this time, but it is a vital guideline.  Good work isolating it so well.

*{GCL 2011-10-12: I disagree that maximizing the viewport size should always override styles that would cause wrapping, The user should certainly be able to override any author formatting that requires or prevents wrapping, including the HTML pre element, the CSS white-space attribute, etc., but that should definitely be separated from whether the viewport is maximized. But I agree the option to turn wrapping content to viewport on or off, overriding author formatting, should be added to the guidelines somewhere. For example, perhaps something like "1.4.3 Configure content wrapping: Users can override author formatting and user agent defaults that would prevent content from wrapping to its viewport. (Level AA)", or to be more general, "The user can ensure that content wraps to the width of its viewport so that horizontal scrolling is not required."}*


          1.9 and 1.10


I don't get *1.9*.

*{GCL 2011-10-12: 1.9 has been removed from the latest draft; its success criteria were already scattered to different sections or replaced altogether.}*

In *SC 1.10.1* the "view" is unclear.  Is this view in the style specified in 1.4.  You might make this explicit. Just add "in the preferred text adjustment of the user".

*{GCL 2011-10-12: The examples should be reworked in our new style, to be specific users taking actions to meet their needs. Do we need to explicitly require that the text be viewable in the browser and with all its accessibility features? I'd be okay with that.}*

*SC 1.10.2* is great.  It should be Level A.  At 25 to 100 words per screen outline format is more that a luxury.

*{GCL 2011-10-12: I agree that outline view can be more than a luxury, and would support it being Level A if no major objections are raised, but we might have discussed it and had good reason to demote it to Level AA.}*



     Thanks,

     Greg

-------- Original Message  --------
Subject: Fwd: Comments on UUA 2.0 Draft 6/11
From: Jeanne Spellman <jeanne@w3.org>
To: UAWG <w3c-wai-ua@w3.org>
Date: 8/22/2011 4:19 AM
> Some comments have come in on the last working draft.   See following:
>
> -------- Original Message --------
> Date: Fri, 19 Aug 2011 17:01:46 -0700
> From: Wayne Dick <wayneedick@gmail.com>
> Reply-To: wed@csulb.edu
> To: public-uaag2-comments@w3.org
>
> This does not address some criteria you requested.  I examined
> Principle 1 Perception carefully.  There some changes needed to
> support visual readers with low vision.
>
> Here are my comments
> http://www.csulb.edu/~wed/public/UAAG_2-1Comments-8-19-2011.html <http://www.csulb.edu/%7Ewed/public/UAAG_2-1Comments-8-19-2011.html>
>
> Sincerely Wayne Dick PhD
>
>