W3C

Protocols and Formats Working Group Teleconference
26 Sep 2014

Attendees

Present
Joseph_Scheuhammer, Michael_Cooper, Rich_Schwerdtfeger, Steve_Faulkner
Regrets
Chair
Joseph_Scheuhammer
Scribe
MichaelC

Contents


<trackbot> Date: 26 September 2014

<richardschwerdtfeger> scribe: MichaelC

<richardschwerdtfeger> meeting: ARIA Editors on Accessible Name Computation

<clown> http://rawgit.com/w3c/aria/master/accessiblename/accName.html

rs: doc on github for name and description?

<clown> https://github.com/w3c/aria/commits/master/accessiblename

clown: ^

have been doing a bunch of stuff with it

rs: input from cynthia?

clown: no, hasn´t been at AAPI meetings

due to work conflicts

I´ve added introduction (still room for improvement)

in algorithm, have removed references to HTML or made clearly example or added equivalent SVG ref

rs: got input from from JamesC

ARIA takes precedence

then you drop to native host features to compute name / desc

need to refer to host language specs for those

sounds logical?

clown: to paraphrase

after core a11y computation

there would be a section on changes due to [HTML | host language]

rs: Steve was trying to simplify

authors having a hard time

clown: but not for authors

rs: yeah, but...

clown: do need author guidance somewhere

<SteveF> http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#accessible-name-and-description-calculation

sf: my simplification wasn´t for authors, was based on implementer feedback

if you have aria or aria-label, use name computation

otherwise use x-and-such in a particular order

the attributes and order is pretty much how it´s implemented based on my testing

clown: which user agents?

sf: the four majors

most of it is pretty standard, though a few differences

need to do more testing and documentation

placeholders still problematic

clown: still exist

sf: yah-huh

widespread

rs: know why people don´t want it, but on mobile authors will frequently prefer it

throwing label off screen doesn´t help sighted people

clown: sometimes it´s more guidance than label, such as ¨put stuff here¨

anyway, it´s low in precedence list

sf: yes, based on my testing

rs: I bet labelledby and label will be consistent

then you get into specific elements

SVG doesn´t have that because they don´t have form controls

though they have title and desc descendant elements

<SteveF> http://www.html5accessibility.com/tests/placeholder-labelling.html

if we cover this in the main spec

then we have to get into the recursion with labelledby

in SF doc, see it´s under each element

can it be in its own section?

sf: ?

rs: oh, I see, it is under a name and description section

Ok, so that seems to be the break-down

first aria-labelledby, and talk about concatenation process

Another wrinkle is CSS ::before and ::after

doesn´t work in SVG

clown: I´ve addressed already

doesn´t work on elements w/o a content model

e.g., doesn´t work on <img>

might be why it doesn´t work in SVG

so my spec wording uses that assumption

of course, possible it´s just an imcomplete implementation issue

So, if it turns out it works only with HTML

so put in HTML spec?

what if other techs later implement?

mc: we can move which spec it´s in at that time

clown: <concatenation algorithm>

rs: So, there are two things to do

tell people about name computation - authoring practices?

<clown> http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#mapping_special_te

clown: ^ is very first published version of the algorithm

it´s similar to what Steve recently did

would like to take the current version and put it more like that style

rs: that´s fine

plus section for host languages

sounds reasonable?

sf: at quick glance looks good

want to look more closely

clown: want to take the best of that style with the best of the current algorithm and smoosh them together

sf: let´s set up some test cases to see what´s actually being done

find common ground areas, and file bugs against implementations to steer towards a common denominator

then document that

rs: so where we refer to the algorithm

add a step for the native host language

<SteveF> Accessibility for Docs editors https://support.google.com/docs/topic/6039805?hl=en&ref_topic=1382883

<SteveF> any of those docs "If you're using NVDA, we recommend using Mozilla Firefox as your browser."

MC, what is status of repository?

mc: have been waiting on Jason to re-org

I can if he´s ok with it

clown: need to freeze edits during that

mc: let me ask Jason and then put on agenda for next week´s editors´ meeting

then we can schedule the freeze

clown, sf: <looking at details>

mc: do we want to steer authors to the algorithm?

or create an easier to consume version for authors?

clown, rs: something for authors separately

mc: loop in Authoring Practices editors

rs: where do we put it?

authoring practices is large

should refactor

mc: the editors wanted to refactor

clown: would like an author-oriented section in our doc

rs: works for the core, but what about host languages?

prefer in the authoring practices, and pull in both the core and language-specific stuff for that

<scribe> (new authoring practices needs SVG stuff)

or have language-specific authoring practice versions

also noting existence of Using ARIA in HTML

<clown> accname-aam-1.1

rs: what´s the name of the doc?

(shortname)

mc: placeholder for now

will have to solidify on FPWD

don´t worry about filename in repository, can move

mc: one doc with sections for the techs, or separate for each tech?

rs: sounds like we have agreement on way forward

some details to be sorted

clown: feel free to add to the doc

rs: what do we do in the ARIA spec?

mc: refer to the new doc, remove the existing section

clown: supposed to give JamesC an action to do

want to wait until after re-org

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/09/26 14:53:21 $