See also: IRC log
<trackbot> Date: 28 October 2014
<jeanne> scribe: Jeanne
JR: Yesterday we identified that the original wording of 2.2.2 was...
<Jan> http://w3c.github.io/UAAG/UAAG20/#sc_222
<Jan> ORIGINAL 2.2.2 Sequential Navigation Between Viewports: The user can move the keyboard focus backwards and forwards between viewports, without having to sequentially navigate all the elements in a viewport. (Level A)
JR: There were so many ways that
it could be implemented that it became too many variables to
test reasonably.
... yesterday we proposed
<Jan> 2.2.2 Sequential Navigation By Landmarks: The user can move the keyboard focus backwards and forwards between recognized enabled elements to regions identified by document landmarks. (Level AA)
GL: We also cut out recognized enabled elements in the final version.
<Jan> 2.2.2 Sequential Navigation By Landmarks: The user can move the keyboard focus backwards and forwards between regions identified by document landmarks. (Level AA)
JR: We found a plugin for Firefox that does this for ARIA landmarks
KF: I am ok with it. How much is
this evolving to a content issue vs. a browser issue.
... when I think about google apps, or office online apps, they
have to build it into their content.
... but it is probably ok.
GL: If a page uses iFrames or Regions, will they automatically be landmarked.
JR: We gave up on that. The author would need to mark Landmarks.
GL: We are putting in an
accessibility feature that works with a well-designed page, but
not offering a feature to the user that helps them with a
poorly designed page.
... I won't block it.
JS: So we are really just skimming the list for what is testable and implementable?
KF: So this is morphing into
solving a different problem.
... we are shifting to solving a keyboard user problems, and
giving them the same features that screenreader users have. I'm
ok with that.
<k> Greg: I can add two things – one is we can put a note into the referenced document stating it's recommended that the user agent provide quick navigation to other regions such as HTML frames and iframes
<scribe> scribenick: k
Jan: this is for the normative document.
<Jan> Note: The user agent might include quick navigation to other regions such as viewports in the content.
<Jan> 2.2.2 Sequential Navigation By Landmarks: The user can move the keyboard focus backwards and forwards between regions identified by document landmarks. (Level AA) - Note: The user agent might include quick navigation to other regions such as viewports in the content.
<Jan> 2.2.2 Sequential Navigation By Landmarks: The user can move the keyboard focus backwards and forwards between regions identified by document landmarks. (Level AA) - Note: The user agent might also include sequential navigation to other regions, such as viewports in the content.
<kford> I am fine with this.
<Greg> ...include other document regions such as viewports in the sequential navigation order.
Greg: editorial
... or just of the sequential navigation
<Jan> 2.2.2 Sequential Navigation By Landmarks: The user can move the keyboard focus backwards and forwards between regions identified by document landmarks. (Level AA) - Note: The user agent might also include other regions, such as viewports, in the sequential navigation.
Greg: might often include is a phrase we used to say another feature as opposed to part of this feature
<jeanne> ACTION: Jan to update the IER for 2.2.2 for the changes to the SC to Landmarks. [recorded in http://www.w3.org/2014/10/28-ua-minutes.html#action01]
<trackbot> Created ACTION-1043 - Update the ier for 2.2.2 for the changes to the sc to landmarks. [on Jan Richards - due 2014-11-04].
Greg: second issue – I'm concerned that in the process of dealing with that when we have concluded that the term viewports is problematic in that we can't test things that are about viewports – that's what it seems like we have decided and if that's the case where 17 SC's that use viewports – are they all not testable?
Jan: many of them are top-level reports, that's okay
Greg: there are 12 that are not top-level viewports
Jan: 1.1.6 could be top-level viewport
<jeanne> https://www.w3.org/WAI/UA/work/wiki/1.1.6
Jeanne: it's just up to the size of viewport – do we need that to be top-level viewport?
Jan: should we also change that
to 80% of the size – imagine if it's just a little tiny video
and the rest caption
... get rid of the video completely and have the content got to
the full-size of the top-level viewport – I think that's wrong
I think someone is going to push back and say this is a video
viewer the videos got to be somewhere. I wonder if we should
set up to half or up to 75%
Jeanne: especially if we are talking about about sign language video which is two videos
Jan: at least 50% – could take up to half of the top-level report – anybody disagree
Jan updating test, Jeanne updating SC
<Jan> Resize: The user can resize alternative content for time-based media up to at least 50% of the size of the top-level viewport.
RESOLUTION: Change 1.1.6 note to Resize: The user can resize alternative content for time-based media up to at least 50% of the size of the top-level viewport.
Greg: how this is going to work in practice – child viewport of the 50% so captions could be clipped
Jeanne: when we say it takes a top-level viewport we're going to full-screen mode
Jan: webpage is in its own area – within that area you can expand captions and take away from the video but not affect the whole rest of the page
Jeanne: different on mobile. Here we are talking about taking it out of the div and expanding it to full-screen – I don't think we have a mechanism to do that
Jan: 50% of the size of the original content
Greg: what is original – phrase is ambiguous especially if you been mucking around in resizing things. Does the original size have to be remembered?
<Jan> Working on this....Resize: The user can resize alternative content for time-based media up to at least 50% of the size of the top-level viewport.
Jan: we want to say that they should be freed from that little area and take over more space that was previously used by the video – how should we should be say that
Jeanne: you can't drag a video into full-size unless you go to full screen
Jan: if they wanted to pop up
another window that would be allowed
... whatever renderer is responsible for putting the captions
wherever they are put – embedded YouTube player, not Internet
Explorer, and the space that is given needs to devote up to 50%
of it some way to display the captions
... Kelly, when you go into YouTube and make it full screen,
how is that negotiated with Internet Explorer
Jeanne: full-screen API
Kelly: don't know
Jan: we are just saying within that space 50% or some percent – or 100% of the user agent has to be devoted to display, and I just want to say that dialing that back
<Jan> Working on this....Resize: The user can resize alternative content for time-based media up to at least 50% of the size of the user agent viewport.
Jeanne: back to the viewport, not top-level viewport?
Jan: I'd like something to do with the size of the video in its default configuration
<Jan> Working on this....Resize: The user can resize alternative content for time-based media up to at least 50% of the default rendering size of the time-based media.
Greg: as a person who doesn't deal with that I would have no idea what you mean by the default size – I would say that is ambiguous
Jan: is there a way to make it
better
... recapping: at some point the developer says this is a video
player and I have the video the size of the postage stamp, but
that's not enough you want the video to disappear, captions
100% – I have to do that to pass? Tried to dial the number
down, now we've got 50% of what?
Jim: the author decides sides of the video – coded into the tag. Depends on the player.
Jeanne: remember we also have the sign language video, that might have to be bigger than the video
<Jan> Resize: The user can resize alternative content for time-based media up to at least 50% of the space available for rendering the time-based media.
Jeanne: maybe you should table this until we review with the accessibility task force – wrote about media requirements
<jeanne> http://www.w3.org/TR/media-accessibility-reqs/
Jim: that works
<jeanne> CC-5 in notes
Greg: recommended larger such as a pop out or full-screen feature in order to provide more room for captions
<jeanne> http://www.w3.org/TR/media-accessibility-reqs/#captioning
Jan: we have that already, just picky with size requirements
looking at media accessibility captioning text
Jan: cc 15, detailed
Jeanne: I told John that as a group we would take a look at this media accessibility requirements – everybody should review
<AllanJ> ACTION: jallan to review media a11y requirements for 1.1.6 resize, reposition of media [recorded in http://www.w3.org/2014/10/28-ua-minutes.html#action02]
<trackbot> Created ACTION-1044 - Review media a11y requirements for 1.1.6 resize, reposition of media [on Jim Allan - due 2014-11-04].
Jeanne: should switch to looking at Cynthia's comments
<jeanne> ACTION: jeanne to put use of Viewport term review in next week's meeting [recorded in http://www.w3.org/2014/10/28-ua-minutes.html#action03]
<trackbot> Created ACTION-1045 - Put use of viewport term review in next week's meeting [on Jeanne F Spellman - due 2014-11-04].
<Jan> http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Oct/0002.html
<jeanne> http://jspellman.github.io/UAAG-LC-Comment/
Jeanne: MS06 is repeated in many places, that's where she talked about the levels, we should do those first
Jim: this is about the user finding out about the situation – reliance on AT is overrated, because there are many people who don't have AT who won't know this is exist because they can't get at it
Jeanne: most people with disabilities don't have AT
Jim: the majority
Jeanne: 1.1.1 is done
1.1.2
Jan: supports 1.1.1 which requires text alternatives, and also 1.1.2
Jim: media has CC icon because it reveals that you have captions they can turn them on – that's not an AT thing
Greg: for example a person who has difficulty processing abbreviations can see which acronyms have definitions
Jeanne: someone who is deaf, but also have low vision
Greg: and the three examples which are in the reference document already
1.1.3
Jan: good question, if something
is flashing, but we have below placeholders for video
... looking at intent
Jim: this is turning off the images and having the alt text show up in its place
Greg: contrast is a good example
for that – people for whom the image can be painful
... we should add that into the list of examples of the
reference document as well
<jeanne> ACTION: jeanne to add the example to 1.1.3 People who find high contrast painful and want a low contrast font. [recorded in http://www.w3.org/2014/10/28-ua-minutes.html#action04]
<trackbot> Created ACTION-1046 - Add the example to 1.1.3 people who find high contrast painful and want a low contrast font. [on Jeanne F Spellman - due 2014-11-04].
Jim: think of cognitive people who may have issues with icons or don't understand the icons but could understand the text and have all these icons for navigation and you make those go away and the alt text pops up and you can navigate, worse people would language difficulties who don't understand our meams
1.1.5
Jan: are we okay with keeping these all one AA groups or splitting up to keep the same level as WCAG
Jeanne: the third bullet point is what pushes it into AA
agreement to split them
<jeanne> ACTION: Kim to split 1.1.5 so that the first two bullets are A and the third bullet is AA. IER and handles must be split as well. [recorded in http://www.w3.org/2014/10/28-ua-minutes.html#action05]
<trackbot> Created ACTION-1047 - Split 1.1.5 so that the first two bullets are a and the third bullet is aa. ier and handles must be split as well. [on Kimberly Patch - due 2014-11-04].
RESOLUTION: accept splitting 1.1.5 into A and AA
<AllanJ> resolution related to MS06 comment
accepted
Greg: why did we choose AAA on this?
Jeanne: difficult to do
agreed
agreed
Jan: rewrote last night
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0034.html
Jan: 1.3.1 note addresses Microsoft comment
<kford> we just lost you on the call.
<kford> are we not supposed to tell zakim to call you or should we call the hotel?
<kford> What's the hotel number if the second?
Jim: 1.3.3 is out there
Greg: programs like word implement their own text cursor and text cursor blink rate
Jeanne: note, should not be using the word should
<Jan> 1.3.1 Distinguishable Highlighting: The default presentation of the following types of content highlighting can be distinguished from one another: (Level A)
<Jan> - Selection highlighting
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - Recognized enabled input elements (and also distinguished from disabled elements)
<Jan> - Recently visited links
<Jan> - Found search results
<Jan> Note: Platform settings for these characteristics are respected, if present.
Jeanne: avoid should, must or may in general
<Jan> 1.3.1 Distinguishable Highlighting: The default presentation of the following types of content highlighting can be distinguished from one another: (Level A)
<Jan> - Selection highlighting
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - Recognized enabled input elements (and also distinguished from disabled elements)
<Jan> - Recently visited links
<Jan> - Search results
<jeanne> ACTION: jeanne to review UAAG 2.0 to remove RFC 2119 words [recorded in http://www.w3.org/2014/10/28-ua-minutes.html#action06]
<trackbot> Created ACTION-1048 - Review uaag 2.0 to remove rfc 2119 words [on Jeanne F Spellman - due 2014-11-04].
<Jan> Note: Platform settings for these characteristics are respected, if present.
Jan: is this enough:
<Jan> 1.3.1 Distinguishable Highlighting: The default presentation of the following types of content highlighting can be distinguished from one another: (Level A)
<Jan> - Selection highlighting
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - Recognized enabled input elements (and also distinguished from disabled elements)
<Jan> - Recently visited links
<Jan> - Search results
<Jan> Note: Any platform settings for these characteristics are respected.
Jeanne: I think that Microsoft
requested went beyond that – the browser should import and
respect the platform settings
... May need special attention, this is been a problem on
mobile platforms for a while particular in iOS. Until recently
was a way to expose settings.
Jan: we should say where it's pertinent
Jim: platform notes number 9
Jeanne: what were saying somebody has set the setting of the platform and you are ignoring it
Jan: we could make it more clear
Jim: any OS level settings trickle through
<jeanne> Reply: 5.1.3 covers the requirement to pick up OS settings. We agree to reword 5.1.3 to make it more clear.
<Jan> 1.3.1 Distinguishable Highlighting: The default presentation of the following types of content highlighting can be distinguished from one another: (Level A)
<Jan> - Selection highlighting
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - Recognized enabled input elements (and also distinguished from disabled elements)
<Jan> - Recently visited links
<Jan> - Search results
<Jan> Note: Any platform settings for these characteristics are respected.
Jan: 1.3.1 – are we good to go?
Greg: not replying to all Microsoft suggestions
<Jan> ACTION: Jan to make sure that repecting OS settings is more clear in 5.1.3 [recorded in http://www.w3.org/2014/10/28-ua-minutes.html#action07]
<trackbot> Created ACTION-1049 - Make sure that repecting os settings is more clear in 5.1.3 [on Jan Richards - due 2014-11-04].
Greg: saying that anything that
is not an OS setting should be AA or AAA
... request was to demote from A anything that was not at OS
level
Jan: keyboard focus is not
handled in OS, handled inbrowser
... recognized input, found search results in browser
... needs to be clear that is asking for the links to be
highlighted and that they be different for each other
Jan adjusting 1.3.1
<Jan> 1.3.1 Distinguishable Highlighting: The following types of content are highlighted and the highlighting can be distinguished from one another: (Level A)
<Jan> - Selection highlighting
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - Recognized enabled input elements (and also distinguished from disabled elements)
<Jan> - Recently visited links
<Jan> - Search results
<Jan> Note: Any platform settings for these characteristics are respected.
Greg: saying enabled elements are
highlighted. Most browsers don't highlight – they do
distinguish, but the way they are first rendered not sure that
really counts is highlighting them
... my concern is the way you say are highlighted as opposed to
the user can have them highlighted – that we're requesting find
away for the user to have all the enabled elements highlighted,
that's great, but to say they must as the wording implies seems
to be wrong
Jan: the problem with that is at
this level it's one more setting – or five more settings at
level AA
... if you're saying can have – do you think all enabled
elements should be capable of being highlighted that level A –
I'm saying no. You should be able to tell apart from disabled
elements,
Jeanne: may be are distinguished rather than type of highlighting
Greg: nice thing
Jan: it is in it AA we talk all about it, maybe it should be dropped here
Jim: every browser has a setting for making links blue and underlined
Jan: that's only one type of enabled elements
<Jan> 1.3.1 Distinguishable Highlighting: The following types of content are highlighted and the highlighting can be distinguished from one another: (Level A)
<Jan> - Selection highlighting
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - Recently visited links
<Jan> - Search results
<Jan> Note: Any platform settings for these characteristics are respected.
Jan: if I got rid of that recognized enabled type, in 1.3.1 we still have it in 1.3.5 at AA
<Jan> 1.3.1 Distinguishable Highlighting: The following types of content are highlighted and the default highlighting can be distinguished from one another: (Level A)
<Jan> - Selection highlighting
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - Recently visited links
<Jan> - Search results
<Jan> Note: Any platform settings for these characteristics are respected.
Greg: this is a change, the user used to be able to override the authors selection color
Jan: that is on purpose – all of these can be changed at AA
Greg: should explicitly state that – overriding author settings
Jan: good with what I just put in?
<Jan> 1.3.1 Distinguishable Highlighting: The following types of content are highlighted and the default highlighting can be distinguished from one another: (Level A)
<Jan> - Selection
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - Recently visited links
doing some editorial changes
<Jan> - Search results
<Jan> Note: Any platform settings for these characteristics are respected.
Greg: screenshot – couldn't tell recently visited from others
<jeanne> +1
Jan: showing solution to that
Greg: are links considered enabled input elements
Jan: should we remove recently visited links?
Greg: I was just thinking of
adding the other links
... we want links visible and to be distinguished and visited
links to be visible in the two to be distinguished from each
other
Jan: adjusting 1.3.1
<Jan> 1.3.1 Distinguishable Highlighting: The following types of content are highlighted and the default highlighting can be distinguished from one another: (Level A)
<Jan> - Selection
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - Search results
<Jan> - Unvisited links
<Jan> - Visited links
<Jan> Note: Any platform settings for these characteristics are respected.
<Greg> ", overriding any values specified by the author."
<Greg> I'm afraid that given this current wording (the first clause) a UA would fail if it did not override author settings that hid highlighting of links.
<Greg> That is to say, the wording says "The following types of content are highlighted", and the page says don't highlight it, the UA complies with that, so it's violating this.
<Greg> I keep coming back to what we really mean is that the user can have them highlighted. In the case of this last scenario, they can by using other UA features to override author formatting, but if they don't, the UA doesn't fail.
<kford> I have to step away until 2P unfortunately.
<Greg> The same applies to selection: some pages use CSS to hide selection.
Jan: drop visited and unvisited links?
Greg: not just links, some pages
do the same thing for selections – they hide selection so you
can't tell, they set the foreground and background colors the
same as the rest of the page
... I've been on pages where I can't tell what text was
selected or it's very subtle
... lots of pages like that – new site – very subtle change in
text color and no change background color
<Jan> http://www.w3schools.com/cssref/tryit.asp?filename=trycss3_selection
Jeanne: CSS rules to suppress highlighting
Jan: adjusting 1.3.1
<Jan> 1.3.1 Distinguishable Highlighting: The user can have the following types of content uniquely highlighted, overriding any values specified by the author: (Level A)
<Jan> - Selection
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - Search results
<Jan> Note: Any platform settings for these characteristics are respected.
Greg: styling something is just another way of highlighting, so don't have to take out links
<Jan> 1.3.1 Distinguishable Highlighting: The user can have the following types of content uniquely highlighted, overriding any values specified by the author: (Level A)
<Jan> - Selection
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - Search results
<Jan> - Visited links
<Jan> - Unvisited links
<Jan> Note: Any platform settings for these characteristics are respected.
Greg: search results – do we need to make sure we're not talking about anything like a Google page – just using a native find
<Jan> 1.3.1 Distinguishable Highlighting: The user can have the following types of content uniquely highlighted, overriding any values specified by the author: (Level A)
<Jan> - Selection
<Jan> - Active keyboard focus (indicated by focus cursors and/or text cursors)
<Jan> - In-page search results
<Jan> - Visited links
<Jan> - Unvisited links
<Jan> Note: Any platform settings for these characteristics are respected.
Greg: editing pass over document, change search results to in-page search results
<jeanne> ACTION: jeanne to do an editing pass to change search results to in-page search results. [recorded in http://www.w3.org/2014/10/28-ua-minutes.html#action08]
<trackbot> Created ACTION-1050 - Do an editing pass to change search results to in-page search results. [on Jeanne F Spellman - due 2014-11-04].
<Greg> E.g. 2.4.3 Match Found, "matched content is highlighted", etc.
RESOLUTION: accept 1.3.1 as proposed
<Jan> 1.3.2 Highlighting Selection: The user can set all of the following characteristics of selection highlighting, overriding any values specified by the author: (Level AA)
<Jan> - Foreground colors
<Jan> - Background colors
Jan: if highlighting is being set at the OS level why would it ever did to be set here – why reinvent the wheel
Greg: on a Mac you only get light
blue and light gray
... leave note out – I would not want to restrict developers
from providing more features
... concern- selecting something other than text, selecting an
image. But we might assume that it's understood that were not
suggesting they have to recolor the image
Jan: yes, it doesn't say text
color
... sometimes they do, sometimes they don't – I'm selecting a
W3C image in chrome and it recovers it
Greg: inverting or using the highlight colors?
Jan: using the background color is a filter over the entire thing
Greg: it's probably fine, I'm probably just being overly cautious
<Jan> 1.3.2 Highlighting Selection: The user can set all of the following characteristics of selection highlighting, overriding any values specified by the author: (Level AA)
Jan: 1.3.2 good?
<Jan> - Foreground colors
Gen. agreement
<Jan> - Background colors
Greg: how we test this? Figure out how to test selecting on text items
<Jan> 1.3.2 Highlighting Selection: The user can set all of the following characteristics of selection highlighting, overriding any values specified by the author: (Level AA)
<Jan> - Text color
<Jan> - Background color
Jan: would it help if instead of foreground colors it did say text colors?
Greg: most browsers use the term foreground and background and figure out some way to apply it to nontext content
<Jan> 1.3.2 Highlighting Selection: The user can set all of the following characteristics of selection highlighting, overriding any values specified by the author: (Level AA)
<Jan> - Foreground color
<Jan> - Background color
RESOLUTION: Accept 1.3.2 as proposed above
<Jan> 1.3.3 Highlighting Active Keyboard Focus: The user can set all of the following characteristics of active keyboard focus highlighting, overriding any values specified by the author: (Level AA)
<Jan> - Foreground color
<Jan> - Background color
<Jan> - Border (color, style, and thickness)
<Jan> - Text cursor blink rate
Greg: looks fine
general agreement
RESOLUTION: accept 1.3.3 as proposed above
<Jan> 1.3.4 Highlighting Search Results: The user can set all of the following characteristics of search result highlighting, overriding any values specified by the author: (Level AA)
<Jan> - Foreground color
<Jan> - Background color
<Jan> 1.3.4 Highlighting In-Page Search Results: The user can set all of the following characteristics of in-page search result highlighting, overriding any values specified by the author: (Level AA)
<Jan> - Foreground color
<Jan> - Background color
Greg: implementations?
Jan: should we let this go?
... willing to not have this at all
Greg: I'm reluctant to drop it just because we haven't spotted any implementations yet
Jeanne: accessibility?
Jan: if someone made a bad choice of colors
Jeanne: 1.3.1?
Jen: not usually something you set in the platform
Greg: problem for people who are colorblind
<Greg> Firefox by default highlight in-page search results as white text on mid-green background, which is not very high contrast.
Jan: in page search results – do
we need a AA where we can actually change what those are
... it's not implemented, is it that important, is it likely to
be implemented
Greg: you sure it's not already implemented?
Jim: I don't know of any browser
that allows you to change the search highlighting
... I'd have to look at the Dom and see what the actual code is
for things that are selected
Greg: my preference is not to just willy-nilly delete it
Jeanne: I think it's practical that if we don't have implementations for it – there's not a strong compelling reason to keep it so we should prune it
Jan: use case is a user is colorblind in they do a search for a word, multiple times it was found and the highlighting that was used by the user agent. Workarounds: find, find next
Greg: will go with the majority
no objections
<Jan> 1.3.4 Distinguishing Enabled Elements: The user can set all of the following characteristics of enabled elements highlighting, overriding any values specified by the author: (Level AA)
<Jan> - Foreground color
<Jan> - Background color
<Jan> - Border (color, style, and thickness)
<Jan> 1.3.4 Distinguishing Enabled Elements: The user can set all of the following characteristics of enabled element highlighting, overriding any values specified by the author: (Level AA)
<Jan> - Foreground color
<Jan> - Background color
<Jan> - Border (color, style, and thickness)
RESOLUTION: accept 1.3.4 as proposed above
<Jan> 1.3.5 Highlighting Links: The user can set all of the following characteristics of visited and unvisited links, overriding any values specified by the author:(Level AA)
<Jan> - Foreground color
<Jan> - Background color
<Jan> - Text decoration ???
<Jan> 1.3.5 Highlighting Links: The user can set all of the following characteristics of visited and unvisited links, overriding any values specified by the author:(Level AA)
<Jan> - Foreground color
Jan: we're putting a minimum on here – instead of text decoration should we say underlining
<Jan> - Background color
<Jan> - Underline
Jim: confirming in IE: advanced – always underline links only on hover, never or always, but not foreground and background – nobody that I know that does that
Jan: should we do foreground only – text color of links
Greg: how do they handle a dark background – how do you read the links. It's a cardinal rule, should never be able to change one color without the matching color, should always be in pairs
Jan: Firefox has text and
background colors visited and visited links. But the background
is the entire page
... taking out background color here - somewhere document does
it say change the background color
<Greg> I'm concerned that the phrase " characteristics of visited and unvisited links" does not clearly convey that they need to be independently adjustable.
Jan: it's in 1.4.1, we don't have to do it here
<Jan> 1.3.5 Highlighting Links: The user can set all of the following characteristics of visited and unvisited links, overriding any values specified by the author:(Level AA)
<Jan> - Foreground color
<Jan> - Underline
<Greg> I'd also like to add a note (in either document) recommending that they allow customizing both foreground and background colors.
<Jan> 1.3.5 Highlighting Links: The user can set all of the following characteristics separately for visited and unvisited links, overriding any values specified by the author:(Level AA)
<Jan> - Foreground color
<Jan> - Underline
<Jan> 1.3.5 Highlighting Links: The user can set all of the following characteristics for visited links and for unvisited links, overriding any values specified by the author:(Level AA)
<Jan> - Foreground color
<Jan> - Underline
<Jan> 1.3.5 Highlighting Links: The user can set all of the following characteristics for visited links and (separately) for unvisited links, overriding any values specified by the author:(Level AA)
<Jan> - Foreground color
<Jan> - Underline
<Jan> 1.3.5 Highlighting Links: The user can set all of the following characteristics for visited links and separately for unvisited links, overriding any values specified by the author:(Level AA)
<Jan> - Foreground color
<Jan> - Underline
RESOLUTION: accept 1.3.5 as proposed above
Jan: explanation for Microsoft, you can meet them with OS settings or going beyond OS settings
<jeanne> proposed reply: UAWG agreed 5.1.3 covers the requirement to pick up OS settings. We agree to reword 5.1.3 to make it more clear. 1.3 was also rewritten for effective testing.
<AllanJ> meeting with COGA http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0043.html
<Jan> Scribe: Jan
<jeanne> Note: Any platform settings for these characteristics are respected.
JR: Could this note to 1.4.1 Note: Any platform settings for these characteristics are respected.
<AllanJ> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/0043.html
<AllanJ> http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed.html
<AllanJ> scaling
<AllanJ> scribe: jallan
<AllanJ> ACTION: jallan to craft new SC 1.1.1 that fundamentally everything the browser renders by default (text, controls, etc.) must be accessible by the keyboard, meet minimum contrast, and scales when the user scales content. write SC, IERT [recorded in http://www.w3.org/2014/10/28-ua-minutes.html#action09]
<trackbot> Created ACTION-1051 - Craft new sc 1.1.1 that fundamentally everything the browser renders by default (text, controls, etc.) must be accessible by the keyboard, meet minimum contrast, and scales when the user scales content. write sc, iert [on Jim Allan - due 2014-11-04].
1.4.1 Note: Any platform settings for these characteristics are respected.
1.4.1 Note: Any user settings from the platform for these characteristics are respected.
1.4.1 Note: Any user settings from the platform for these characteristics are implemented.
<AllanJ> RESOLUTION: 1.4.1 Note: Any user settings from the platform for these characteristics are implemented.
<Greg> We should eventually normalize phrases like "user settings from the platform", "platforms color options", etc.
<AllanJ> cs: in the reference document list the settings on each platform for each SC
<AllanJ> Cynthia Shelly from Microsoft is sitting in.
<AllanJ> js: did this at request of low vision folks who do not use AT
<AllanJ> cs: this is more level of control than is allowed at the OS. MS as well as other developers are moving to less settings
<AllanJ> jr: user style sheets, difficult but doable.
<AllanJ> ... also perhaps extensions
<Greg> We allow extensions to be used for conformance, but require that they exist in order to prove that the UA does what it needs to in order to enable that facility in extensions. The UA vendor can contract with a third party in order to ensure such extensions exist, or can create it themselves but make it available as an optional download, etc.
<AllanJ> cs: as I look at this, to make my browser accessible...what do I have to do to make my browser accessible. adding all these settings may make it difficult for folks with cognitvie issues, etc
<AllanJ> cs: advisory documents, what functions belong in browser, extensions, AT, etc. If I am building a browser what are the things I have to do.
<AllanJ> js: what is ordinary in desktop is extraordinary in mobile, and visa-versa
<Greg> This is similar to the way manufacturers deal with large contracts (RFPs), where they do not need to include all features in the base product, but need to make sure a complete suite can be put together that comply with the requirements.
<AllanJ> cs: not saying that shouldn't be done, but what are the base requirements, what should be done by extensions or AT
<AllanJ> jr: perhaps adding information in "Applies to:" section in Reference document that says Browser, or extension, or AT
<AllanJ> cs: perhaps applies to = Usually Implemented In
<scribe> ACTION: Jan to consider how to tag (in the Reference document) whether the SC applies to (is usually implemented in) base browsers, extensions, readers, media players, OS's [recorded in http://www.w3.org/2014/10/28-ua-minutes.html#action10]
<trackbot> Created ACTION-1052 - Consider how to tag (in the reference document) whether the sc applies to (is usually implemented in) base browsers, extensions, readers, media players, os's [on Jan Richards - due 2014-11-04].
<AllanJ> cs: processing all the text is easier, than having a UI with lots of toggles for specific attributes
<AllanJ> gl: this is not widely implemented, and was harder
<AllanJ> js: set levels on global/local, importance to user, easy/hard to do
<AllanJ> jr: perhaps remove globally
<AllanJ> js: done, edited
<AllanJ> cs: stylesheets should be a developer feature not an end user feature. as a transport feature, or api
<AllanJ> gl: rehab engineers may make and distribute CSS for users
<AllanJ> cs: is there a market for that.
<AllanJ> gl: stylish extension,
<AllanJ> cs: don't think user CSS is a good end user feature, not seeing comments in forums, etc.
<AllanJ> js: absence of need requests is not same as absence of need
<AllanJ> cs: should be a tool for extension folks, or browser developers
<AllanJ> cs: user=mom, developer=author, geek, browser engineer
<AllanJ> gl: perhaps add a note that this is an advanced feature not intended for users
<AllanJ> gl: make a def for "user style sheets" css not developed by author or the browser,.
<Greg> The key is to have "user stylesheet" link to the glossary, so readers recognize it as a technical term.
user style sheet: Stylesheets that are not provided by the web content author. The user interface for configuring user style sheets can be targeted at advanced users.
user style sheet: Style sheets that are not provided by the web content author. The user interface for configuring user style sheets can be targeted at advanced users.
<AllanJ> RESOLUTION: add def. user stylesheet: Style sheets that are not provided by the web content author. The user interface for configuring user style sheets can be targeted at advanced users.
<AllanJ> js: this was form content
<Greg> Safari 7.1 on OS X Mavericks does restore form field content when navigating the history.
<Greg> However, it does not restore selection.
<AllanJ> jr: suggest removing selection
<Greg> Safari 7.1 on OS X Mavericks restores point of regard, focus, and form field entries, but not selection.
<AllanJ> ja: +1
<AllanJ> js: +1
<AllanJ> jr: +1
<AllanJ> gl: perhaps add a note that selection would be nice
<Greg> Not thrilled with removing Selection; can we add a note recommending it be restored?
<Greg> Note: It is recommended that selection also be restored.
<AllanJ> RESOLUTION: remove item "c. selection" from 1.8.9 (only one implementation - FF) add Note: It is recommended that selection also be restored.
<Greg> (I strongly feel that "the user agent might" does not convey that it is recommended.)
<AllanJ> cs: agree that hz scrolling is bad. but removing absolute positioning will explode content
<Greg> This is not just about horizontal scrolling, but also giving more width for large text, etc.
<AllanJ> gl: this SC would allow user to at least try to turn off absolute layout to see if they can try to make it easier to use.
<AllanJ> cs: have a hard time believing this use case. may need to gather data.
<AllanJ> gl: changing # of pixels per inch in the OS broke a few things, but made many other things work
<AllanJ> cs: positioning.
<Greg> This is not absolute positioning, but dimensions. There may be other terms for it.
<AllanJ> gl: no, its dimensions not positioning.
<AllanJ> cs. there is a wcag SC for this
<Greg> What about changing to "1.8.14 Ignore Layout Dimensions: The user can have the user agent override author-specified dimensions. (Level AA)"?
<Greg> If an author says a div should be 25% width, that's just as bad as 600px.
<Greg> "1.8.14 Ignore Layout Dimensions: The user can have the user agent override author-specified layout dimensions. (Level AA)"
1.8.14 Ignore Absolute Layout Dimensions: The user can have the user agent override author-specified fixed unit dimensions.
<AllanJ> ja: why? is 25% as bad as 600px
1.8.14 Ignore Fixed Unit Dimensions: The user can have the user agent override author-specified fixed unit dimensions.
<AllanJ> gl: if user changes font size, then will break things
<AllanJ> cs: IE has smart zoom, if you zoom, then things will wrap and prevent most hz scrolling
<AllanJ> cs: MS is trying to deprecate the 1.8.14 feature and use only smart zoom
<AllanJ> gl: does smart zoom need to be reapplied for each page
<AllanJ> cs: persistence would be a good feature for smart zoom
<AllanJ> gl: wrapping to a suboptimal size
1.8.14 Ignore Fixed Unit Dimensions: The user can have the user agent override author-specified fixed unit dimensions.
<AllanJ> jr: smart zoom will meet 1.8.14, need example in Reference document
1.8.14 Ignore Author-Specified Dimensions: The user can have the user agent override author-specified dimensions.
<Greg> As I noted earlier, if an author says a div should be 25% width, that's just as bad as 600px. Percentages can be as bad a fixed dimensions.
JR: Plus add an example etc. that would allow for "smart"-type zoom features that do this intrisically
<AllanJ> RESOLUTION: 1.8.14 Ignore Author-Specified Dimensions: The user can have the user agent override author-specified dimensions. Plus add an example etc. that would allow for "smart"-type zoom features that do this intrisically
<AllanJ> cs: sounds bizzare
<Greg> https://translate.google.com/translate?hl=en&sl=auto&tl=af&u=http%3A%2F%2Fw3.org
<AllanJ> jr: nested UA, some media player, or PDF reader inside a parent UA
<AllanJ> cs: why is the PDF thingy is different from content?
<AllanJ> jr: the wbua can use many of the features in the UA, but take hotmail, how do you search for an email. not using the browser, you use a search in the webbased user agent
<AllanJ> cs: this is searching a server.
<AllanJ> jr: what about 2.4.5 search for alternative content in hotmail
<AllanJ> cs: this makes my brain go into a loop
<Greg> I think the key here is "Note: This success criterion does not apply to non-web-based UA user interfaces, but does include any parts of non-web-based user agents that are web-based (e.g. help systems)." That is, even if we get rid of the concept of web-based UA, this SC would still exist.
<AllanJ> cs: user agents run in the operating system
<AllanJ> jr: epub reader
<AllanJ> kf: is Word a user agent
<AllanJ> cs: no,
<AllanJ> kf: you can open a webpage in Word.
<AllanJ> gl: word uses http to read content on the web. that is a UA feature
<AllanJ> kf: if word is a UA, then is Word Online or Google docs a AU
<AllanJ> ja; can I use Office 365 in a browser to open a webpage
<AllanJ> cs: but it is in the browser content area, so it is content
<Greg> In fact, the wording of 5.1.1 does not say it's about web-based user agents, but about web-based UA UI, such as (as the Note says) a browser's Help system that renders help files written in HTML, or shows dialog boxes authored in HTML.
<AllanJ> cs: want to apply additional rules to content other than wcag base on a specific use case
<Greg> So, I must admit I don't understand how the discussion is relevant to 5.1.1, except for passing and non-requisite mentions in the Note.
<AllanJ> kp: users get confused because the have expectations about behavior of apps. but the apps change because of the underlying technology
<AllanJ> cs: word online that will work like a webapplication, its all content.
<AllanJ> cs: figuring out the core mapping between the UA and platform API is very important. a UA inside a UA does not have access to the platform (OS) api
<AllanJ> cs: some SCs apply to OS, or UA,, or AT
<AllanJ> cs: if the resulting content of whatever is inside the UA fails WCAG, then it is flawed separate from how the UA works
<AllanJ> cs: if you remove the words Web-Based user agent it would not change the document
<Greg> "Note: This success criterion applies to any parts of user agents that are web-based (e.g. help systems). However, it is recommended that developers of non-web-based user agent user interfaces follow the Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT) [WCAG2ICT]."
<Greg> That is a simplified version of the existing Note for 1.5.1, removing the concept of web-based UA.
<Greg> That Note under 1.5.1 is the ONLY occurrence of the term "web-based user agent" outside of the glossary.
<AllanJ> kf: WAI has triangle of WCAG, ATAG, UAAG. there are gaps. UAAG is trying to fill the a11y gap for web applications
<AllanJ> ... the app working groups should be dealing with the keyboard shortcuts, and other concepts, rather than making UAAG the watchdog for everything
<AllanJ> kp: example, single key shortcuts, gmail, hotmail. why are they bad for speech users.
<AllanJ> cs: not hooked up to the a11y api. but a simple phrase can execute things beyond my control
<AllanJ> kp: I want to be able to control and change the keybindings in the UA to make it easier for speech users.
<AllanJ> cs: is that specific to something rendering other content, or specific to a web app
<AllanJ> kf: the document has expanded in scope. do the guidelines general usability issues and not specific to UAs
<AllanJ> cs: perhaps they should be in WCAG
<AllanJ> js: WCAG has been closed
<AllanJ> kp: changing keyboard shortcuts should be in the UA, not in the content.
<AllanJ> cs: are these requirements specific to rendering content. what is overlap between UAAG & WCAG, how do we decide what is a browser and what is not.
<AllanJ> kf: UI usability is critical even in a minimalist UA
<AllanJ> cs: WCAG does not address usability.
<kford> I will say that supporting correct accessibility mappings to accessibility APIs is key here.
<kford> For part of user agent success.
<AllanJ> js: we always look at a11y, but we want to make the life of the user easier
<AllanJ> js: need to merge UAAF WCAG, ATAG
<AllanJ> response: reworded 1.10.1, asking for information already being sent to a11y api, can get the information for orientation when zoomed in
<jeanne> Reply: UAWG has reworded 1.10.1 and are only asking that information that is being sent to API, so that that people who are not using AT can still understand context.
http://lists.w3.org/Archives/Public/public-uaag2-comments/2014Oct/0002.html
<AllanJ> comment: Defaulting to source order is a bug, not something to be codified. You are preventing browsers from implementing navigation based on visual rendering, which many add-on AT products support, and which is often a better solution. If it must be kept, make it AAA The rest of 2.2 looks ok for level
<AllanJ> gl: we have to require them to make sense rather than random. use source order rather than visual order because everyone already does it. and having the browser decide what's best subverts the authors intent
<AllanJ> js: form order is difficult because of author bad practices.
<AllanJ> js: thinks browsers may be developing heuristics to parse the html & css to navigate visually.
<Greg> There is advantage to us specifying *some* default order, so that navigation is consistent between browsers. Given that, argument can be made for either document order or layout order. The advantages of the former are (a) it's how browsers all work historically, so not changing behavior, and (b) because of that, some pages are authored with that behavior in mind, not specifying tabindex...
<Greg> ...because document order IS the order they want to have.
<AllanJ> ja: but everyone already navigates by source code order.
<AllanJ> gl: random = navigation would be different from browser to order
<Greg> Conversely, as Cynthia and Jan say, there are advantages to letting a browser implement an order they think is better, such as left-to-right, top-to-bottom (in English).
<Greg> I don't think we should prohibit a different order, but I do think that a browser imposing its heuristics might break some existing sites.
<Greg> For example, a site which puts the navigation bar at the end of the document, so that doesn't come first in the tab order even though it's visually at the left edge of the window.
<Greg> A compromise of course is to allow them do change the default, as long as the user can choose the older behavior, but in reality I don't see users changing that setting given that it's only occasional web sites that would suddenly be working differently, and they won't know why.
<Greg> But vendors hate that just as much: saying if they change behavior they have to put in an option to keep the old behavior.
<Greg> Of course, as written now it does not preclude the UA from providing an option to do heuristic navigation order, but we do preclude it from being the default option.
<AllanJ> js: this doesn't solve any problems.
<AllanJ> jr: we have all kinds of other supports., making this mute
<AllanJ> jr: perhaps make it AA
<AllanJ> ja: +1
2.2.3 Default Navigation Order: If the author has not specified a navigation order, the user can have the default sequential navigation order be the source order. (Level A)
2.2.3 Default Navigation Order: If the author has not specified a navigation order, the user can have the default sequential navigation order be the source order. (Level AA)
<AllanJ> RESOLUTION: 2.2.3 Default Navigation Order: If the author has not specified a navigation order, the user can have the default sequential navigation order be the source order. (Level AA)
<AllanJ> kp: mouseless browsing
<AllanJ> ... this is possible. when there are many enabled elements is when you need it most
<AllanJ> kf: not possible. comment is 100% correct
<AllanJ> gl: this is when the media player knows all the information and to convey information in a linear fashion.
<AllanJ> kf: nobody does this, no one will
<AllanJ> ja: +1
<AllanJ> ja: delete
<AllanJ> no objections
<AllanJ> RESOLUTION: delete 2.5.1
<AllanJ> js: we made it more specific. could be A
<AllanJ> js: does this interfere with 1.9.1
<AllanJ> gl: structural navigation does not mean navigating by header, if I am on h2 I want to jump to the previous heading level (1) not the previous heading
<AllanJ> js: leave alone.
<AllanJ> jr: this is a lot of work
<AllanJ> ... nearly untestable. want to delete.
<k> Greg: some browsers do allow this for outline views- it's fairly common, but structural navigation probably not so much
<k> Greg: headings map extension
<k> Greg: checkboxes for which heading levels you want to do.
<AllanJ> gl: ok to delete
<AllanJ> objections to delete 2.5.3
<AllanJ> none heard
<AllanJ> gl: no implementations
<Greg> However, when an application does not allow you restrict an outline view by heading level, it can often become nearly unusable (e.g. having to scroll through dozens or even hundreds of H4s to get to the H3 you're looking for).
<AllanJ> RESOLUTION: delete 2.5.3
<Greg> I would have liked to keep this for outline view, even at AAA.
<AllanJ> rrsgaent, make minutes
<Greg> Re 2.5.3 I didn't feel it was difficult to test, merely that there were no implementations for half of it.
<AllanJ> cs: webapps, hooking events to a11yAPI, but difficult
<AllanJ> ... would be hard to implement. there is something here that might be doable, but not sure what it is.
<AllanJ> ... webapps is working in this area
<AllanJ> jr: how would this be tested? what is in scope? who ever wants to keep this must write the test
<AllanJ> gl: if user puts focus on link, brings up context menu. what goes in the menu.
<AllanJ> jr: if not in tab order, div with javascript,
<AllanJ> cs: 2.6.1 does not say that the user has to be on an element in order to know what the activation controls are. the actions are not built until the element gets focus or hover
<AllanJ> cs: on mouse over, click handler gets bound, but it is not built until hover
<Greg> I feel that people creating a straw interpretation of this SC that is far larger in scope than its original intent, and easy to shoot down.
<AllanJ> ... there is no way to know when events are being built and when to communicate to users.
<AllanJ> cs: bubbling, browser doesn't know whats going on until something happens
<AllanJ> gl: a recognized association between element and event
<Greg> If this was actually about tabbing to an element or right-clicking on it, getting its context menu, and having a sub-menu of currently recognized input actions (hover, click, etc.).
<AllanJ> cs: because of bubbling this may result in the user getting bad information.
<AllanJ> cs: in WebApp and user intentions will cause this to be mute.
<Greg> I'd like to hear a walk through the Examples, determining whether you consider them not valuable to the users, or not technically feasible, etc.
<AllanJ> kp: what do we do with this item. it affects many users. some pages this will work, some not
<AllanJ> ja: so it depends on how the author wrote the script as to whether this SC gives relevant information to the user
<AllanJ> kp: would like the ability to try to use a site rather than not using it at all.
<AllanJ> cs: this may break things for average user.
<Greg> Another approach would be to replace this with a UA feature that lets the user simulate common input actions on a target element (e.g. simulate hover, click, pinch, etc. actions on an element that is right-clicked or has keyboard focus), ignoring the question of what input methods are bound to the element, and presumably bubbling just like a normal, physical input action would.
<AllanJ> cs: not possible to implement in mainstream browser that meet the quality standards of the browser. better for extension or AT.
<Greg> The most common problem this would solve is that a badly-written page has scripted mouse actions on an element, with no keyboard equivalent.
<AllanJ> gl: why can't user use enter or space to activate a control
<AllanJ> gl: when you split OS from UA. it gets hard. how to get a hover event from keyboard. or have mouse keys have a feature of 'jump to keyboard focus'
<AllanJ> cs: not sure we can implement this so it works consistently
<Greg> If the user tabs to a link that also has a hover action, it would be a lot of work for them to spatially navigate a mouse pointer to it using MouseKeys in order to perform the hover. Since the user has already selected the item in the browser, why make them select it again in another tool?
<AllanJ> cs: testability
<AllanJ> jr: difficult to test, too many variables.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/take out winks/take out links/ Succeeded: s/I would want/I would not want/ Succeeded: s/can/should/ Succeeded: s/shandled/handled/ Succeeded: s/allow extensions/allow extensions to be used for conformance/ Succeeded: s/cs: absence/js: absence/ Succeeded: s/histor/history/ Succeeded: s/Absolute// Succeeded: s/wording of 1.5.1 does/wording of 5.1.1 does/ Succeeded: s/relevant to 1.5.1, except/relevant to 5.1.1, except/ Succeeded: s/noone/no one/ Succeeded: s/not build/not built/ Succeeded: s/I like/I'd like/ Found Scribe: Jeanne Inferring ScribeNick: jeanne WARNING: No scribe lines found matching previous ScribeNick pattern: <k> ... Found ScribeNick: k Found Scribe: Jan Inferring ScribeNick: Jan Found Scribe: jallan Scribes: Jeanne, Jan, jallan ScribeNicks: k, jeanne, Jan Default Present: Jeanne, Suite1242, Greg_Lowney, Kelly Present: Jeanne Suite1242 Greg_Lowney Kelly Kim Jim Jan Greg Kenny_Zhang Cynthia_Shelly(Microsoft) Charles_LaPierre Found Date: 28 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/28-ua-minutes.html People with action items: jallan jan jeanne kim[End of scribe.perl diagnostic output]