Minutes: User Agent Telecon 9 July 2015

from: http://www.w3.org/2015/07/09-ua-minutes.html

User Agent Accessibility Guidelines Working Group Teleconference 09 Jul 2015

See also: IRC log  http://www.w3.org/2015/07/09-ua-irc
<http://www.w3.org/2015/07/09-ua-irc>
Attendees
Presentjim, jeanne, gregRegretskimChairJimScribeallanj
Contents

   - Topics <http://www.w3.org/2015/07/09-ua-minutes.html#agenda>
      1. mobile view in desktop browser
      <http://www.w3.org/2015/07/09-ua-minutes.html#item01>
   - Summary of Action Items
   <http://www.w3.org/2015/07/09-ua-minutes.html#ActionSummary>

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

<trackbot> Date: 09 July 2015

use http://www.w3.org/WAI/PF/media-a11y-reqs/ as a structure
mobile view in desktop browser

<Greg> It would be nice if WCAG had a recommendation that content providers
who provide different versions of their content optimized for different
users, environments, input or output devices, etc., would let the user
choose which they prefer rather than forcing them to view the version the
site guesses they want (e.g. by browser identification or screen size).

<Greg> Phil proposes that the *browser* allow the user to lie about what
device, screen size, etc. they're using in order to trick the site into
serving up a different version. This is a hack, but I would support it,
given that few web sites allow the user to choose directly. After all, if
the content provider has gone through all the trouble to create versions
optimized for single column, large...

<Greg> ...font, etc., it only makes sense to let the user take advantage of
that, when they want it, rather than force them to rely on browser settings
that would only try to approximate that view.

many websites have a mobile version m.domain.name

<Greg> Rather than a browser setting to simply identify as a mobile browser
per se, it should be generalized to a series of browser settings that allow
the user to choose which browser, screen size, input devices, etc. the
browser should advertise itself as having. That would not be tied to mobile
versions of sites, but allow choosing between any number of different
optimizations or optimized...

<Greg> ...versions that the site/content may provide.

the

school's site allows mobile view anytime

http://www.tsbvi.edu

we want the mobile view even if the screen width is 1080 px wide

short of turning off style sheets to get a single column view browsers
don't provide a mobile view unless the author already provides a mobile view

<Greg> If Phil would like a way to get the site to provide the mobile view
on large desktop windows, that would require some new flag that sent by the
browser and used by the content. Thus, it would be defined in HTML or the
like and recommended in both UAAG and WCAG.

for a browser to transcode a site to a mobile view seems a lot of work,
without any author provided break points

<Greg> We've in the past discussed the advantage of a flag that the browser
would pass to the site saying the user requests high contrast, and it could
also have flags for user preference for large fonts, simple layout, simple
language, keyboard UI, etc.

js: smaller devicces, wearables...more things will be attached to it.

<Greg> ... preferred language, etc.

discussion of server vs browser

gl: if server/author used color for information. the author could (like for
printed version) code to allow underline instead of color.
... browsers don't have heuristic power to transcode every site.

<Greg> I believe the content can do a much better version of adjusting for
lack of color than the browser can, because the author/designer understands
what color is signifying, and thus what would be an appropriate way to
convey it without color.

js: users should have ability to change the way the browser handles
information and not push all of this on the author.

<Greg> Sites often do this to some extent already, e.g. when rendering for
the printed page they might substitute underscoring for a color, italics
for another color, etc.

<Greg> The problem is they won't let the user access this for anything
other than printing! That's the same as Phil's complaint that the author
has gone to the trouble of creating a version optimized for single column,
but won't let him use it on a desktop.

gl: phil's comment is the author has already done the work. the UA should
allow the mobile view on a large screen

that should be easy

js: responsive sites respond to increase font size. the user should get
what they want. spoofing devices is a hack

<Greg> So there are, at the base level, several approaches available: (a)
the browser can try to adjust each page for the user's preferences; (b) the
browser can lie about itself to trick the site into serving up a version of
the content optimized for a different configuration; (c) define a set of
preference settings set in the browser and sent to the site identifying
ways they'd like the content...

<Greg> ...formatted; (d) the site can provide UI that lets the user choose
preferences such as font size, use of columns, etc.

js: do we want to add a new SC or provide a usecase for low vision TF

ja: use case sounds good

<Greg> For option A the advantage is that it requires no changes to the
server or content, but the disadvantage is that the browser cannot do an
effective job because it doesn't understand the content the way the author
does.

low vision use case : alternative views

mobile or single column views allow users to get a single column view with
no horizontal scrolling

<Greg> For option B the advantage is that it requires no change to the
server or content, but disadvantages are that it only works with a limited
set of sites, it's definitely a hack, it only works for settings generally
associated with mobile devices, and it turns on or off all of those
settings together even though some might not apply (e.g. you want single
column but don't use a touch screen).

They are particularly useful for users with memory or cognitive
disabilities, lowvision users, and users who find it difficult or
impossible to scroll horizontally. A navigable outline views reduce
orientation and navigation time and fatigue.

would include expandable/collapsible navigation structure

<Greg> For option C, advantage is that it would provide a wonderful menu of
preference choices from which the user could choose individually, but the
disadvantages are it would require an extension to HTML or the header and
cooperation of the browser and the site/content.

would still maintain the "style" of the site, as opposed to removing all
styles

<Greg> For D, the advantages are that it provides a good variation on the
site and requires no changes to the browser, but the disadvantage is that
it requires changes to the content and additional real estate on the page
for the preference UI (or perhaps elsewhere if it's a site-wide preference
setting).

<Greg> Jim points out that there could be a standardized convention for how
to adjust a URL to get to a mobile view (e.g. cnn.com to m.cnn.com).

js: this would be a series of use cases.

we have alot of it done in 1.4

js: phil's proposal is about single columns, separate from changing fonts,
colors, etc on multicolumn layout

gl: think its a valuable issue to be dealt with

all agree

<scribe> scribe: allanj

gl: who would be responsible for a new flag passed between browser and
server for changing layout

js: might be http or webapps or aria

gl: there are tons of things going back and forth between the server and
browser
... some are done via http header, there are others not sent in the header

there are somethings - preference settings

some need to precessed by the server, others processed in a script locally
through an API

scribe: I set a high contrast flag in the browser.
... if something is sent to the server, and it detects the flag, then the
php can do things to send a customize version
... there may be something locally, check browser function - check high
contrast flag

js: there is an environment stack (window size, etc) that is available for
javascript to query. perhaps highcontrast is there.
Summary of Action Items [End of minutes]

-- 
[image: http://www.tsbvi.edu] <http://www.tsbvi.edu>Jim Allan,
Accessibility Coordinator
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