16:57:30 RRSAgent has joined #ua 16:57:30 logging to http://www.w3.org/2015/07/09-ua-irc 16:57:32 RRSAgent, make logs public 16:57:32 Zakim has joined #ua 16:57:34 Zakim, this will be WAI_UAWG 16:57:34 I do not see a conference matching that name scheduled within the next hour, trackbot 16:57:35 Meeting: User Agent Accessibility Guidelines Working Group Teleconference 16:57:35 Date: 09 July 2015 17:02:10 Agenda+ Use Cases - Low Vision 17:02:11 use http://www.w3.org/WAI/PF/media-a11y-reqs/ as a structure 17:03:33 Greg has joined #ua 17:05:50 regrets: kim 17:05:56 Chair: Jim 17:12:30 topic: mobile view in desktop browser 17:13:45 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). 17:16:08 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... 17:16:09 ...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. 17:17:29 many websites have a mobile version m.domain.name 17:19:35 rrsagent, make minutes 17:19:35 I have made the request to generate http://www.w3.org/2015/07/09-ua-minutes.html allanj 17:19:50 rrsagent, set logs public 17:19:57 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... 17:19:58 ...versions that the site/content may provide. 17:20:06 the 17:20:23 school's site allows mobile view anytime 17:20:45 http://www.tsbvi.edu 17:32:09 we want the mobile view even if the screen width is 1080 px wide 17:33:24 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 17:34:29 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. 17:34:41 for a browser to transcode a site to a mobile view seems a lot of work, without any author provided break points 17:38:42 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. 17:38:55 js: smaller devicces, wearables...more things will be attached to it. 17:40:12 ... preferred language, etc. 17:41:39 discussion of server vs browser 17:43:12 gl: if server/author used color for information. the author could (like for printed version) code to allow underline instead of color. 17:43:58 ... browsers don't have heuristic power to transcode every site. 17:44:06 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. 17:45:33 js: users should have ability to change the way the browser handles information and not push all of this on the author. 17:45:55 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. 17:47:18 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. 17:47:58 gl: phil's comment is the author has already done the work. the UA should allow the mobile view on a large screen 17:48:05 that should be easy 17:50:32 js: responsive sites respond to increase font size. the user should get what they want. spoofing devices is a hack 17:51:20 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... 17:51:22 ...formatted; (d) the site can provide UI that lets the user choose preferences such as font size, use of columns, etc. 17:51:55 js: do we want to add a new SC or provide a usecase for low vision TF 17:52:27 ja: use case sounds good 17:53:20 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. 17:53:57 low vision use case : alternative views 17:55:14 mobile or single column views allow users to get a single column view with no horizontal scrolling 17:55:25 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). 17:56:01 They are particularly useful for users with memory or cognitive disabilities, blind users, and users who find it difficult or impossible to scroll horizontally. A navigable outline views reduce orientation and navigation time and fatigue. 17:56:41 would include expandable/collapsible navigation structure 17:57:07 s/blind users/lowvision users 17:57:19 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. 17:58:19 would still maintain the "style" of the site, as opposed to removing all styles 17:59:16 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). 18:00:52 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). 18:04:34 js: this would be a series of use cases. 18:05:08 we have alot of it done in 1.4 18:07:31 js: phil's proposal is about single columns, separate from changing fonts, colors, etc on multicolumn layout 18:09:37 gl: think its a valuable issue to be dealt with 18:09:47 all agree 18:09:58 scribe: allanj 18:17:08 gl: who would be responsible for a new flag passed between browser and server for changing layout 18:17:44 js: might be http or webapps or aria 18:19:52 gl: there are tons of things going back and forth between the server and browser 18:22:15 ... some are done via http header, there are others not sent in the header 18:22:57 there are somethings - preference settings 18:23:26 some need to precessed by the server, others processed in a script locally through an API 18:23:42 ... I set a high contrast flag in the browser. 18:24:24 ... if something is sent to the server, and it detects the flag, then the php can do things to send a customize version 18:24:56 ... there may be something locally, check browser function - check high contrast flag 18:25:52 js: there is an environment stack (window size, etc) that is sent to the server. perhaps highcontrast is there. 18:26:37 s/that is sent to the server./that is available for javascript to query. 18:28:46 rrsagent, make minutes 18:28:46 I have made the request to generate http://www.w3.org/2015/07/09-ua-minutes.html allanj 18:30:10 present: jim, jeanne, greg 18:30:13 rrsagent, make minutes 18:30:13 I have made the request to generate http://www.w3.org/2015/07/09-ua-minutes.html allanj 18:30:22 zakim, please part 18:30:22 Zakim has left #ua 18:30:55 rrsagent, please part 18:30:55 I see no action items