User Agent Accessibility Guidelines Working Group Teleconference -- 27 Oct 2014

<trackbot> Date: 27 October 2014

<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

what's implemented

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

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

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

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

at risk 2.2.2

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.

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

27 Oct 2014

Attendees

Contents