W3C

- DRAFT -

HTML Accessibility Task Force Teleconference

27 Jun 2013

See also: IRC log

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
MarkS

Contents


<trackbot> Date: 27 June 2013

RS: thing I'm having trouble understanding is that that spec is non-normative, so how do you know when you're done.

…the section on ARIA talks about elements that have native host language semantics in terms of ARIA markup. You shouldn't need to apply an ARIA role to that element because you already have the same semantics in that element. The accessibility API takes the same role ARIA would. mix and match elements, some with aria roles, some without.

JS: test whether proper roles are being transmitted to AAPI, and when ARIA roles are defined, the same role is being transmitted.

RS: need to do it for things as complicated as a tree widget.

…example. I will find one that matches with a widget

…need to test that keyboard focus actually works.

…probably can take ARIA test cases for that.

…i would take the ARIA test suite as much as you can.

… for canvas, need to make sure that the fallback content maps to AAPI

<chaals> [the question for now is just "is this actually interoperable, or does it need to be tested?"]

JS: haven't determined the state of testing for canvas yet, so we still have an opportunity to enforce the need for testing.

RS: they didn't state that the focus rectangles were at risk. need to test those.

…baseline support. two API's for drawing focus rectangle. a custom ring and system standard, so a dotted box. give it a path and it draws it.

…it is supposed to provide the location information and the fallback content in the AAPI. at the very least you can help a user follow focus.

…the other thing is the basic kit testing. marked at risk. doubt it will be in html5, most likely will be in html5.1 all ETS will be moving off of flash.

…Tables

JS: summary has been removed, there are problems with what has replaced it.

<janina_> Sorry. I can try my cell phone

<richardschwerdtfeger> please do

RS: if you put a summary attribute in the content, what happens?

…test that.

…make sure it is not mapped any longer.

JS: caption, markup technique was buggy. we think it should go away and be replaced by aria-describedby

RS: ARIA doesn't test any of the new controls that are in HTML5. Any specific tests that you want to apply to those?

JS: media controls. so much is left up to authors. been told its not going to be a problem because of API access.

…users should be able to override custom controls...

RS: how can you test the spec if non of your mappings are normative?

…caption?

JS: media source extensions. need to test this extensively. text described videos, color contrast of captions, etc.

…side by side sign language video

RS: video descriptions?

JS: definitely. including extended video description.

…don't have to be recorded audio, could be text format

RS: list of controls that are new. requirements for keyboard accessibility...

JS: no idea what that intersection is going to be.

RS: HTML5Accessibility site, firefox is ahead of most browsers. safari is good on mac. IE is used in govt, implementation is not good.

…what about content editable.

http://www.w3.org/html/wg/tests-cr-exit.html

http://www.w3.org/html/wg/tests-cr-exit.html

4.10.6, labels, no problem

keygen? non UI, right?

4.10.18, new enough, should be tested. seems like there would be issues.

RS: def need to test autocomplete when ARIA autocomplete metatdata is in the markup

4.12 links

RS: test keyboard navigation for links

MS: 4.12.5.5 link type icon? probably needs testing.

http://www.w3.org/TR/html5/Overview.html#contents

<richardschwerdtfeger> http://www.w3.org/TR/2012/CR-html5-20121217/dom.html#htmlelement

<richardschwerdtfeger> http://www.w3.org/TR/2012/CR-html5-20121217/editing.html#dom-tabindex

RS: in the HTML element IDL, if you look at the tabIndex that it links to in that IDL,

…"The tabIndex IDL attribute must reflect the value of the tabindex content attribute. Its default value is 0 for elements that are focusable and −1 for elements that are not focusable."

…however if you go to sequential focus if you have a value of -1 you can set focus on it with the focus method.

<richardschwerdtfeger> http://www.w3.org/TR/2012/CR-html5-20121217/editing.html#sequential-focus-navigation-and-the-tabindex-attribute

<richardschwerdtfeger> f the value is a negative integer

<richardschwerdtfeger> The user agent must set the element's tabindex focus flag, but should not allow the element to be reached using sequential focus navigation.

<richardschwerdtfeger> One valid reason to ignore the requirement that sequential focus navigation not allow the author to lead to the element would be if the user's only mechanism for moving the focus is sequential focus navigation. For instance, a keyboard-only user would be unable to click on a text field with a negative tabindex, so that user's user agent would be well justified in allowing the user to tab to the control regardless.

…bottom line is if you have a tab index of -1 you can call focus and it will give it focus. if you can do that, it means its focusable. so if default values are set to -1 it is focusable, contrary to spec language

…have to call the focus method to give it focus, programatically.

…need to clarify this. not sure who is using it.

MS: 4.13 we should take a closer look to see if they are using accessible techniques.

RS: 6.1 Scripting has been around forever. should be fine.

<chaals> [4.13.1 changed, we have <main>]

<chaals> [4.13.2 breadcrumbs just uses links and punctuation… effectively OK]

7 User Interaction

RS: keyboard navigation. when you tab and land into fallback content, that you are getting focus on elements in the fallback content. What happens if you put a widget in the fall back content??

<chaals> [4.13.3 tag clouds: not so sure that font-size is interoperable. People use minimum-font-size which would blow it away]

RS: once you have focus it should respond to keyboard input.

section 10 Rendering

<chaals> [4.13.4 conversations: this is just an acknowledgement that html doesn't work well for this. Not sure how interoperable the examples are. I don't think they are particularly clear and I would appreciate someone else looking over them]

RS: CSS produced content, is it accessible?

MS: content directives are not accessible.

<chaals> [4.13.5 footnotes (make a link) looks bascially OK]

<chaals> CSS content isn't interoperably accessibile as far as I know.

<chaals> some browsers made it available (e.g. Opera pre-blink) but I think most didn't and argued that wasn't a bug.

RS: you want to test contenteditable and designmode.
... canvas shape support needs to be added to 5.1

…one stop shopping for APIs. more ARIA

…implement dialog box in 5.1

…makes things easier for authors.

scribe: they would get keyboard navigation sequence right

…managing focus

…make sure contenteditable works better.

…IndieUI is extremely important.

…taxonomies for SVG

JS: canvas editing

RS: i think that got moved to .next
... use existing testing for ARIA. The rest of the stuff, I think you should test.

<chaals> [inert subtrees is OK? I don't know, but I'd like to hear someone say yes because they do know]

http://www.w3.org/TR/html5/editing.html#inert-subtrees

RS: anything that is hidden is inert. this is hidden content. been around for a long time. however, the hidden attribute, IE 10 doesn't support it. so it should be tested.

…another form of inert is a modal dialog box. keyboard navigation should not go to anything below that dialog box.

…should also mean that you cannot do a programmatic click on those things either.

…test the javascript access to those elements as well.

…if its hidden, it can't be mapped to the AAPI

<richardschwerdtfeger> one problem is that IE does not implement the hidden attribute in IE10. So technically that content should be inert but it is not

<richardschwerdtfeger> also, inert content should not be in the keyboard navigation order, should not respond to click() focus() or blur()

RS: the mapping API is not going to get tested because its not normative.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013/06/27 19:29:38 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/def/RS: def/
Succeeded: s/linotype/link type/
Succeeded: s/hover/however/
No ScribeNick specified.  Guessing ScribeNick: MarkS
Inferring Scribes: MarkS

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: JS Janina MS MarkS P1 P16 RS Rich_Schwerdtfeger chaals html-a11y-test janina_ joined richardschwerdtfeger trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 27 Jun 2013
Guessing minutes URL: http://www.w3.org/2013/06/27-html-a11y-test-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


[End of scribe.perl diagnostic output]