Minutes: User Agent telecon 4 June 2015

source: http://www.w3.org/2015/06/04-ua-minutes.html

User Agent Accessibility Guidelines Working Group Teleconference 04 Jun 2015

See also: IRC log   http://www.w3.org/2015/06/04-ua-irc
<http://www.w3.org/2015/06/04-ua-irc>
Attendees
PresentRegretsChairSV_MEETING_CHAIRScribeallanj
Contents

   - Topics <http://www.w3.org/2015/06/04-ua-minutes.html#agenda>
      1. SC 4.1.4 DOM <http://www.w3.org/2015/06/04-ua-minutes.html#item01>
      2. Guideline 1.7 <http://www.w3.org/2015/06/04-ua-minutes.html#item02>
      3. 1.7.2 apply user styles
      <http://www.w3.org/2015/06/04-ua-minutes.html#item03>
      4. 1.7.3 disable author styles
      <http://www.w3.org/2015/06/04-ua-minutes.html#item04>
      5. 1.7.4 save styles
      <http://www.w3.org/2015/06/04-ua-minutes.html#item05>
      6. reorder 1.7 <http://www.w3.org/2015/06/04-ua-minutes.html#item06>
   - Summary of Action Items
   <http://www.w3.org/2015/06/04-ua-minutes.html#ActionSummary>

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

<trackbot> Date: 04 June 2015

open item 1
SC 4.1.4 DOM

- awaiting more information. Two screen readers say they need the DOM, a
technologist and a different screen reader say the DOM access is a lost
cause

close item 1

open item 2
Guideline 1.7

http://lists.w3.org/Archives/Public/w3c-wai-ua/2015AprJun/0047.html

<Greg> How is "styles" different from the term "style properties" we
already have?

<Greg> Style properties is defined as "Properties whose values determine
the presentation (e.g. font, color, size, location, padding, volume,
synthesized speech prosody) of content elements as they are rendered (e.g.
onscreen, via loudspeaker, via braille display) by user agents. Style
properties can have several origins..."

<Greg> "Style Properties" is only used in the glossary.

js: we should just leave it. styles are important

<Greg> Re changing the term "stylesheets" to "styles", we already define
"stylesheets" to broadly that it applies to many technologies, including
but not limited to CSS-type stylesheets. Thus changing to another term
that's inherently broader, such as "styles", seems like a purely editorial
change, rather than substantive.

+1

<Greg> "Style sheet" (two words) is defined as "A mechanism for
communicating style property settings for web content, in which the style
property settings are separable from other content resources."

<Greg> Thus I believe it would apply to user stylesheets and also to
extensions like Stylish.

<Greg> Thus, if we leave the SC to require "user stylesheets", but user
stylesheets are already inclusive of other technologies such as Stylish,
then Microsoft Edge could presumably comply by simply supporting Stylish
rather than traditional CSS/HTML user stylesheets. (For better or worse.)

<Greg> If, on the other hand, we feel that traditional stylesheets are
important enough to require specifically, we would have to change the SCs
or the definitions to accomplish that.

js: don't see that we need to change SC or Defs.

ja: leave them as they are.

js: +1

gl: important for user stylesheets or some other mechanism - stylish, etc.

js: the second

<Greg> Even Greasemonkey would presumably suffice to meet today's SC.

ja: proposal was to communicate a styling mechanism

js: we try to reword to make it broad, and end up confusing people.

<Greg> The current wording is technically accurate, but it will mislead
anyone who doesn't consult the glossary.

<Greg> That is, assuming we want Stylish and Greasemonkey to be enough to
comply.

ja: keep stylesheets or change to style modification mechanism

gl: distinction - stylseheet is separate from content. but in pdf style is
not separate. if you change from stylesheets which is separate to style
modification mechanism...would it still apply to pdf

<Greg> Another concern is that our definition of style sheet limits it to
mechanisms "in which the style property settings are separable from other
content resources". If we go to a more general mechanism, what would keep
it from applying to web content formats where formatting is hard-coded in?

ja: we have many implementations to meet changing style changes if one UA -
PDF doesn't ... I'm ok with that, don't want to change the SC to make them
weaker

