User Agent Accessibility Guidelines Working Group Teleconference -- 03 Jul 2014

<trackbot> Date: 03 July 2014

<allanj> scribe: allanj

<kford> scribe: kford

Face to Face at TPAC

F2F at TPAC

<allanj> js: is a go, please register

JS: F2F is a go. If you want W3C help get your estimates and requests in.

<allanj> ... we can start on Sunday, thanks to Adobe

JS: Adobe giving us an extra day of office space if we want to start on Sunday.

Event would be starting Sun Oct 26.

<allanj> https://www.regonline.com/builder/site/Default.aspx?EventID=1574227

<allanj> http://www.w3.org/2014/11/TPAC/

document comments

JA: Let's take up some of these proposals.

propose applicability note

<allanj> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014AprJun/0066.html

<allanj> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014AprJun/0069.html

<allanj> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014AprJun/0073.html

<allanj> js, jr, gl +1

I am good with this too.

<allanj> ja, kp +1

<jeanne> ACTION: Jeanne to add new conformance applicability notes from http://lists.w3.org/Archives/Public/w3c-wai-ua/2014AprJun/0069.html [recorded in http://www.w3.org/2014/07/03-ua-minutes.html#action01]

<trackbot> Created ACTION-989 - Add new conformance applicability notes from http://lists.w3.org/archives/public/w3c-wai-ua/2014aprjun/0069.html [on Jeanne F Spellman - due 2014-07-10].

RESOLUTION: Accept the text of the second link form Jim 0069.html

1.4 proposal

<allanj> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014AprJun/0075.html

<allanj> 1.4.1 +1

<allanj> close action-979

<trackbot> Closed action-979.

<allanj> all Ok

1.4.2

JS going over changes in proposal.

<allanj> +1

<jeanne> Font family, choosing from at least all platform fonts

<jeanne> +1

<Greg> The phrase "Font family, choosing from all platform fonts", we don't want to imply they can't choose from other, UA-provided or downloaded-on-demand fonts.

<jeanne> ACTION: jeanne to make changes to 1.4.1 and 1.4.2 adding "at least" all platform fonts to 1.4.2 [recorded in http://www.w3.org/2014/07/03-ua-minutes.html#action02]

<trackbot> Created ACTION-990 - Make changes to 1.4.1 and 1.4.2 adding "at least" all platform fonts to 1.4.2 [on Jeanne F Spellman - due 2014-07-10].

RESOLUTION: Proposal for 1.4 changes accepted http://lists.w3.org/Archives/Public/w3c-wai-ua/2014AprJun/0075.html

1.4.3

<allanj> proposed:

<allanj> 1.4.3 Text Blocks (Globally): The user can globally set all of the

<allanj> following characteristics of visually rendered blocks of text: (Level AA)

<allanj> * Character spacing, choosing from a range with at least five values

<allanj> * Justification (left, right, or full)

<allanj> * Margins around blocks of text

<allanj> UAWG Note: Probably need definition of Blocks of text

<allanj> UAWG Note: add Wayne's recommendation of the range (MIN 0.02 to MAX 0.1

<allanj> of the base character width) to Implementing Intent section.

<allanj> js: need definition of 'blocks of text'

<Greg> Justification (left or right, including turning off full justification)

