RE: UPDATE suggested alternatives to accessible version

I believe this would violate 1.4.4 “Except for captions and images of text,
text can be resized without assistive technology up to 200 percent without
loss of content or functionality. (Level AA)” since I loss functionality of
the page.



As the developer has expressly stated scrolling=”no” in the code I’d say
this issue is a site fault and not a problem with browsers.



[Andrew wrote]

Ø  Regarding a failure of 1.4.8, this shouldn’t trigger a failure because
there is a mechanism available to allow access to the page content, in this
case for Firefox it is to turn off support for CSS



Requiring me to turn off CSS for the entire page and miss all of the visual
styling that I need and want just so scrollbars will appears does not seem
acceptable for me to meet a WCAG Level AA requirement.    If you start
making that argument then we might as well throw out 1.4.3 Contrast
(Minimum) because users can turn off style sheets so why use colors that
provide sufficient contrast.  Once you start saying the user can just turn
off style sheets or that a browser should provide a certain functionality
you are inviting all sorts of inaccessible behavior that would remove a
number of success criteria that were established to work in a multi-faceted
environments.



Jonathan



*From:* Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
*Sent:* Monday, February 20, 2012 11:05 AM
*To:* jon.avila@ssbbartgroup.com; Carla De Winter; w3c-wai-ig@w3.org
*Subject:* RE: UPDATE suggested alternatives to accessible version



I do agree that this doesn’t seem like a good practice, but I wonder
whether this is an issue with the browser more than the web page.  Of
course, if browsers don’t do certain things we avoid depending on them, but
that doesn’t get browsers off the hook entirely.  I wondered if the
experience for a keyboard user would be better than for a mouse user, and
at least in Firefox when I tab (I haven’t tried anything else) the window
does scroll to off-screen focusable objects, but not quite enough.  For the
links on the far right they aren’t brought fully into view, which makes
this at least in part a browser issue.



Regarding a failure of 1.4.8, this shouldn’t trigger a failure because
there is a mechanism available to allow access to the page content, in this
case for Firefox it is to turn off support for CSS.  I don’t think that it
is desirable to rely on users turning off style sheets, but I don’t think
that this is non-compliant with WCAG 2.0 1.4.8.



AWK



*From:* Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
*Sent:* Monday, February 20, 2012 10:41 AM
*To:* Carla De Winter; w3c-wai-ig@w3.org
*Subject:* RE: UPDATE suggested alternatives to accessible version



Carla,



Correct and that is where we indicate a failure for this also, although for
me it happens with 800x600 without zooming.  So from what you are saying
1.4.8 assumes a standard screen resolution and anything less is then
considered zooming?   I suppose a standard screen resolution would also
need to be defined for different devices based on the technology stack.
  I’m trying to think of cases where zooming would act different from a
lower resolution to determine if an additional requirement would be needed
but I can’t think of one.  If anyone knows of any I’d be interesting of
hearing about it.



Jonathan



*From:* Carla De Winter [mailto:carla@accesscapable.com]
*Sent:* Monday, February 20, 2012 10:35 AM
*To:* 'Jonathan Avila'; w3c-wai-ig@w3.org
*Cc:* 'Jonathan Hassell'
*Subject:* RE: UPDATE suggested alternatives to accessible version



This touches 1.4.8 Visual presentation, but it not explicitly described:



“Text can be resized without assistive technology up to 200 percent in a
way that does not require the user to scroll horizontally to read a line of
text on a full-screen window.”



There is no equivalent in Section 508 and WCAG 1.0



We redefined that as “customizable user interface”, and included the fact
that the website should remain accessible when font size is increased or
screen resolution is lowered. If content is not accessible because of a
lacking scrollbar, this fails.



Carla De Winter

AccessCapable





*Van:* Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
*Verzonden:* maandag 20 februari 2012 16:05
*Aan:* w3c-wai-ig@w3.org
*CC:* Jonathan Hassell
*Onderwerp:* RE: UPDATE suggested alternatives to accessible version



Jonathan, one issue with your site that I have noticed is that you have
scroll bars turned off by setting scrolling=”no” on the main div.  This
means that when the page is viewed by people using zoom features in the
browser or lower screen resolutions no horizontal scroll bars appear and
they cannot access the horizontal content off the right edge of the screen.



This is an issue that I believe is not clearly spelled out in WCAG that
needs to be indicated as a failure.



Best Regards,



Jonathan



*From:* Jonathan Hassell [mailto:jonathanhassell@yahoo.co.uk]
*Sent:* Sunday, February 19, 2012 7:05 PM
*To:* w3c-wai-ig@w3.org
*Subject:* Fw: UPDATE suggested alternatives to accessible version



Thanks for your comments, David.



Hassell Inclusion is my site, and I take inclusion very seriously.



Accordingly, you'll find that both of the colour combinations you mention
meet WCAG-AA rather than having 'almost zero colour contrast'.



However, you're right that the shade of blue I used only met AA for the
large text on which it was used on the home page. The contrast could have
been better for smaller text used elsewhere. I've darkened the shade
accordingly so it passes all WCAG-AA tests at whatever size I use it.



Thanks for pointing this out.



In turn, could I point out that high colour contrast colour-schemes, whilst
helping many people with vision impairments, actually hinder a great number
of dyslexic people from reading the page.



That's why 'universal design' doesn't work - it's not universally good for
everyone, as people with different disabilities have completely
contradictory colour preferences.



So it's impossible to please everyone, unless you provide a means of
changing the colours on the site.



This is something I'm already looking into, as I already mention on my
site's accessibility statement:
http://www.hassellinclusion.com/accessibility/



As for 'large areas white on the first two screenfuls' - no-one else has
experienced this problem. Could you let me know which browser you're using?
(I've tested the pages in Chrome, Safari, Firefox and IE 8...)



If you have any other comments on how you think my site could be improved,
please email me on jonathan@hassellinclusion.com.



Jonathan.




------------------------------

*From:* David Woolley <forums@david-woolley.me.uk>
*To:* w3c-wai-ig@w3.org
*Sent:* Saturday, 18 February 2012, 22:32
*Subject:* Re: UPDATE suggested alternatives to accessible version


Carla wrote:

> http://www.hassellinclusion.com/2011/12/accessibility-myths-2011/

Were these examples of how not to write universal pages?

Dark green on grey in the tabs: almost zero colour contrast.

Light green on white in the body text, also a poor colour contrast, but not
nearly as bad.

Large areas of white space on the first two screenfuls; I presume it only
works in one browser.

Centre justification in the print version - at least they do have a print
version and it doesn't go off the edge of the paper.
-- David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.