gl: ok with this.

http://lists.w3.org/Archives/Public/w3c-wai-ua/2015AprJun/0047.html

1.7.1 Support User Style Modification Mechanism: If the user agent supports
a mechanism for author styles, the user agent also provides a mechanism for
a user to override author styling on specified elements. (Level A)

1.7.1 Support User Stylesheet or User Style Modification Mechanism: If the
user agent supports a mechanism for author styles, the user agent also
provides a mechanism for a user to override author styling on specified
elements. (Level A)

Added “on specified elements” seemed that overriding could be viewed as
simply turning off the styles. Wanted it to be more. Styish provide
mechanism for changing specific elements on specific pages.

<Greg> To be clear, it previously read "1.7.1 Support User Stylesheets: If
the user agent supports a mechanism for author stylesheets, the user agent
also provides a mechanism for user stylesheets. (Level A) ".

<Greg> Another concern re the proposed 1.7.1: The term "specified element"
(or "specified elements") is not used elsewhere in the document. Did you
mean "specified element types"? I feel that specifying for individual
elements is less useful than by element types, as while the former can be
useful on occasion, it’s a lot of work if you have to use it widely or
frequently.

<Greg> I was worried that a browser could comply by providing a debugger in
which the user could override the formatting of a particular element, but
would have to repeat it for every single paragraph. However, if you
consider that too theoretical a problem, that's okay.

<Greg> That means, though, that providing the debugger is sufficient to
comply, correct?

gl: has concerns about strength or abilities of tools to override really
poor content

js: yes it would comply. sigh. this is the argument for keeping stylesheets

<Greg> That could be addressed either by going back to "user stylesheets"
or changing Jim's new wording from "specified elements" to "specified
element types". (Or just ignore it and allow debugger to comply.)

1.7.1 Support User Stylesheet or User Style Modification Mechanism: If the
user agent supports a mechanism for author styles, the user agent also
provides a mechanism for a user to override author styling. (Level A)

<Greg> With that, would a browser comply just by providing a debugger?
Would it comply simply by allowing the user to *disable* author styling,
without allowing them to substitute their own?

<Greg> Don't we want this SC to require the user to be able to specify
their own styles, overriding the author's? We're losing that in the
proposed rewrite.

1.7.1 Support User Stylesheet or User Style Modification Mechanism: If the
user agent supports a mechanism for author styles, the user agent also
provides a mechanism for a user styling to override author styling. (Level
A)

js: +1

<Greg> That takes care of my concern that 1.7.3 would automatically comply
with 1.7.1, but does it still allow presence of a debugger to be sufficient?

ja: yes, not sure we will get around that.

<Greg> However, I can live with that wording if you want to use it.

*RESOLUTION: change 1.7.1 to be Support User Stylesheet or User Style
Modification Mechanism: If the user agent supports a mechanism for author
styles, the user agent also provides a mechanism for a user styling to
override author styling. (Level A)*

<Greg> I would explain this by saying that it is almost entirely an
editorial change, that instead of using a technical term which we'd
redefined more broadly, we'll use a more general term so as to not be
misleading people who do not consult the glossary. This should remove
Microsoft's concern when they thought we were requiring a specific
implementation that they didn't want to support, when in...

<Greg> ...fact we were requiring end user functionality and leaving
implementation mechanism up to them.

<Greg> s/up to them/to up them/.

<Greg> In the process, we may have made it slightly broader if it's
interpreted as allowing things that apply element-by-element rather than
requiriing mechanisms that apply to the whole document.
1.7.2 apply user styles

1.7.2 Apply User Stylesheets: If user stylesheets are supported, then the
user can enable or disable user stylesheets for: (Level A)

All pages on specified websites, or

All pages

<Greg> Firefox lets the user install exactly one CSS file which applies to
all rendered documents, thus complying with the second bullet.

<Greg> Stylish applies styling to all pages on a specific site, thus
complying with the first bullet.

1.7.2 Apply User Styles:

If a mechanism for user styles is supported, then the user can enable or
disable user styles for: (Level A)

All pages on specified websites, or

All pages

