<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.

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/blind users/lowvision users/
Succeeded: s/that is sent to the server./that is available for javascript to query./
Found Scribe: allanj
Inferring ScribeNick: allanj
Present: jim jeanne greg
Regrets: kim
Found Date: 09 Jul 2015
Guessing minutes URL: http://www.w3.org/2015/07/09-ua-minutes.html
People with action items: