See also: IRC log
<trackbot> Date: 18 June 2015
<richardschwerdtfeger> chair: Rich
<richardschwerdtfeger> Meeting: W3C WAI-PF ARIA Caucus
<janina_> I will need to leave about 15 minutes early
<scribe> scribe: fesch
rs: need to hear from several
publishers by August, otherwise we will remove
describedat
... dpub is looking at alternatives, and have longdesc, may not
be an issue
... it is mid year, lets get stuff knocked out... if we don't
get stuff finalized in ARIA 1.1 may be moved to ARIA 2.0
<JF> Just want to note there is discussion about aria-describedat as an HTML5 bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18385
rs: already done a great job, on getting misconnects with HTML in ARIA 1.1, group has done a heck of a good job
<clown> issue-691?
<trackbot> issue-691 -- Proposal to extend the support of aria-orientation -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/691
<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/issues/691
rs: Bryan gave a list of roles he would like, all roles are there, action should be complete
RESOLUTION: Close issue 691 as complete
<MichaelC> close issue-691
<trackbot> Closed issue-691.
<clown> http://w3c.github.io/aria/aria/aria.html#aria-orientation
<clown> ?
jn: which version of the spec are you looking at?
rs: looking at rawgit version.
issue-683?
<trackbot> issue-683 -- The aria-level attribute is not required for role=heading within the spec, but should be. -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/683
issue-698
<trackbot> issue-698 -- Elements with "None" Instrinsic Host Language Semantics with ARIA relationship and/or tabidex applied -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/698
rs: how can you have a heading without a level? We can make this a required attribute.
lw: if you have a heading without a level something bizarre happens - not good
jn: it might be a valid thing, right?
jf: not
issue 698 closed as a duplicate of 683.
jf: does that map to a MUST?
rs: yes
<Zakim> JF, you wanted to ask if adding a level should be a SHOULD or MUST?
<richardschwerdtfeger> ACTION: Joanie make aria-level a required attribute for role=“heading” [recorded in http://www.w3.org/2015/06/18-aria-minutes.html#action01]
<trackbot> Created ACTION-1657 - Make aria-level a required attribute for role=“heading” [on Joanmarie Diggs - due 2015-06-25].
<clown> action-1657
<trackbot> action-1657 -- Joanmarie Diggs to Make aria-level a required attribute for role=“heading” -- due 2015-06-25 -- OPEN
<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1657
js: what happens when it doesn't have a level? right now it defaults to 1
jf: even if you don't know what the level is, knowing it is a heading is still useful, even though incomplete
jn: you will make existing things
- non conforming,
... it could be you don't know the level and it could be really
hard....
rs: what do you do?
jn: we take a best guess, better to mark as a heading and get the level wrong than not marking as a heading at all
<JF> +1 to the idea that knowing it is a heading is important, whether or not the level is declared
lw: can't find the bug, but testing a heading without a level defaulted to level 2.
bg: what I hear is heading,
(without a level)
... the problem is it ruins the document structure - if you are
trying to build out a tree, it is broken
rs: we should require the level, even if it is out of sync...
jn: if there is only one heading on a page, then does it matter?
lw: but if it is a level 3 it may not make any sense
jf: true, but if you know it is a heading, you know you have a heading rather than nothing
lw: in FireFox no level appears to default to level 2. And you hear heading with no level information
rs: in HTML can you have a heading without a level? Lets be consistent with HTML
jn: There may be a reason why
they aren't putting level information...
... I think requiring a level in HTML is stupid... And that was
why they were trying to calculate it for you
... I have people come to me and ask, I don't know what the
level is... I don't think we should force people to put in the
wrong information rather than no information
rs: I think you are better off putting them in regional landmarks, rather than try to bring in heading levels when pulling in parts from external parts
jf: Rich, you made the argument for not trying to keep the level, it makes more sense to provide the level if you know it, but not if you don't
bg: if the argument is don't put a level if it is wrong, then you will get a (default) which will be wrong anyway
rs: the person that wrote the app- you pull in needs to keep a consistent heading levels, I don't think it makes sense to try and keep the whole page in sync...
jf: ... more arguments for not
wanting to require a level...
... a missing level is not wrong, it is incomplete
rs: so you can put heading without a level, on every heading... and that would be OK
jf: If you can provide the level, you should, but there are times when you can't or you would provide wrong information - about how important it is - SHOULD vs MUST
rs: If we don't mandate a level, a tool won't flag it. Then when we sell to a government agency then they will be unhappy
lw: the two screen reader users think a level is important
bg: A screen reader will add a level to create the tree
jn: then it is a bug in the
screen reader
... is there a big problem where if we don't require it, they
won't do it? Do we see headings without levels in the
wild?
... uncomfortable to tell to put in a heading with a unknown
level, it is more important to have the heading...
... I tell developers - take you best guess at level... so if
it is not required, then they can use a heading...
js: when you imbed it in
something else, then within the widget itself, it needs to be
consistent...
... then the user agent should transform it to be consistent in
the tree
jf: how many H1 can you have on a
page?
... If you have a component, someone suggested they should
start at H2, maybe they should start at H3... we don't know
lw: better than making them not try at all
jf: I'm with James, better to be accurate and incomplete, than provide wrong information...
rs: user agent takes content and tries to expose it, that's it.... concerned that it is consistent within the section....
jf: what about the 3rd party
rs: the 3rd party is responsible for that
jn: I think you are forcing the developer to provide bad information, will defer to group
rs: we can vote....
<janina_> +1
<jongund> 1+
<jamesn> -1
<JF> -1
<richardschwerdtfeger> +1
<LJWatson> +1
<richardschwerdtfeger> Who wants to have aria-level required property for role=“heading”
<bgaraventa1979> +1 for consistency
<richardschwerdtfeger> +1
<janina_> +1
<LJWatson> +1
<JF> -1
<jamesn> -1
<jongund> +1
<richardschwerdtfeger> Who Wants aria-level to not be required for role=“heading”?
<janina_> -1
<LJWatson> -1
<richardschwerdtfeger> -1
jf: I think the topic needs more discussion, then later use a survey
mc: I think we are not ready for decision making
rs: you get a SHOULD by having a supported property..
jf & jn: NO
jn: We should have SHOULD not MUST...
<JF> Related: http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.5.
rs: made a topic, sending email for feedback on list...
jf: this goes back to XHTML2... with an H element...
rs: I think this should be computed, but you can't...
js: lets take a poll
issue-702
<trackbot> issue-702 -- The ARIA Roles Model spec states that keyboard support for interactive widgets is optional, not required, which it should be. -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/702
Topic issue 702
<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/issues/702
<richardschwerdtfeger> http://www.w3.org/TR/wai-aria-1.1/#managingfocus
rs: do we want to change this or not?
jn: If I am doing a different version for iOS then I should not have to support a keyboard
rs: so you are providing alternate support
jn: if no one is going to use it, why should we have to do it?
rs: we require it, because some
people use keyboards, and you are seeing more support for
keyboards
... maybe we deal with this in ARIA 2.0, when you have gaps,
then we have to provide alternate mechanism,
... we can move this to ARIA 2.0 issue
RESOLUTION: move to ARIA 2.0 issue
rs: waiting for mobile infrastructure
<clown> agenda: https://lists.w3.org/Archives/Public/public-pfwg/2015Jun/0073.html
<clown> issue-697
<trackbot> issue-697 -- Remove "frameset" reference from the definition of Root WAI-ARIA node -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/697
issue-697
<trackbot> issue-697 -- Remove "frameset" reference from the definition of Root WAI-ARIA node -- open
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/697
Topic issue 697
rs: I think frameset should be removed the glossary
<clown> http://w3c.github.io/aria/aria/aria.html#dfn-role
rs: have you put roles on a frame set <frameset??
jn: no
rs: we only have one app that use frameset
jn: it is fine to drop it, since it is valid on a frameset so we are not confusing anyone...
rs: this is in the glossary, so it is not normative
jn: I don't have a problem changing it, since it will remove confusion
<JF> http://www.w3.org/TR/html5/obsolete.html
rs: I think we can take it out of it
RESOLUTION: give Joseph an action to remove.
<richardschwerdtfeger> ACTION: Joseph remove the reference to “or <frameset>” from the role definition in the glossary. [recorded in http://www.w3.org/2015/06/18-aria-minutes.html#action02]
<trackbot> Created ACTION-1658 - Remove the reference to “or <frameset>” from the role definition in the glossary. [on Joseph Scheuhammer - due 2015-06-25].
js: contemplates the state definition...
issue-651
<trackbot> issue-651 -- Allow aria-invalid to specify more types of errors including custom errors -- raised
<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/651
<clown> http://w3c.github.io/aria/aria/aria.html#aria-invalid
<richardschwerdtfeger> http://w3c.github.io/aria/aria/aria.html#aria-invalid
jn: I want to be able to have a message read out by a screen reader immediately
rs: I wonder how to do this
effectively....
... could point to it with describedby
jn: we use describedby for lots of things, then if this error has a condition x, then the describedby could provide...
rs: aren't these things often popups?
jn: yes
rs: do you tie them to
role=alert
... that may be a problem
jn: some popups may have a role
of alert, but that shouldn't matter
... I want the AT to know that this is an error message
associated with this field...
rs: if you put a role of alert and you can't use descirbedby
jn: you could put multiple things in describedby and you need to tell AT which is information and which is the error message
rs: you could
jn: shouldn't be required...
rs: you can have one descirbedby with multiple ids, then they get concatenated together, then if one was an error message... then ...
js: sounds like we need another
relation... error message for.... something like that, the mac
makes a string
... UIA has a describedby property...
rs: I don't know how much work it
is for apple to add an error relationship, wouldn't be that
bad, have to separate help and error...
... describedby is usually used for help information, if there
was an error, we put role=error on the target...
... you could put a role=error on the target, problem is you
often put an error inside an alert...
jn: not sure I like using a role
on that...
... need people that know accessibility API to explain how that
would be exposed
rs: I can try to put something
out on the list about error messages
... do we want to overload the description
jn: that is the problem, do we have anything else?
js: do we have an error or error msg in the accessibility APIs? They may exist...
jn: can you have a property?
js: try something like this'''
<clown> <input aria-describedby="tooltip ID" aria-errormessage="errorID">
rs: yes, that is what we were talking about before
js: that tooltip id will point to
some text... it will also contain a describedby... but you can
still build the string and stick it in the object
... so it is ARIA 2?
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/REQUIRED/MUST/ Succeeded: s/this goes back to HTML 2/ this goes back to XHTML2/ Succeeded: s/<frame> <iframe>/<frameset?/ Found Scribe: fesch Inferring ScribeNick: fesch Present: LJWatson Janina Rich Fred Joseph_Scheuhammer Bryan_Garaventa JF James_Nurthen MichaelC Jon_Gunderson Regrets: Cynthia Agenda: https://lists.w3.org/Archives/Public/public-pfwg/2015Jun/0073.html Found Date: 18 Jun 2015 Guessing minutes URL: http://www.w3.org/2015/06/18-aria-minutes.html People with action items: joanie joseph WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]