W3C

- DRAFT -

HTML Accessibility Task Force Teleconference

21 May 2015

See also: IRC log

Attendees

Present
janina, Ivan, Liam, Plh, Cynthia_Shelly, Tzviya, LJWatson, SteveF, +1.617.319.aaaa, Mark, Judy, Rich_Schwerdtfeger, Joanmarie_Diggs, JF, +1.609.759.aabb, Michael_Cooper, Jason, ShaneM, mgarrish, paulc, Mike, [IPcaller], darobin, Sadecki
Regrets
Chair
Charles
Scribe
MarkS

Contents


<trackbot> Date: 21 May 2015

Identify Scribe http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List

<janina> Yes, thanks!

<janina> Thanks, Robin!

<richardschwerdtfeger> the link to the webex is not in the agena. please post it here

<janina> Rich, we're on Zakim 2119

<LJWatson> @Rich we're using zakim not WebX

<Judy> [JB: We are continuing to use Zakim for this call. There will be a practice session on WebEx following this call. The message about that was from Liam on the list earlier.]

<scribe> scribe: MarkS

Additional agenda?

PLH: Anything else to discuss today? in addition to ARIA

<richardschwerdtfeger> https://www.w3.org/WAI/PF/wiki/ARIAExtensions

Extended ARIA Roles Discussion https://www.w3.org/WAI/PF/wiki/ARIAExtensions

TS: several months ago, DPUB considered adding features to HTML that would improve accessibility in the context of digital publishing, much like DAISY does.
... data-* css, etc
... at TPAC, we decided to write an extension spec. during CFC for FPWD, there were many objections, so we are considering a different path. ARIA extensions
... semantic inflection for HTML

<janina> https://www.w3.org/WAI/PF/wiki/ARIAExtensions

RS: link for proposal to extend
... aria TF met and put this proposal together. it has been reviewed by PF. Mostly agreed with one exception
... if you are to write an extension for ARIA, it should not become part of the non-optional parts of ARIA. If a browser is fully compliant with 1.1, it will no longer be once an ext gets added
... what we want to say is that anything that goes into the core, must be compliant with Accessibility API mappings
... it would be a choice to implement them or not. The goal is to avoid breaking accessibility with these modules

<ShaneM> as I proposed last night, the text for point 4 could say "Any ARIA extension specifications that have reached Recommendation status at the time the ARIA Core is revised and approved as a superseding Recommendation will be considered to be a part of ARIA Core and their non-optional components required of all ARIA conforming implementations."

RS: formal mechanism, extending must come from existing taxonomy that you can inherit from. descendants of existing role of published spec, not WD

<scribe> ...new states must be coordinated with ARIA TF

UNKNOWN_SPEAKER: must have API mapping and does not break accessibility, doesn't have to be for accessibility, just not break it
... hyphenated role values acceptable dpub-glossary,
... create a normative api mapping spec
... demonstrate that it works with existing AT
... that would be the process
... ARIA is a cross connecting tech. Used for accessibility, but not limited to. allows for putting additional semantics into existing markup

<ivan> Current draft of the DPUB-ARIA terms

UNKNOWN_SPEAKER: valuable to CMS, epub readers, AT
... epub is mostly based on existing web/browser technology.
... should improve compatiblitliy

PLH: SteveF? You are working on mapping in HTML. Can you add to this?

SF: my concern appears to be partially resolved: prefixed roles.
... i think the existing solution is reasonable. would mitigate issues with collisions
... extension roles should have a prefix. that would be OK.

IH: two issues that came up in early discussions with DPUB. What we call hyphen space, separate of terms and the scope of what can be a value in the role attribute. this was fuzzy
... comments we received were against adding new terms, or that there would be collisions, etc.
... the number of terms we have is significant.
... those terms, as they are in DPUB are very important
... what happens if hyphen-namespace solution moves forward

TS: confused about what the method is for graduating terms from ext to ARIA spec
... suggest adding new terms after publication, and then a revision of aria core
... chapter for instance
... otherwise extension work has to be done in two places at once

RS: hyphen-space is designed to avoid collisions with terms that have been in there from the start. Should be able to name them as they want, but can't do that without namespaces
... If we're not in the middle of CR, we should have them available immediately, and get responses from community immediately
... important if we get the API mappings, we won't be breaking things. We don't want to define your space.

<Zakim> janina, you wanted to address in/out of scope issue

JS: some of the scope challenges that we haven't addressed yet is whether it is just accessibility or not. We're not restricting to AT use, but want to make sure new terms don't break accessibility.

<Zakim> ShaneM, you wanted to address adoption / requirement concerns and prefixing and to address tzviyas question about "graduating"

SM: extension mechanisms, and how they are made part of core (or not). prefixing, turned into not-prefixed, etc, changing the name is not as helpful as agreeing on terms that work for everyone.
... how we get things into core, the model I imagined was as ext are ratified, published, etc, they don't become a required part of ARIA 1.1 core, etc, but when next version comes out, the new term would be part of that spec.
... I think that is what implementers will care about

CS: I want to talk about ext. I like that model that was discussed. Also concerned about new terms in new specs. It can be harder to track. I conform to this, this, this, but not that, and that. etc.
... author can know what they could accomplish in that browser
... different than what Shane is saying. I imagined it to be more like CSS

PLH: We have a long history of using prefixes on the web, and I think long term, they don't work out.
... CSS for example
... implementation problems
... at the end of the day, what matters is what gets implemented. i would advise not to block on what should be part of core

LW: RE giving AT users ability to interact with DPUB. Too many roles could decrease accessibility if too many roles are introduced
... have we spoken to other implementers of ebook readers with their own screen readers to see if they would implement support for new roleS?
... that seems important

<ivan> EPUB Structural semantics

TS: the terms we have discussed come from IDPF and DAISY. So ebook publishers are plugged into these groups and are familiar with these terms

RS: IDPF, DAISY, Adobe, were all involved in EPUB, and accessibility was considered from the start

TS: we can reach out to other implementers

LW: I think it would be important to involve as many as possible.

<plh> ack Shaneack Shane

<Zakim> ShaneM, you wanted to ask cynthia about announcement

SM: Cynthia, you mentioned wanting extensions to be optional. If you have things that are optional, things that are portable need a mechanism to announce themselves

CS: I don't have anything in mind, but there are examples of support listings
... it needs to be deterministic.
... how does CSS do it?

PLH: they don't

<ShaneM_> I note that schema.org seems to resolve this well with prefixing

CS: I understand the market doesn't like prefixes, but certain terms have major conflicts with existing taxonomies.

<Zakim> SteveF, you wanted to ask PLH about aria-* prefixings success?

CS: prefixing would solve that problem

SF: Trying to understand the issue of having a prefix and then removing it when it gets moved to "core"

PLH: using x- causes problems. solution was to put everything behind a test flag

SF: we talked about attribute names/values/roles

<ShaneM_> +1 that it is a TOKEN!

SF: its a token, it doesn't need to represent what is exposed to the user, its just a token

<ivan> +1 to SteveF

SF: the concept of it becoming part of the core vocab could still include the hyphen or not

RB: I wanted to point out that these are 2 diff things. Using a prefix is probably fine, removing it later is a bad idea. What happens is that devs want to be future proof, so they will include both dpub-foo and foo

<Zakim> ShaneM_, you wanted to ask about core vocabulary and prefixes

RB: don't want to remove prefix. If the prefix moves to core, that is fine.

<richardschwerdtfeger> +1

SM: I agree with robin on that. we need to work out a mechanism for moving to core and what that means.

PLH: CSS doesn't have this problem. there is no CSS core

SM: CSS has graceful degradation,

<Zakim> liam, you wanted to wonder if we're going down a thorny path away from what AT should do, who is helped? schema.org only works because (1) money, (2) very limited in scope

SM: it would be disasterous, not inconvenient

LQ: similar to struggles in XML as well. Worry about defining all of these roles and nobody implementing them.

<ShaneM_> I disagree about the scope of schema.org. it is VAST

LQ: schema.org was mentioned, it is successful because it has limited scope. And there is financial incentive to adopt. Opposite for ARIA. If we make it more complicated, it might have adoption problems

<liam> [e.g. what happens if I introduce 300 prefixed terms?]

<SteveF> [e.g. what happens if I introduce 300 prefixed terms?] much better than 300 unprefixed terms

IH: We have to have a clear view of what it means to use new role values. If we have new terms and DPUB reading systems use those terms for things that are not strictly accessibility issues, i.e. glossary-item, there would be a pop-up (universally beneficial) .
... this is demonstration that it is useful for providing additional structure to document.

<ivan> +1 to richardschwerdtfeger

RS: I would encourage things like that. At IBM we use aria semantics to drive UI because we can tie it to CSS. Makes code more performant. We can work with designers to create UIs with more semantics.
... if there is value in adding other ways to include semantic info, that is a good thing