<Greg> If we are removing "sheets" from the other SC, we should remove it
here, too. As I said, it's purely editorial given our glossary entry for
stylesheet.

*RESOLUTION: change 1.7.2 to be 1.7.2 Apply User Styles: If a mechanism for
user styles is supported, then the user can enable or disable user styles
for: (Level A) *All pages on specified websites, or *All pages*

<jeanne> *ACTION:* Jeanne to change the links in 1.7 from user and author
stylesheets to user and author styles (under the def of style properties)
[recorded in http://www.w3.org/2015/06/04-ua-minutes.html#action01]

<trackbot> Created ACTION-1086 - Change the links in 1.7 from user and
author stylesheets to user and author styles (under the def of style
properties) [on Jeanne F Spellman - due 2015-06-11].
1.7.3 disable author styles

proposal: 1.7.3 Disable Author Styles: If the user agent supports a
mechanism for author styling of rendered content, the user can disable the
author styles on the current page. (Level A)

original: 1.7.3 Disable Author Stylesheets: If the user agent supports a
mechanism for author stylesheets, the user can disable the use of author
stylesheets on the current page. (Level A)

proposal: 1.7.3 Disable Author Styles: If the user agent supports a
mechanism for author styes, the user can disable the author styles on the
current page. (Level A)

<Greg> This uses a longer phrase than the new wording from 1.7.2.

proposal: 1.7.3 Disable Author Styles: If the user agent supports a
mechanism for author styles, the user can disable the author styles on the
current page. (Level A)

author styles: Style property values that are set by the author as part of
the content (e.g. in-line styles, author style sheets).

<Greg> Fine, I think it's a purely editorial change.

*RESOLUTION: change 1.7.3 to 1.7.3 Disable Author Styles: If the user agent
supports a mechanism for author styles, the user can disable the author
styles on the current page. (Level A)*
1.7.4 save styles

current: 1.7.4 Save Copies of Stylesheets: The user can save copies of the
stylesheets referenced by the current page. This allows the user to edit
and load the copies as user stylesheets.

proposal: 1.7.4 Save Copies of Styling Profile: The user can save copies of
the user styles referenced by the current page. This allows the user to
edit and load the copies on other devices. (Level AA)

<Greg> The new wording has problems. It only saves copies of user styles,
not of the author styles like the original SC did.

proposal: 1.7.4 Save Copies of Styling Profile: The user can save copies of
the styles referenced by the current page. This allows the user to edit and
load the copies on other devices. (Level AA)

<Greg> Better, but still not perfect. The original only required the
browser to save the author-provided stylesheet to the user's local storage.

<Greg> However, it seems that the new wording would require the browser to
extract all the formatting (e.g. style=, etc. etc.) from an HTML document,
and save it separately from the original document, effectively creating a
new stylesheet where there was none before, and perhaps even applying ID
attributes to elements so that formatting could be applied to them via the
new stylesheet.

<Greg> That is because it requires saving all styling in the page, not just
external stylesheets.

ja: agree. leave 7.1.4 alone

js: +1

<Greg> +1

<Kim> +1

<Greg> 1.7.1 through 1.7.3 were about providing a mechanism for overriding
styles, not anything about the styles themselves.
reorder 1.7

proposal: 3,1,2,4

kp: +1

<Greg> I have no strong opinion on the order.

<jeanne> *ACTION:* jeanne to reorder 1.7 to 1.7.3, 1, 2, 4 [recorded in
http://www.w3.org/2015/06/04-ua-minutes.html#action02]

<trackbot> Created ACTION-1087 - Reorder 1.7 to 1.7.3, 1, 2, 4 [on Jeanne F
Spellman - due 2015-06-11].
 Summary of Action Items *[NEW]* *ACTION:* Jeanne to change the links in
1.7 from user and author stylesheets to user and author styles (under the
def of style properties) [recorded in
http://www.w3.org/2015/06/04-ua-minutes.html#action01]
*[NEW]* *ACTION:* jeanne to reorder 1.7 to 1.7.3, 1, 2, 4 [recorded in
http://www.w3.org/2015/06/04-ua-minutes.html#action02]

[End of minutes]
------------------------------

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