- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Tue, 28 Oct 2014 19:43:12 -0500
- To: WAI-ua <w3c-wai-ua@w3.org>
- Message-ID: <CA+=z1WmMZrrRiRc8mFeQVU1+-RbcV-kv-CJYKfnvCkYE4W-X5A@mail.gmail.com>
from: http://www.w3.org/2014/10/28-ua-minutes.html
- DRAFT - User Agent Accessibility Guidelines Working Group Teleconference 28
Oct 2014
See also: IRC log <http://www.w3.org/2014/10/28-ua-irc>
http://www.w3.org/2014/10/28-ua-irc
Attendees
Present Jeanne, Suite1242, Greg_Lowney, Kelly, Kim, Jim, Jan, Greg,
Kenny_Zhang, Cynthia_Shelly(Microsoft), Charles_LaPierre Regrets Chair
JimAllan Scribe Jeanne, Jan, jallan
Contents
- Topics <http://www.w3.org/2014/10/28-ua-minutes.html#agenda>
1. Finishing 2.2.2
<http://www.w3.org/2014/10/28-ua-minutes.html#item01>
2. Review of "Viewports"
<http://www.w3.org/2014/10/28-ua-minutes.html#item02>
3. Microsoft comments
<http://www.w3.org/2014/10/28-ua-minutes.html#item03>
4. Cynthia's comments on 1.1.5
<http://www.w3.org/2014/10/28-ua-minutes.html#item04>
5. Microsoft comments on 1.1.5
<http://www.w3.org/2014/10/28-ua-minutes.html#item05>
6. Microsoft comments on 1.1.6
<http://www.w3.org/2014/10/28-ua-minutes.html#item06>
7. Microsoft comments on 1.2.1
<http://www.w3.org/2014/10/28-ua-minutes.html#item07>
8. Microsoft comments on 1.2.2
<http://www.w3.org/2014/10/28-ua-minutes.html#item08>
9. Microsoft comments on 1.3
<http://www.w3.org/2014/10/28-ua-minutes.html#item09>
10. MS06 on 1.3 <http://www.w3.org/2014/10/28-ua-minutes.html#item10>
11. Microsoft comments on 1.3.2
<http://www.w3.org/2014/10/28-ua-minutes.html#item11>
12. Microsoft comments on 1.3.3
<http://www.w3.org/2014/10/28-ua-minutes.html#item12>
13. Microsoft comments on 1.3.4
<http://www.w3.org/2014/10/28-ua-minutes.html#item13>
14. Microsoft comments on 1.3.5
<http://www.w3.org/2014/10/28-ua-minutes.html#item14>
15. Microsoft comments on 1.4.1
<http://www.w3.org/2014/10/28-ua-minutes.html#item15>
16. MS06 1.4.2 handled by AT?
<http://www.w3.org/2014/10/28-ua-minutes.html#item16>
17. MS06 1.4.5 <http://www.w3.org/2014/10/28-ua-minutes.html#item17>
18. MS06 1.7 stylesheets
<http://www.w3.org/2014/10/28-ua-minutes.html#item18>
19. MS06 1.8.9 viewport history
<http://www.w3.org/2014/10/28-ua-minutes.html#item19>
20. MS06 1.8.14 break content
<http://www.w3.org/2014/10/28-ua-minutes.html#item20>
21. web-based useragent
<http://www.w3.org/2014/10/28-ua-minutes.html#item21>
22. MS06 1.10.1 <http://www.w3.org/2014/10/28-ua-minutes.html#item22>
23. MS06 2.2.3 <http://www.w3.org/2014/10/28-ua-minutes.html#item23>
24. MS06 2.3.1 <http://www.w3.org/2014/10/28-ua-minutes.html#item24>
25. MS06 2.5.1 this is vapor ware
<http://www.w3.org/2014/10/28-ua-minutes.html#item25>
26. MS06 2.5.2 could be A
<http://www.w3.org/2014/10/28-ua-minutes.html#item26>
27. MS06 2.5.3 <http://www.w3.org/2014/10/28-ua-minutes.html#item27>
28. MS06 2.6 <http://www.w3.org/2014/10/28-ua-minutes.html#item28>
- Summary of Action Items
<http://www.w3.org/2014/10/28-ua-minutes.html#ActionSummary>
------------------------------
<trackbot> Date: 28 October 2014
<jeanne> scribe: Jeanne
Finishing 2.2.2
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?
Review of "Viewports"
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].
Microsoft comments
<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
Cynthia's comments on 1.1.5 Microsoft comments on 1.1.5 Microsoft comments
on 1.1.6
accepted
Greg: why did we choose AAA on this?
Jeanne: difficult to do
Microsoft comments on 1.2.1
agreed
Microsoft comments on 1.2.2
agreed
Microsoft comments on 1.3
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.
MS06 on 1.3
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
Microsoft comments on 1.3.2
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
Microsoft comments on 1.3.3
Greg: looks fine
general agreement
*RESOLUTION: accept 1.3.3 as proposed above*
Microsoft comments on 1.3.4
<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*
Microsoft comments on 1.3.5
<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
Microsoft comments on 1.4.1
<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.
MS06 1.4.2 handled by AT?
<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].
MS06 1.4.5
<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
MS06 1.7 stylesheets
<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.
MS06 1.8.9 viewport history
<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.)
MS06 1.8.14 break content
<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
web-based useragent
<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
MS06 1.10.1
<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.
MS06 2.2.3
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)
MS06 2.3.1
<AllanJ> kp: mouseless browsing
<AllanJ> ... this is possible. when there are many enabled elements is when
you need it most
MS06 2.5.1 this is vapor ware
<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
MS06 2.5.2 could be A
<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.
MS06 2.5.3
<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.
MS06 2.6
<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.
Summary of Action Items *[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
[End of minutes]
------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version
1.138 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2014-10-29 00:39:17 $
--
[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
Received on Wednesday, 29 October 2014 00:43:41 UTC