- From: Jeanne Spellman <jeanne@w3.org>
- Date: Mon, 27 Oct 2014 20:29:37 -0400
- To: UAWG <w3c-wai-ua@w3.org>
Minutes:
http://www.w3.org/2014/10/27-ua-minutes.html
Text of Minutes
[1]W3C
[1] http://www.w3.org/
- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
27 Oct 2014
[2]Agenda
[2] http://www.w3.org/WAI/UA/2014/F2Fagenda20141027
See also: [3]IRC log
[3] http://www.w3.org/2014/10/27-ua-irc
Attendees
Present
Kim, Jim, Jeanne, Jan, Kelly, Greg,
Charles_LaPierre(Benetech)
Regrets
Chair
Jim, Kelly
Scribe
allanj
Contents
* [4]Topics
1. [5]what's implemented
2. [6]implementation testing
3. [7]test 1.3.2
4. [8]at risk element 1.2.1
5. [9]at risk, 1.2.2
6. [10]at risk 1.3.2
7. [11]at risk 1.9.1 should just be headings
8. [12]at risk 1.10.1 what do we test
9. [13]at risk 2.2.2
* [14]Summary of Action Items
__________________________________________________________
<trackbot> Date: 27 October 2014
[15]http://jspellman.github.io/UAAG-LC-Comment/
[15] http://jspellman.github.io/UAAG-LC-Comment/
<jeanne> [16]http://www.w3.org/WAI/UA/2014/F2Fagenda20141027
[16] http://www.w3.org/WAI/UA/2014/F2Fagenda20141027
tests:
[17]https://www.w3.org/WAI/UA/work/wiki/Tests_for_CR#Principle_
1:_Perceivable
[17]
https://www.w3.org/WAI/UA/work/wiki/Tests_for_CR#Principle_1:_Perceivable
<Greg> OK
<kford>
[18]http://en.wikipedia.org/wiki/Trident_(layout_engine)
[18] http://en.wikipedia.org/wiki/Trident_(layout_engine)
<scribe> scribe: allanj
discussion of rendering engines vs UI
chrome, opera = blink, firefox = gecko, IE = mshtml, safari =
webkit
what's implemented
desktop - V
desktop -
[19]http://w3c.github.io/UAAG-Implementations/desktop.html
[19] http://w3c.github.io/UAAG-Implementations/desktop.html
in browser column: Pass/Fail
in the browser notes: if plugin/extension required (with url),
include steps for settings or how to cause something to work
implementation testing
browser assignments - Greg=Safari, Jan=Chrome, Jeanne=Firefox,
Kelly=IE, Jim=Opera, Kim=mercury
<clapierre> *Kelly, Charles LaPierre here I am observing,
thought I would say Hi!*
kim-mercury on the iPhone
<Jan> [20]http://www.w3.org/WAI/demos/bad/before/survey.html
[20] http://www.w3.org/WAI/demos/bad/before/survey.html
<jeanne> Firefox, 1.3.1, Test 1, Pass
<clapierre> FireFox 33.0.1 on Mac, Test 1, Pass
<Jan> Chrome_Windows_v38, 1.3.1, Test 1, Pass
opera v25 1.3.1 test 1 - pass
gl: need to see that selection is different from focus
jr: missing test
kf: hightlighting definition does not include requirement for
communication thru API.
... when screen readers used off-screen models we knew where SR
got the information.
this test has nothing to do with programmatic access, is it
implicitly assumed that programmatic access is incuded
gl: test procedure 3? doesn't seem right
[21]http://www.w3.org/WAI/demos/bad/after/survey.html
[21] http://www.w3.org/WAI/demos/bad/after/survey.html
<Jan> [22]http://www.w3.org/WAI/
[22] http://www.w3.org/WAI/
<Jan> [23]http://www.w3.org/
[23] http://www.w3.org/
<Greg>
[24]http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed
.html
[24] http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed.html
<Jan> Chrome_Windows_v38, 1.3.1, Test 2, Pass
<jeanne> Firefox 33, 1.3.1, Test 2, Pass
<Jan> Chrome_Windows_v38, 1.3.1, Test 3, Pass (assuming that a
flashing cursor is enough of a highlighting for text areas)
<Greg> To test #3 you need to have both enabled and disabled
elements. I used Safari's built-in debugger to add the
"disabled" attribute to the INPUT element used for last name,
then verified that it is rendered looking differently than the
other INPUT, still enabled element.
<Jan> Chrome_Windows_v38, 1.3.1, Test 4, Pass
<Jan> Chrome_Windows_v38, 1.3.1, Test 5, Pass
<Greg> However, the instructions for Test Procedure 3 are
incorrect. This is not about which element is selected or has
focus, but whether all the enabled elements can be
distinguished at a glance from their disabled counterparts.
<Jan> Chrome_Windows_v38, 1.3.1, Test 6, Pass
<jeanne> Firefox 33, 1.3.1, Test 4, Pass
IE_v11, 1.3.1, test 1, pass
IE_v11, 1.3.1, test 2, pass
IE_v11, 1.3.1, test 3, pass
IE_v11, 1.3.1, test 4, pass
IE_v11, 1.3.1, test 5, pass
<Greg> The test document referenced should be referred to as
"test page with rendered text and enabled *and disabled*
elements".
IE_v11, 1.3.1, test 6, pass (search term is highlighted white
on blue, if you select something after searching, the search
will change color to black on yellow, and selection is white on
blue)
<Greg> Ideally they would check each element type to verify
that the enabled and disabled appearances are different.
js: we need to have a place where we say "all of the test must
pass"
jr: edited
<Jan>
[25]http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed
.html
[25] http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed.html
<jeanne> [26]https://www.w3.org/WAI/UA/work/wiki/1.3.1
[26] https://www.w3.org/WAI/UA/work/wiki/1.3.1
<k> safari ios8 on ipad test 1 pass
<k> safari ios8 on ipad test 2 pass
<k> mercury v8.7.2 1.3.1 test 1 pass
<k> mercury v8.7.2 1.3.1 test 2 pass
<Jan> Firefox 33, 1.3.1, Test 3, Pass (although the difference
between enabled and disabled text entry areas is visually
minimal)
js: what is purpose of test 3, do we need it. what is the a11y
case
kp, and jr: it is needed to know what you can interact with
before you get to it.
<jeanne> Firefox 33, 1.3.1, Test 5, Pass
<jeanne> Firefox 33, 1.3.1, Test 6, Pass
<Greg> Safari 7.1, 1.3.1 passes all 6 tests (although the
distinction between enabled and disabled elements is far too
subtle)
<Jan> Firefox 33, 1.3.1, 1-6 tests pass (Note: For Test 3 the
difference between enabled and disabled text entry areas is
visually minimal)
IE_v11, 1.3.1, 1-6 pass, note6 (search term is highlighted
white on blue, if you select something after searching, the
search will change color to black on yellow, and selection is
white on blue),
<Jan> Chrome_Windows_v38, 1.3.1, passes 1-6 tests
<k> safari ios8 on ipad test 1,2,4 pass, 5 fail (no find in
page function), 3, 6 needed disabled element – not tested
<k> mercury v8.7.2 1.3.1 test 1,2,4 pass, 5 fail (no find in
page function), 3, 6 needed disabled element – not tested
<jeanne> Tweet to a table of focusable elements in HTML ->
[27]https://twitter.com/rodneyrehm/status/526655289643515904
[27] https://twitter.com/rodneyrehm/status/526655289643515904
<clapierre> FireFox 33.0.1 Mac 1-6 tests Pass
[28]https://www.w3.org/WAI/UA/work/wiki/1.3.2
[28] https://www.w3.org/WAI/UA/work/wiki/1.3.2
<Jan>
[29]http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed
.html
[29] http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed.html
[30]http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/a
tt-0027/form2.htm
[30]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/att-0027/form2.htm
<jeanne>
[31]http://www.w3.org/WAI/UA/CR-UAAG2/SampleFiles/TextElementsS
amples.html
[31]
http://www.w3.org/WAI/UA/CR-UAAG2/SampleFiles/TextElementsSamples.html
<k> Update mercury v8.7.2 1.3.1 test 1,2,4 pass, 5 pass with
Search in Page extension; 3, 6 needed disabled element – not
tested
test 1.3.2
<Greg> In Test Procedure 1 it doesn't actually say to select
any text or do other things that should highlight anything.
<kford> If we have this question do our docks need to answer it
better given we are asking it of ourselves?
ja: what does 'size when the indicator is an image' mean/
<k> note: puffin browser has a trackpad mouse
gl: in google, the indicator of the current item in the search
results was an image. the image would need to be resized. if
not used mark as NA
jr: user stylesheets are complicated, and most users wont use
them. what is the requirement for the browser to allow changes
to rendering of information.
gl: Ideally the UA would provide a robust UI to do this, but
not likely to happen.
<Greg> In OS X Mavericks, you can choose between two and only
two colors for highlighting keyboard focus: light blue, and
gray. Safari does respect that choice, although it's of minimal
value because it's so limited.
<Greg> On the other hand, OS X Mavericks supports any highlight
color for selected text (not just two choices).
<Jan_> Firefox_for_Windows_v33 1.3.2 Test 1- Text selection
PASS? - picks up OS selected item color (but can't change
borders)
<Jan> Firefox_for_Windows_v33 1.3.2 Test 2- Keyboard Focus
PASS? - using Stylish add-on
<Jan> Firefox_for_Windows_v33 1.3.2 Test 2- Keyboard Focus
PASS? - using Stylish add-on (Native support removed)
<k> Perfect Browser has a setting to enable 25 comment browser
keyboard shortcuts for a Bluetooth keyboard: Settings/External
keyboard shortcuts
<clapierre> FireFox 33.0.1 Mac using Stylish add-on could Pass
for test 2
<Greg> Safari 7.1 on OS X Mavericks: 1.3.2: Test Procedure 1:
Fail. (It respects the OS's preference for highlight background
color, but does not allow changing foreground color
automatically or manually, so some combinations are unreadable.
No border support.)
IE_v11_windows 1.3.2 Test 1, (internet options > general >
colors > uncheck Windows Colors, then set whatever color for
the 5 items. you can set background, IE takes care of
contrasting foreground. NA on Foreground, Borders, Blinkrate
IE_v11_windows 1.3.2 Test 2, menu: tools>accessibility>check
'format documents using my style sheet', user must create style
sheet, NA on size and blink rate
<Greg> Safari 7.1 on OS X Mavericks: 1.3.2: Test Procedure 2:
Fail. ( only allow changing the border color between light blue
and light gray, and not the thickness, etc.)
<Jan> Back from lunch...
<Jan> [32]https://www.w3.org/WAI/UA/work/wiki/Tests_for_CR
[32] https://www.w3.org/WAI/UA/work/wiki/Tests_for_CR
at risk element 1.2.1
bullet 2: change to" If the user agent makes available metadata
related to the non-text content available programmatically, but
not via fields reserved for text alternatives" or
eliminate it.
Proposal: remove bullet 2 for 1.2.1. and rewrite 1.2.1
<Jan> 1.2.1 Support Repair by Assistive Technologies: If text
alternatives for non-text content are missing or empty, the
user agent doesn't attempt to repair the text alternatives by
substituting text values that are also available to assistive
technologies (e.g. image file name).
<Jan>
[33]http://www.w3.org/TR/UAAG10/guidelines.html#tech-null-alt
[33] http://www.w3.org/TR/UAAG10/guidelines.html#tech-null-alt
<Greg> This is to avoid problems when (for example) the
metadata in an image does not match the way it's being used on
the current page. It allows a screen reader to distinguish
between metadata provided by the page author, who knows the
image's use here, vs. metadata tagging along from some long-ago
source.
<Greg> For example, John is creating a web page that uses an
image of a check mark for "Selected". He grabs a PNG file from
another site, not realizing that it's embedded IPTC TITLE
attribute says "You are a winner!". John should set alt, but if
he forgets to, it's better for a screen reader to say "image, I
don't know what it means" than to say "image, You're a winner!"
no browser does the above.
any objections to new wording for 1.2.1
none heard
RESOLUTION: 1.2.1 Support Repair by Assistive Technologies: If
text alternatives for non-text content are missing or empty,
the user agent doesn't attempt to repair the text alternatives
by substituting text values that are also available to
assistive technologies (e.g. image file name). (AA)
at risk, 1.2.2
<jeanne> ACTION: Jeanne to update the IER of 1.2.1 to reflect
removing the metadata component. [recorded in
[34]http://www.w3.org/2014/10/27-ua-minutes.html#action01]
<trackbot> Created ACTION-1040 - Update the ier of 1.2.1 to
reflect removing the metadata component. [on Jeanne F Spellman
- due 2014-11-03].
jr: you can only test to see if there is a UI component for
turning on off feature. but what would the test file look like.
how would we know if the UA did the right thing?
recommend removing this SC
RESOLUTION: mark @@ATRISK of removal, write Simon, can you come
up with a test of expected behavior of the browser. separate
from does the UI component exist.
at risk 1.3.2
RESOLUTION: rewrite 1.3.2 break into separate items to make
testing easier
<scribe> ACTION: Jan to rewrite 1.3.2 to make testing easier
[recorded in
[35]http://www.w3.org/2014/10/27-ua-minutes.html#action02]
<trackbot> Created ACTION-1041 - Rewrite 1.3.2 to make testing
easier [on Jan Richards - due 2014-11-03].
topic at risk 1.8.8
should actually be 1.8.6
"at the same location" is confusing
gl: if the entirety of the point of regard is in the viewport
when scaled, its ok. if larger than the viewport then some
portion must remain in the viewport.
<Greg> Note that the point of regard is NOT a point, but an
element or range (e.g. button or selected text).
<Jan> GL: When the point of regard is larger than the viewport,
the user agent should emphasize the corner that is first
according to the current language's reading order (e.g.
Uppler-left corner for English)
<Jan> 1.8.6 Maintain Point of Regard: The point of regard
remains visible within the viewport when the viewport is
resized, when content is zoomed or scaled, or when content
formatting is changed. (Level A) Note: When the point of regard
is larger than the viewport, the user agent should emphasize
the corner that is first according to the current language's
reading order (e.g. Uppler-left corner...
<Jan> ...for English)
<Jan> 1.8.6 Maintain Point of Regard: The point of regard
remains visible within the viewport when the viewport is
resized, when content is zoomed or scaled, or when content
formatting is changed. (Level A) Note: When the point of regard
is larger than the viewport, the user agent should keep visible
the leading corner of the point of regard according to the
current language's reading order (e.g....
<Jan> ...Upper-left corner for English).
<Jan> 1.8.6 Maintain Point of Regard: The point of regard
remains visible within the viewport when the viewport is
resized, when content is zoomed or scaled, or when content
formatting is changed. (Level A) Note: When the point of regard
is larger than the viewport, the user agent should keep visible
the beginning of the point of regard according to the current
language's reading order (e.g. first...
<Jan> ...character or upper-left corner of an image in
English).
<Jan> 1.8.6 Maintain Point of Regard: The point of regard
remains visible within the viewport when the viewport is
resized, when content is zoomed or scaled, or when content
formatting is changed. (Level A) Note: When the point of regard
is larger than the viewport, the user agent keeps visible the
beginning of the point of regard according to the current
language's reading order (e.g. at least...
<Jan> ...the first character in English).
<Greg> For text, ideally have the entire range visible. If it's
larger than the viewport, as much as possible of the text
should be visible, including the beginning of the text
according to its language's reading order.
<Jan> 1.8.6 Maintain Point of Regard: The point of regard
remains visible within the viewport when the viewport is
resized, when content is zoomed or scaled, or when content
formatting is changed. (Level A) Note: When the point of regard
is larger than the viewport, the user agent keeps visible the
beginning of the point of regard according to the current
language's reading order (e.g. top-left in...
<Jan> ...English).
RESOLUTION: change 1.8.6 Maintain Point of Regard: The point of
regard remains visible within the viewport when the viewport is
resized, when content is zoomed or scaled, or when content
formatting is changed. (Level A) Note: When the point of regard
is larger than the viewport, the user agent keeps visible the
beginning of the point of regard according to the current
language's reading...
... order (e.g. top-left in English)
<Greg> For text, ideally have the entire range visible. If it's
larger than the viewport, as many characters as possible should
be visible, including the first character according to its
language's reading order. If the entire first character is
larger than the viewport, the leading portion of the character
should be visible (e.g. the upper left corner for English).
at risk 1.9.1 should just be headings
<Jan> 1.9.1 Outline View: Users can view a navigable outline of
the rendered content that allows focus to be moved to the
corresponding element in the main viewport. (Level AA) Note:
The elements reflected in the outline view depend on the web
content technology, and may include headings, table captions,
and content sections.
<Jan> 1.9.1 Outline View: Users can view a navigable outline of
named regions in the rendered content that allows focus to be
moved to the corresponding region in the main viewport. (Level
AA)
<Greg> named regions (e.g. defined by headings, ARIA Landmark,
or table captions)
<Jan> Defn: Named Regions: ...
<Greg> Named Regions: elements or ranges of content which the
author has provided with a human-readable name.
<Greg> Examples include regions defined by headings, ARIA
landmarks, and table captions.
<Jan> 1.9.1 Outline View: Users can view a navigable outline of
the headings in the rendered content that allows focus to be
moved to the corresponding element in the main viewport. (Level
AA)
<Greg> Named Regions: elements or ranges of content that have
recognized, author-provided, human-readable names (i.e. names
conveyed in attribute fields defined as being for human
readers).
<Jan> Note: An outline view might also include other named
elements.
<Jan> Note: An outline view might also include other named
elements such as document landmarks.
<clapierre>
[36]http://www.w3.org/WAI/GL/wiki/Using_ARIA_landmarks_to_ident
ify_regions_of_a_page
[36]
http://www.w3.org/WAI/GL/wiki/Using_ARIA_landmarks_to_identify_regions_of_a_page
aria landmark roles
[37]http://www.w3.org/TR/wai-aria/roles#landmark_roles
[37] http://www.w3.org/TR/wai-aria/roles#landmark_roles
<Jan> 1.9.1 Outline View: Users can view a navigable outline of
the headings in the rendered content that allows focus to be
moved to the corresponding element in the main viewport. (Level
AA) Note: An outline view might also include other named
elements such as document landmarks.
RESOLUTION: change 1.9.1 Outline View: Users can view a
navigable outline of the headings in the rendered content that
allows focus to be moved to the corresponding element in the
main viewport. (Level AA) Note: An outline view might also
include other named elements such as document landmarks.
at risk 1.10.1 what do we test
<Jan> 1.10.1 Show Related Elements: The user can access the
information from explicitly-defined relationships in the
content, including at least the following: (Level AA) - label
for a control or image (e.g. HTML label element, figcaption or
aria-labelledby attributes) - caption for a table - row and
column labels for a table cell
discussion, "control" is problematic
jr: at least one type of label for each type of control or
label.
... point of this was to make this information available to
non-screen reader users.
... there are still many ways to label a control. could we use
the 'accessible name' in the a11y api and reveal to user with a
mechanism like right click on image in FF to get properties
<Jan>
[38]http://www.w3.org/TR/wai-aria/roles#textalternativecomputat
ion
[38] http://www.w3.org/TR/wai-aria/roles#textalternativecomputation
<clapierre> There is the Firefox extension for navigating Aria
Landmarks.
[39]http://www.w3.org/TR/wai-aria/roles#landmark_roles The
actual download of the extension is
[40]https://github.com/matatk/landmarks/releases
[39] http://www.w3.org/TR/wai-aria/roles#landmark_roles
[40] https://github.com/matatk/landmarks/releases
<Jan> 1.10.1 Show Related Elements: The user can access the
information from explicitly-defined relationships in the
content, including at least the following: (Level AA)
<Jan> (a) calculated accessible name for images
<Jan> (b) calculated accessible name for controls
<Jan> (c) caption for a table
<Jan> (d) row and column labels for a table cell
<Jan> 1.10.1 Show Related Elements: The user can access the
information from explicitly-defined relationships in the
content, including at least the following: (Level AA)(a)
calculated accessible name for images (b) calculated accessible
name for controls (e.g. form fields, buttons) (c) captions for
tables (d) row and column labels for table cells
<Jan> 1.10.1 Show Related Elements: The user can access the
information from explicitly-defined relationships in the
content, including at least the following: (Level AA)(a)
calculated accessible name for images (b) calculated accessible
name for controls (e.g. form fields, buttons) (c) captions for
tables (d) row and column labels for table cells [defn of using
calculated accessible name [41]http://www.w
[41] http://www.w/
<Jan> 3.org/TR/wai-aria/roles#textalternativecomputation]
<Jan> 1.10.1 Show Related Elements: Users can view the
information from explicitly-defined relationships in the
content, including at least the following: (Level AA)(a)
calculated accessible name for images (b) calculated accessible
name for controls (e.g. form fields, buttons) (c) captions for
tables (d) row and column labels for table cells
<Jan> 1.9.2 Source View:
<Jan> The user can view all source text that is available to
the user agent. (Level AAA)
<Jan> 1.10.1 Show Related Elements: Users can view information
from explicitly-defined relationships in the content, including
at least the following: (Level AA)(a) calculated accessible
name for images (b) calculated accessible name for controls
(e.g. form fields, buttons) (c) captions for tables (d) row and
column labels for table cells
RESOLUTION: 1.10.1 Show Related Elements: Users can view
information from explicitly-defined relationships in the
content, including at least the following: (Level AA)(a)
calculated accessible name for images (b) calculated accessible
name for controls (e.g. form fields, buttons) (c) captions for
tables (d) row and column labels for table cells
change 1.10.1, now is testable
<Jan> DEFN: calculated accessible name: The text equivalent
computation is the name or description that they then publish
through the accessibility API. {EXPLAIN why this is used}
assumes that UA will provide a UI for 1.10.1
<Jan> AllanJ, test
back from break
<scribe> ACTION: allanj to review duplicate items, make a
proposal [recorded in
[42]http://www.w3.org/2014/10/27-ua-minutes.html#action03]
<trackbot> Error finding 'allanj'. You can review and register
nicknames at <[43]http://www.w3.org/WAI/UA/tracker/users>.
[43] http://www.w3.org/WAI/UA/tracker/users%3E.
<scribe> ACTION: jallan to review duplicate items, make a
proposal [recorded in
[44]http://www.w3.org/2014/10/27-ua-minutes.html#action04]
<trackbot> Created ACTION-1042 - Review duplicate items, make a
proposal [on Jim Allan - due 2014-11-03].
at risk 2.2.2
[45]http://pic.dhe.ibm.com/infocenter/cities/v1r5m0/index.jsp?t
opic=%2Fcom.ibm.citieshelp.doc%2Fdoc_keyboard.html frame test
page
[45]
http://pic.dhe.ibm.com/infocenter/cities/v1r5m0/index.jsp?topic=%2Fcom.ibm.citieshelp.doc%2Fdoc_keyboard.html
<Jan>
[46]http://www-archive.mozilla.org/docs/end-user/moz_shortcuts.
html
[46] http://www-archive.mozilla.org/docs/end-user/moz_shortcuts.html
jr: what we really mean is sequential navigation between
containers of controls (UAUI, nav areas, iframe, frame, main
content area)
... is there something testable we can use, or make it only top
level and only navigate from tab to tab
<Jan> top-level viewport: A viewport that is not contained
within another viewport of a platform-based user agent.
Web-based user agents are always displayed inside another
viewport, and therefore are never top-level viewports. A
popular browser implementation is to provide a window that
includes some UA user interface elements (e.g., menus) and a
series of tabbed panels, each of which...
<Jan> ...contains additional UA user interface elements (e.g.,
address bar, bookmarks, back/forward buttons) and a top-level
viewport for rendering a view of the addressed web resource.
jr: get frame navigation. but we need to generalize. then how
is browser to recognize the myriad ways to make a 'viewport"
with or without scrollbars
<Jan> JR: [[[A B C] D E F [G H I]]]
<Jan> JR: Warping A D G
<Jan> 2.2.1 Sequential Navigation Between Elements: The user
can move the keyboard focus backwards and forwards through all
recognized enabled elements in the rendered content of the
current viewport. (Level A)
<Jan> 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)
<Jan> 2.2.2 Sequential Navigation Between Element Groupings:
The user can move the keyboard focus backwards and forwards
between at least one type of element groupings in the current
top-level viewport. (Level AA)
<Jan> 2.2.2 Sequential Navigation Between Element Groupings:
The user can move the keyboard focus backwards and forwards
between the first recognized enabled elements in certain
element groupings. (Level AA)
<Jan> 2.2.2 Sequential Navigation By Landmarks: The user can
move the keyboard focus backwards and forwards between a
recognized enabled elements marked by landmarks. (Level AA)
<Jan> 2.2.2 Sequential Navigation By Landmarks: The user can
move the keyboard focus backwards and forwards between
recognized enabled elements marked by landmarks. (Level AA)
<Jan> 2.2.2 Sequential Navigation By Landmarks: The user can
move the keyboard focus backwards and forwards between
recognized enabled elements marked by document landmarks.
(Level AA)
gl: are landmarks the same as frames or iframes
<Jan>
[47]http://www.w3.org/TR/wai-aria/roles#document_structure_role
s
[47] http://www.w3.org/TR/wai-aria/roles#document_structure_roles
<Jan> [48]http://www.w3.org/TR/wai-aria/roles#landmark_roles
[48] http://www.w3.org/TR/wai-aria/roles#landmark_roles
<Jan> 2.2.2 Sequential Navigation By Landmarks: The user can
move the keyboard focus backwards and forwards between
recognized enabled elements marked by document landmarks.
(Level AA)
<Jan> 2.2.2 Sequential Navigation By Landmarks: The user can
move the keyboard focus backwards and forwards between
recognized enabled elements in regions identified by document
landmarks. (Level AA)
<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)
kf: does this mean only aria landmarks. no browsers do this
ja; there are extensions that do this.
keyboard navigation between frames and iframes is broken across
most browsers
<Greg> [49]https://github.com/matatk/landmarks/releases
[49] https://github.com/matatk/landmarks/releases
<AllanJ> need to add an SC such that what the browser renders
is accessible, form place holder text fails contrast test.
Starting with completing 2.2.2 discussion tomorrow
<AllanJ> need to add an SC such that what the browser renders
is accessible, form place holder text fails contrast test.
Summary of Action Items
[NEW] ACTION: allanj to review duplicate items, make a proposal
[recorded in
[50]http://www.w3.org/2014/10/27-ua-minutes.html#action03]
[NEW] ACTION: jallan to review duplicate items, make a proposal
[recorded in
[51]http://www.w3.org/2014/10/27-ua-minutes.html#action04]
[NEW] ACTION: Jan to rewrite 1.3.2 to make testing easier
[recorded in
[52]http://www.w3.org/2014/10/27-ua-minutes.html#action02]
[NEW] ACTION: Jeanne to update the IER of 1.2.1 to reflect
removing the metadata component. [recorded in
[53]http://www.w3.org/2014/10/27-ua-minutes.html#action01]
[End of minutes]
__________________________________________________________
Received on Tuesday, 28 October 2014 00:29:57 UTC