See also: IRC log
<trackbot> Date: 27 October 2014
http://jspellman.github.io/UAAG-LC-Comment/
<jeanne> http://www.w3.org/WAI/UA/2014/F2Fagenda20141027
tests: https://www.w3.org/WAI/UA/work/wiki/Tests_for_CR#Principle_1:_Perceivable
<Greg> OK
<kford> 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
desktop - V
desktop - 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
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> 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
http://www.w3.org/WAI/demos/bad/after/survey.html
<Jan> http://www.w3.org/WAI/
<Jan> http://www.w3.org/
<Greg> 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> http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed.html
<jeanne> 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 -> https://twitter.com/rodneyrehm/status/526655289643515904
<clapierre> FireFox 33.0.1 Mac 1-6 tests Pass
https://www.w3.org/WAI/UA/work/wiki/1.3.2
<Jan> http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed.html
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/att-0027/form2.htm
<jeanne> 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
<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> https://www.w3.org/WAI/UA/work/wiki/Tests_for_CR
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> 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)
<jeanne> ACTION: Jeanne to update the IER of 1.2.1 to reflect removing the metadata component. [recorded in 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.
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 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).
<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> http://www.w3.org/WAI/GL/wiki/Using_ARIA_landmarks_to_identify_regions_of_a_page
aria landmark roles 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.
<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> http://www.w3.org/TR/wai-aria/roles#textalternativecomputation
<clapierre> There is the Firefox extension for navigating Aria Landmarks. http://www.w3.org/TR/wai-aria/roles#landmark_roles The actual download of the extension is 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 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 http://www.w3.org/2014/10/27-ua-minutes.html#action03]
<trackbot> Error finding 'allanj'. You can review and register nicknames at <http://www.w3.org/WAI/UA/tracker/users>.
<scribe> ACTION: jallan to review duplicate items, make a proposal [recorded in 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].
http://pic.dhe.ibm.com/infocenter/cities/v1r5m0/index.jsp?topic=%2Fcom.ibm.citieshelp.doc%2Fdoc_keyboard.html frame test page
<Jan> 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> http://www.w3.org/TR/wai-aria/roles#document_structure_roles
<Jan> 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> 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.
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/1.9.9/1.9.1/ Succeeded: s/ keyboard between frames and iframes navigation is broken across most browsers/ keyboard navigation between frames and iframes is broken across most browsers/ Found Scribe: allanj Inferring ScribeNick: AllanJ Present: Kim Jim Jeanne Jan Kelly Greg Charles_LaPierre(Benetech) Agenda: http://www.w3.org/WAI/UA/2014/F2Fagenda20141027 Found Date: 27 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/27-ua-minutes.html People with action items: allanj jallan jan jeanne[End of scribe.perl diagnostic output]