W3C

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

04 Jun 2015

See also: IRC log

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
allanj

Contents


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

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/06/04 18:36:16 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/Stylisht/Stylish/
Succeeded: s/Greasemonky/Greasemonkey/
Succeeded: s/to specify/to be able to specify/
WARNING: Bad s/// command: s/up to them/to up them/.
Succeeded: s/up t them/up to them/
Succeeded: s/Stylishl/Stylish/
No ScribeNick specified.  Guessing ScribeNick: allanj
Inferring Scribes: allanj

WARNING: No "Present: ... " found!
Possibly Present: Greg Kim current gl ja jeanne joined js kp original proposal trackbot ua
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 04 Jun 2015
Guessing minutes URL: http://www.w3.org/2015/06/04-ua-minutes.html
People with action items: jeanne

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]