<jeanne> ACTION: jeanne to implement changes to 1.4.3 as per 2014AprJun/0075.html changing Justification to Justification (left or right, including turning off full justification). [recorded in http://www.w3.org/2014/07/03-ua-minutes.html#action03]

<trackbot> Created ACTION-991 - Implement changes to 1.4.3 as per 2014aprjun/0075.html changing justification to justification (left or right, including turning off full justification). [on Jeanne F Spellman - due 2014-07-10].

<Greg> I'd like to clarify somewhere that by "left, right, or full" that we mean the user can turn those off, not just turn them on, and thus can avoid full justification.

<Greg> I certainly don't want a UA to feel compelled to implement full justification because our wording was sloppy and made it sound like it was required, and I want to make sure that users can turn full justification off.

group talking about what's been done with othyer changes and where we stand.

<jeanne> ACTION: jeanne to write definition of blocks of text [recorded in http://www.w3.org/2014/07/03-ua-minutes.html#action04]

<trackbot> Created ACTION-992 - Write definition of blocks of text [on Jeanne F Spellman - due 2014-07-10].

<Greg> Sort of weird that we ended up requiring link text size to be adjustable, just because of how we lumped it in with headings and input fields.

1.4.5

JS again talks about what was changed. Not scribing every little change. It is in the document.

<allanj> proposed:

<jeanne> Advanced text formatting (by Element): The user can set all of the

<jeanne> following characteristics of visually rendered text content [for main

<jeanne> text] and for text element types including at least headings, input

<jeanne> fields and links: (Level AAA) - delete for main text

<allanj> 1.4.6 Advanced text formatting (by Element): The user can set all of the following characteristics of visually rendered text content for text element types including at least headings, input fields and links: (Level AAA)

<allanj> * Text style (underline, italic, bold)

<allanj> * Borders

<jeanne> text style is covered under 1.4.2

<allanj> remove 1.4.6 because it is just borders?

JA: We said throughout text styles becuase that was covered in 142 and what do others think?
... Do we have objections to removing 1.4.5.

GL going over what is left to be covvered by 1.4.5.

GL talking about active input fields and how do we make those easy?

JS: do we cover those under 1.3.1?

JA: Yes.

<Greg> 1.4.5 is left being only borders for headings, input fields, and links. My concern was providing some way to make text input fields easy to find on the page, and borders are one method of that, particularly if something was using the old Solaris (I think) style where input fields were marked only with underlines. But yes, 1.3.1 might handle that well enough.

JS: Going to add a note to 1.4.6 to say highlighting borders covered in 1.3.1.

<Greg> Borders is 1.3.2 which is AA, but that's no lower than 1.4.5 was.

RESOLUTION: group dropping 1.4.5 because we have it covered elsewhere

1.4.6

<allanj> proposed:1.4.6 Advanced text formatting (Globally): The user can globally set all of the following characteristics of visually rendered blocks of text: (Level AAA)

<allanj> * Text style (underline, italic, bold)

<allanj> * Capitalization (overriding upper case and small caps style)

<allanj> * Word-breaking properties (auto-hyphenation)

<allanj> * Borders

<jeanne> * Word-breaking properties (auto-hyphenation, on and off)

<Greg> We need to be consistent about saying "on and off": always say it or never, so that we don't imply a meaningful difference between when we do and when we don't.

<jeanne> GL: I think we add inconsistency in saying on and off.

JA: After discussion we are back to proposed 1.4.6. Any objections?

<Greg> Do we want the user to be able to control all forms of word-breaking (e.g. soft hypen characters), or just auto-hyphenation?

<allanj> scribe: allanj

<Greg> We should probably either say "Word-breaking properties (e.g. optional hyphen characters, auto-hyphenation)" or merely "Auto-hyphenation".

<Greg> Word is an example of a UA that allows the user to turn auto-hyphenation on and off.

<Greg> Just to be clear, if we go with "Word-breaking properties (e.g. auto-hyphenation)" then we're requiring UA to let the user turn off rendering of soft hyphen characters (at AAA).

<jeanne> ACTION: jeanne to add the proposed 1.4.6 from /2014AprJun/0075.html with word breaking "Word-breaking properties (e.g. Auto-hypenation) [recorded in http://www.w3.org/2014/07/03-ua-minutes.html#action05]

<trackbot> Created ACTION-993 - Add the proposed 1.4.6 from /2014aprjun/0075.html with word breaking "word-breaking properties (e.g. auto-hypenation) [on Jeanne F Spellman - due 2014-07-10].

RESOLUTION: Accept 1.4.6 (to be renumbered) with Word-breaking properties (e.g. auto-hyphenation)

<jeanne> ACTION: jeanne to remove 1.4.5 and renumber 1.4.6 [recorded in http://www.w3.org/2014/07/03-ua-minutes.html#action06]

<trackbot> Created ACTION-994 - Remove 1.4.5 and renumber 1.4.6 [on Jeanne F Spellman - due 2014-07-10].

1.10.1

http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JulSep/0003.html

jr: I wonder if perhaps we need concrete use cases might help us clarify to the fundamental issue here.

gl: using 'labels' twice to mean different things

1.10.1 Show Adjacent and Related Text: The *user agent* presents text for at least the following element relationships: (Level AA)

- adjacent form control labels

- table cell headings

- elements explicitly related in the html

gl: use case - in a table cell, being able to show the related column and row headers is useful

<jeanne> Courtney has a cognitive disability that makes it difficult for her to comprehend complex user interfaces. She is completing an online job application. It is not clear where she should enter her phone number, because not all the the input fields have text labels. She mouses over a blank box and sees a tooltip that says "home phone number". She is able to complete the form.

gl: focus on a form field, hit a key to show the name of the field

<Greg> I'd rewrite the second example to make it clearer what is making the label non-obvious, e.g. labels above, below, and to the left of the current input field.

<jeanne> Courtney has a cognitive disability that makes it difficult for her to comprehend complex user interfaces. She is completing an online job application. It is not clear where she should enter her phone number, because the input fields have text labels labels above, below, and to the left of the current input field. She mouses over the blank box and sees a tooltip that says "home phone number". She

<jeanne> is able to complete the form.

<Greg> In WD-UAAG20-20080312 it read:

<Greg> 3.4.2 Access Relationships: The user can access information from explicitly-defined relationships in the content (e.g., what is form control's label?, what is label's form control?, what is cell's table header?, etc.). @@Expanded 10.1 in UAAG10@@

<Greg> That was a lot clearer than the current version, in my opinion.

<Greg> Jan Richards jan.richards@utoronto.ca Date: Thu, 07 Feb 2008 11:45:10 -0500 (http://lists.w3.org/Archives/Public/w3c-wai-ua/2008JanMar/0034.html):

<Greg> 2. Allow the user to access information from explicitly-defined relationships in the content (e.g., label, description, table header, etc.).

<Greg> By WD-UAAG20-20090311 It read:

<Greg> 3.3.1 Access Relationships: Provide access to explicitly-defined relationships based on the user's position in content (e.g., show form control's label, show label's form control, show a cell's table headers, etc.). (Level A)

<Greg> Today:

<Greg> 1.10.1 Show Related Elements: The user can access related elements based on the user's position in content (e.g. show the label of a form control, show the headers of a table cell). (Level AA)

js: use can access explicitly-defined relationships based on position in content

gl: this is way to broad. which relationships are required?

<jeanne> 1.10.1 Show Related Elements: The user can access explicitly related elements based on the user's position in content (e.g. show the label of a form control, show the headers of a table cell). (Level AA)

ja: forms, tables, aria-describedby, aria-etc
... what should not be exposed?

<Greg> The problem with the March 2008 wording is that it's too broad: we don't want to require exposing all explicitly-defined relationships, because there's a HUGE, potentially unlimited number of them, but we also don't want the UA to be able to comply by only exposing one.

gl: what heading is this paragraph under...defined in markup
... figcaption, legend, and there are more
... explicitly defined relationships are the entire document, named anchors

js: what if we make a list, at least:

1.10.1 Show Related Elements: The user can access explicitly related elements based on the user's position in content for at least the following:

form labels

table cell headings

aria-describedby

aria-labeledby

legend (fieldset)

figcaption (figure)

caption (table)

<Greg> Access Relationships: The user can access information from explicitly-defined relationships in the content, including at least the following: label for a control or image; row and column labels and number for a table cell...

<Greg> The user can access information from explicitly-defined relationships in the content, including at least the following: label for a control or image (e.g. @figcaption for an image, @caption for a table); row and column labels and number for a table cell...

number for a table cell perhaps location (cell coordinates - row X, column Y)

js: what is the a11y need of coordinates?

gl: magnification, when you can only see 1 cell, helps with context.

kp: helps with mental map

js: lot of work for calculating context for dynamic, complex, merged tables

gl: trying to solve the what if you don't have a label to fall back on

<Greg> I know from interacting with coworkers who cannot see a whole table that getting the row and column names/numbers when labels are unavailable was useful, but I won't fight to add it, especially here as it doesn't really fit the current title of the SC.

kp: in excel have lots of problems locateing self and navigate with speech. knowing location context would be useful

js: sounds like a new SC

gl: to find the label of row and column headers they already have to calculate the location

js: don't want to add new things

<Greg> Jeanne's point is valid that it could be tricky to figure out which labels to read, if the table is complex with a lot of merged cells, header groups, etc. That's true whether we're asking them to present labels or numbers.

js: even if it is a perception of more work.

<jeanne> Access Relationships: The user can access information from explicitly-defined relationships in the content, including at least the following: label for a control or image; row and column labels and number for a table cell...

<scribe> ACTION: greg to recraft 1.10.1 based on today's discussion [recorded in http://www.w3.org/2014/07/03-ua-minutes.html#action07]

<trackbot> Created ACTION-995 - Recraft 1.10.1 based on today's discussion [on Greg Lowney - due 2014-07-10].

regrets for next week, kim and jeanne

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

03 Jul 2014

Attendees

Contents