- From: Phill Jenkins <pjenkins@us.ibm.com>
- Date: Mon, 18 Jan 2016 20:03:25 -0600
- To: WAI Interest Group <w3c-wai-ig@w3.org>
- Message-ID: <OFB0529BF1.0FE51A09-ON86257F3F.00073505-86257F3F.000B4D53@us.ibm.com>
Hi Wayne,
good discussion, and I agree with the direction.
I agree Authors own the structure, but re-designing a web site for
Responsive smart phone browsers is not trivial and is taking many
companies many months (years?) and hundreds of developers to do it. IBM
Mobile First even advocates and provides tooling for responsive design.
But again it is not trivial and has taken years to get to this point.
I would like to see the authoring tool vendors, toolkit developers, and
browser to assess the effort to support the extension to large screens
with very large fonts first before or while we start advocating any
specific techniques. I am always cautious when I expect authors to
preform very specialized work that previously was Assistive Technology
product design work - because authors often have no idea what they are
looking at or what is needed and we end up with all kinds of crazy
solutions. It would only be trivial to extend those techniques IF
authoring tools, widget toolkits, automated testing tools and browser
supported them. For example, Responsive design is only happening BECAUSE
authors have smartphone browsers, and now simulators to "test and see" how
the page responds, there are toolkits with pre-packaged responsive
designed widgets that authors can use, etc. Even with all that it is
still not trivial.
I could envision a day when authors could be required to do it, whatever
"it" is. But today they would throw up their hands and give up until we
could better articulate what is really needed and how they could verify
that they are doing it correctly - e..g. testable criteria! Is there an
initial example responsive web app that is developed correctly with these
extended techniques?
When you say: "Authors do not have to code accommodations, but they do
have to provide an environment that supports them."
I would say it a little differently, more like: "Authors do not have to
code accommodations, but they do need to provide a web app that responds
correctly to an environment that supports those assistive technology
features."
For example, end users would also need the desktop browser to support an
end-user narrow smartphone mode too, even on wide screen desktop browsers
with super large (greater than 2X) platform supported font size. We the
accessibility community need to define that environment so that browser
developers can create the support needed for the "narrow view" and the
associated extensions needed to create the super large font wide view
environment that the authors need to respond to. hmm, I think I used the
word need to many times . . .
I agree this affects a lot of low vision users. And from my
understanding, more than screen reader users. Not to say that one group
is bigger or more important than another, or that one need is more
important than another. But to be inclusive of all needs of all groups
is our goal.
p.s.
what is LP? as used in: "and the ability to operate without toolbars that
take up too much space in LP."
is LP short for "Long Play" - as in big desktop displays?
___________________________________________
Regards,
Phill Jenkins,
Senior Engineer
IBM Accessibility
From: Wayne Dick <waynedick@knowbility.org>
To: Phill Jenkins/Austin/IBM@IBMUS
Cc: WAI Interest Group <w3c-wai-ig@w3.org>
Date: 01/18/2016 05:58 PM
Subject: Re: Allowing font size changes
I have stayed out of this to see our best thinkers address this problem.
Here is where I come down. Intelligent enlargement is the responsibility
of authors, user agents and operating systems. The full capability and
granularity of CSS 3 is really the level of access needed. It is there to
serve other design needs, why not do it to help people with disabilities.
Authors are responsible for arranging pages so that they can linearize to
fit one column so that the full width of the viewport can be used for
enlargement. Responsive design already does this for small screens. It is
trivial to extend this authoring technique to large screens with very
large print. Many pages already do this; most will in the future; and it
follows that if this can be done to accommodate small screened mobile
devices a few more media query cases can be added to include very large
font. The answer is quite simply, yes, authors now have the techniques
needed to create accessible page formatting. They should be required to
use it. The real guideline here is to get out of the way of assistive
technologies like assistive style sheets. Authors do not have to code
accommodations, but they do have to provide an an environment that
supports them.
The UA must be supportive enabling gross parameters like base font
settings, color settings and maybe even some typographic enhancements like
letter line and word spacing. But as long as the author does the job, most
of this can be provided by AT. The main support the UA can provide is with
large print UA controls, expand/collaps large print menues and the ability
to operate without toolbars that take up too much space in LP.
The UA should always use operating system preferences when present. But
these often do not provide sufficient granularity. For example: What font
does a UA use for a options setting dialogue? Many browsers use the OS
fonts sizes and then dialogues are impossible to use.
The point is this: The OS can forsee the least granularity. The UA can see
more. Only the author knows the structure of content. Thus, responsibility
falls most heavily on the author, then on the UA and finally on the OS.
Wayne
On Mon, Jan 18, 2016 at 2:34 PM, Phill Jenkins <pjenkins@us.ibm.com>
wrote:
> The OS and browser are each broken if they don't provide a way to
increase
> font size, and zoom - yes they are different. And both have important
uses.
I agree it is a user agent responsibility *and* an end user responsibility
to
know how to set the setting or have an assistant set it for them. It is a
lot
easier and more efficient to set it once per browser and/or per OS
platform
that to try to find the yet another unique way an individual website /
developer did it.
Using the excuse that some browser or platforms are hard to set & use does
not justify
leaving it up to millions of web developers to try to figure it out.
> I'm not sure there is any absolute requirement that authors add a
> redundant shortcut to do the same,
I agree, only to make sure their app doesn't break when zooming at 2X
see WCAG 1.4.4 Resize Text
http://www.w3.org/TR/WCAG20/#visual-audio-contrast-scale
> but in practice it can be a useful thing for many users, especially
given that
> in practice many OS and browser solutions are hard to find or use.
I believe it is more useful and less confusing when the audience of the
web app is known or controlled
and has had some training or orientation, such as employees of a company
with a particular app,
or when the app is being designed specifically for a group of users who
have the same or know disability, such as
a rehabilitation app.
The advocacy effort here needs to be directed at OS platform and browser
developers and AT developers, not web developers.
We are starting to get good traction with the iOS and Andorid app
developers not that so many accessibility features
are now included in the platform.
Why can't we (meaning the web accessibility community) focus on the
handful of platform and browser developers
and stop wasting our time and the millions of web developers time on this
topic?
____________________________________________
Regards,
Phill Jenkins,
From: "Chaals McCathie Nevile" <chaals@yandex-team.ru>
To: w3c-wai-ig@w3.org
Date: 01/18/2016 02:00 PM
Subject: Re: Allowing font size changes
On Fri, 15 Jan 2016 15:46:19 +0100, Patrick H. Lauke
<redux@splintered.co.uk> wrote:
> But as ever, it comes down to whose responsibility it is? Should it be
> the content authors, or the device/OS/browser manufacturers?
The OS and browser are each broken if they don't provide a way to increase
font size, and zoom - yes they are different. And both have important
uses.
I'm not sure there is any absolute requirement that authors add a
redundant shortcut to do the same, but in practice it can be a useful
thing for many users, especially given that in practice many OS and
browser soutions are hard to find or use.
IMHO.
chaals
> P
>
> On 15/01/2016 14:40, ALAN SMITH wrote:
>> Heather,
>>
>> I agree.
>>
>> Imaging having to set the volume on our devices in a settings somewhere
>> and constantly return to that setting after we find out it is not
enough
>> or too much and not having the immediate feedback afforded by volume
>> buttons or onscreen controls.
>>
>> Same should be provided for fonts.
>>
>> After all, the text on the web page or app is the main mode of
>> communication or human computer interaction.
>>
>> It is why we use these devices anyway: to be able to read the text
being
>> used.
>>
>> The world population that needs this is so big.
>>
>> Regards,
>>
>> Alan
>>
>> Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>> *From: *Durham, Heather <mailto:heather.durham@pearson.com>
>> *Sent: *Friday, January 15, 2016 9:25 AM
>> *To: *howard_leicester@btconnect.com
>> <mailto:howard_leicester@btconnect.com>
>> *Cc: *Patrick H. Lauke <mailto:redux@splintered.co.uk>;
>> w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>
>> *Subject: *Re: Allowing font size changes
>>
>> What will be the plan for the app? Will it be widely used on mobile
>> devices? In mobile devices you can increase the font size, but it's not
>> as convenient as in a web page. On mobile devices you need to go to the
>> settings app and you can't see how the font size looks live as you
>> adjust it. For people who have difficulty navigating, it could be a
real
>> convenience to tap a button to increase the font size right there in
the
>> app their using.
>>
>> This could also be a nice feature for other uses, such as those with
>> autism. I attended an autism conference in the summer and this was
>> something that was widely discussed. The convenience of reducing the
>> number of steps to accomplish something.
>>
>> Thanks,
>>
>> Heather
>>
>> On Thu, Jan 14, 2016 at 3:22 PM, Howard Leicester
>> <howard_leicester@btconnect.com <mailto:howard_leicester@btconnect.com
>>
>> wrote:
>>
>> Hi P et al,
>>
>> Do things really have to be so detailed and difficult?
>>
>> May be there's some more fundamentally wrong in our approach?
>>
>> No criticism, just a view!
>>
>> VV best,
>> Howard (Leicester, UK).
>>
>>
>>
>> -----Original Message-----
>> From: Patrick H. Lauke [mailto:redux@splintered.co.uk
>> <mailto:redux@splintered.co.uk>]
>> Sent: 14 January 2016 01:23
>> To: w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>
>> Subject: Re: Allowing font size changes
>>
>> On 14/01/2016 00:52, Oscar Cao wrote:
>> > I want to get what everyone's views are on the importance of
>> having
>> > custom font size buttons for a website. You know those 3 icon
>> buttons:
>> > smaller, medium, and larger.
>>
>> Very low from my point of view. It's functionality built into the
>> browser already, so provided a site's CSS is made correctly, these
>> in-page controls would be redundant.
>>
>> There is an argument that users simply don't know that they can
>> resize
>> text/content using the browser controls - but this is more of a
user
>> education issue that should not have to be the responsibility of
>> content
>> authors. (same for in-page/custom controls to switch to high
>> contrast
>> mode or similar)
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk <http://www.splintered.co.uk> |
>> https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>>
>>
>> --
>>
>> Heather Durham
>>
>> Accessibility SQA, HEd
>>
>> Pearson North America
>>
>> 2154 East Commons Ave.
>>
>> Suite 4000
>>
>> Centennial, CO
>>
>> 80122
>>
>> USA
>>
>> *Pearson *
>>
>> Always Learning
>> Learn more at www.pearson.com <http://www.pearson.com/>
>>
>
>
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Tuesday, 19 January 2016 02:04:05 UTC