<tzviya> +1 to using ARIA to make code more performant

RS: this work was taken out of DAISY, which is proven. Powerful, time-saving features. Universally beneficial
... ask that normative API mapping is created, to not break anything. that is all

TS: Would love to do what IBM is doing in DPUB, but can't because ARIA doesn't do what we need currently.
... it will take time to implement, and we understand that we may need to include fallbacks during this time, glossary fallback to landmark for instance until support gets added. we have to start somewhere

CS: like with IBM is doing too. great thing to do when it works. RE API Mappings, there is a place to put the string that is in the role attribute. AT can get at it. several important platform API developers are involved. good chance that going through ARIA will result in getting implementations.

<joanie> +1 for adding API being easy in Linux

<Zakim> SteveF, you wanted to ask Cynthia_Shelly what the mechanism is to add abitrary role values in UIA?

CS: getting the APIs in sync with ARIA is not a difficult thing

SF: Cynthia, What is the mechanism for this? I think that works in IA2

CS: we have a similar method
... if there is something in the aria that we don't know how to map, there is a mechanism for getting at it.

RS: if we want to pull things into ARIA spec, I don't see why we can't have a mechanism for doing that. shouldn't get hung up on whether or not if has a prefix. Just want to say we don't want to ever remove a prefix if that is what was agreed on in the first place

<Zakim> janina, you wanted to ask about nonprefixed roles

JS: We should also discuss about the possibility of using non-prefixed terms. Want to keep this convo going. Concern that there are some terms proposed that are way too general and we do not want them in no-prefixed space. want to make sure that doesn't become a pattern.

<ShaneM_> +1 that some things will go in without prefixes

CS: we need to be careful with general purpose terms. checked/aria-checked for example.
... they behave differently and that is bad

<ShaneM> the checked thing is a state, not a role name

<ivan> FPWD: https://rawgit.com/w3c/aria/master/aria/dpub.html

<SteveF> +1 to ivan's proposal

IH: how about if we take the DPUB document, change it for each of the terms to hyphen space, then we publish as FPWD. IF during the discussion some should be general enough to move into ARIA 1.1, we can do it.

<ShaneM> +1 except not MOVED into aria 1.1. Named without a hyphen. Or possibly both. Some thigns are unprefixed but in the extension spec and not part of core immediately.

IH: very bad message if during dev of EPUB three there is a delay because of this

<tzviya> +1 Ivan's proposal

JB: anyone on the call that hasn't spoken up that would like to add something?

<Zakim> SteveF, you wanted to ask about role value prefixing

<richardschwerdtfeger> +1 to Ivan

JS: Not saying no, but I'm wondering if this is the best way forward, flagging the terms that have general applicability.
... i think in the past we have initially thought terms that were generally applicable were not.
... we may want to call them out in the beginning

<LJWatson> +1 to Ivan's suggestion of moving forward in hyphen-space.

IH: my proposal would be the other way around. Lots of concern about global or not. We define all in namespace by default. Then we can decide during publication process if any should be general non-prefixed terms

JF: This sounds like an XML namespace reprise. I think feedback from browser vendors would be very valuable here.

<SteveF> +1 to ivan

IH: we are hyphenating the values, different than XML

RS: I have to run this proposal through the ARIA TF. I will bring it up today on the call. I think this is a good way forward. We want to show support for moving forward.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/05/21 16:03:09 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/ARAI/ARIA/
Succeeded: s/not/no/
Found Scribe: MarkS
Inferring ScribeNick: MarkS
Default Present: janina, Ivan, Liam, Plh, Cynthia_Shelly, Tzviya, LJWatson, SteveF, +1.617.319.aaaa, Mark, Judy, Rich_Schwerdtfeger, Joanmarie_Diggs, JF, +1.609.759.aabb, Michael_Cooper, Jason, ShaneM, mgarrish, paulc, Mike, [IPcaller], darobin
Present: janina Ivan Liam Plh Cynthia_Shelly Tzviya LJWatson SteveF +1.617.319.aaaa Mark Judy Rich_Schwerdtfeger Joanmarie_Diggs JF +1.609.759.aabb Michael_Cooper Jason ShaneM mgarrish paulc Mike [IPcaller] darobin Sadecki
Found Date: 21 May 2015
Guessing minutes URL: http://www.w3.org/2015/05/21-html-a11y-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]