Hey Dominic,

Thanks for the example!

However, @placeholder isn't mentioned in the Accname AAM.  Specifically, Accname document does not say to use placeholder text for the name, as it's neutral with respect to HTML.

Instead, the HTML AAM discusses @placeholder in its section regarding calculating names and descriptions for <input> types[1], and it more or less agrees with your points.

For now, I'm changing the component to the HTML AAM, and assigning it to Steve Faulkner.

[1] http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#h-input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element

(In reply to Dominic Mazzoni from comment #0)
> Consider: 
> 
> Enter your birthday:
> <input type="text" aria-label="Year" placeholder="yyyy">
> <input type="text" aria-label="Month" placeholder="mm">
> <input type="text" aria-label="Day" placeholder="dd">
> 
> The ARIA labels are excellent, but the placeholder provides great additional
> information. Rather than mapping placeholder to the accessible name, where
> it'd be completely dropped because aria-label overrides it, perhaps it could
> be mapped to the accessible description, where aria-describedby (or
> aria-placeholder) could override it.
> 
> This also makes it easier to figure out what to do on Mac, which has an
> AXPlaceholder field: run the accessible description calculation, and if the
> description comes from the placeholder, expose it in AXPlaceholder,
> otherwise in AXHelp.

Hi Dominic, the placeholder content should only used as an accessible name in the absence of other methods to calculate the accessible name, refer to
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#accessible-name-and-description-calculation 

what is defined in the above was based on testing I did back in 2013
http://www.html5accessibility.com/tests/placeholder-labelling.html so reflects what was implemented at the time. I am sure it needs to be updated.

(In reply to steve faulkner from comment #2)
> (In reply to Dominic Mazzoni from comment #0)
> > Consider: 
> > 
> > Enter your birthday:
> > <input type="text" aria-label="Year" placeholder="yyyy">
> > <input type="text" aria-label="Month" placeholder="mm">
> > <input type="text" aria-label="Day" placeholder="dd">
> > 
> > The ARIA labels are excellent, but the placeholder provides great additional
> > information. Rather than mapping placeholder to the accessible name, where
> > it'd be completely dropped because aria-label overrides it, perhaps it could
> > be mapped to the accessible description, where aria-describedby (or
> > aria-placeholder) could override it.
> > 
> > This also makes it easier to figure out what to do on Mac, which has an
> > AXPlaceholder field: run the accessible description calculation, and if the
> > description comes from the placeholder, expose it in AXPlaceholder,
> > otherwise in AXHelp.
> 
> Hi Dominic, the placeholder content should only used as an accessible name
> in the absence of other methods to calculate the accessible name, refer to
> http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#accessible-name-and-
> description-calculation 
> 
> what is defined in the above was based on testing I did back in 2013
> http://www.html5accessibility.com/tests/placeholder-labelling.html so
> reflects what was implemented at the time. I am sure it needs to be updated.

should also have pointed out that placeholder is included in acc desciption algo
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element

1.Use aria-describedby
2.Otherwise use the placeholder attribute if it wasn't used as the accessible name
3. Otherwise use the title attribute if it wasn't used as the accessible name.
4. If none of the above yield a usable text string there is no accessible description

Ah yes, the algorithm here looks correct:

http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element

However, what about this new "Accessible Name and Description: Computation and API Mappings 1.1" draft?

http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html#mapping_additional_nd_te

This new draft gives a much more comprehensive algorithm for many parts of the calculation, and it's the only one that has a correct specification for mapping the result of the calculation to AXAPI, but it doesn't mention placeholder at all yet.

I just realized I probably filed the bug against the wrong component. I changed it to "AccName AAM".

Am I correct that while it's still a work in progress, the AccName AAM is meant to totally supercede the HTML-AAM in terms of the accessible name calculation?

(In reply to Dominic Mazzoni from comment #4)
> Ah yes, the algorithm here looks correct:
> 
> http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#input-type-text-
> input-type-password-input-type-search-input-type-tel-input-type-url-and-
> textarea-element
> 
> However, what about this new "Accessible Name and Description: Computation
> and API Mappings 1.1" draft?
> 
> http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.
> html#mapping_additional_nd_te
> 
> This new draft gives a much more comprehensive algorithm for many parts of
> the calculation, and it's the only one that has a correct specification for
> mapping the result of the calculation to AXAPI, but it doesn't mention
> placeholder at all yet.
> 
> I just realized I probably filed the bug against the wrong component. I
> changed it to "AccName AAM".
> 
> Am I correct that while it's still a work in progress, the AccName AAM is
> meant to totally supercede the HTML-AAM in terms of the accessible name
> calculation?

Hi Dominic,

note the HTML aam references the Accname AAM for the aria-label/aria-labelledy calculation (and should do likewise for describedby (bug now filed)https://www.w3.org/Bugs/Public/show_bug.cgi?id=28177 

> Am I correct that while it's still a work in progress, the AccName AAM is
> meant to totally supercede the HTML-AAM in terms of the accessible name
> calculation?

It is my understanding that the accName AAM will only define core cross tech aspects of name/description calculation, leaving tech specific aspects to the spec that defines that tech.

If you have any ideas about how the calculations for specific elements/attributes should be defined, feedback is welcome, the current format was developed in consultation with alex surkov who considered that a minimalistic approach was adequate.

> note the HTML aam references the Accname AAM for the
> aria-label/aria-labelledby calculation

Maybe I'm missing something. I'm looking here:

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

I see this text:

If the control has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in section 5.2.7. Accessible Name Calculation of the WAI-ARIA 1.0 specification.

that links to here: http://www.w3.org/TR/wai-aria/roles#namecalculation

...which is the ARIA specification, not the AccName AAM.

> It is my understanding that the accName AAM will only
> define core cross tech aspects of name/description calculation,
> leaving tech specific aspects to the spec that defines that tech.

Well, it already has specific mappings to the various tech specific APIs, which is incredibly useful. I don't know of any native accessibility API documentation that gets anywhere near this specific, so I don't see how we can leave the tech specific aspects to the spec - it requires interpretation.

For example, the AXAPI spec says that AXTitle should be used for visible text, and AXDescription for alternative text - but given that alone it's not at all obvious how to map the accessible name onto that API. Earlier versions of WebKit would sometimes map different strings to both AXTitle and AXDescription, which was inconsistent with other platforms.

The current AccName AAM really helps a lot by saying that you run the same (cross-platform) name calculation and the result gets put in AXTitlte if it came from visible text, and in AXDescription otherwise, and the other property stays blank - then the accessible description goes in AXHelp.

I think we could further amend this to say: if the result of the name calculation comes from the placeholder, put it in AXPlaceholder instead and leave AXTitle/AXDescription both blank. If the result of the description calculation comes from the placeholder, put it in AXPlaceholder and leave AXHelp blank.

> If you have any ideas about how the calculations for specific
> elements/attributes should be defined, feedback is welcome,
> the current format was developed in consultation with alex
> surkov who considered that a minimalistic approach was adequate.

I don't have any issues with the specific elements/attributes, it's more about how to map those to AXAPI in particular.

I'm also trying to figure out what to do on Android since we only have one accessible name field to work with, not two.

Hi Steve, Dominic,

> Hi Dominic,
> 
> note the HTML aam references the Accname AAM for the
> aria-label/aria-labelledy calculation (and should do likewise for
> describedby (bug now
> filed)https://www.w3.org/Bugs/Public/show_bug.cgi?id=28177 
> 
> > Am I correct that while it's still a work in progress, the AccName AAM is
> > meant to totally supercede the HTML-AAM in terms of the accessible name
> > calculation?
> 
> It is my understanding that the accName AAM will only define core cross tech
> aspects of name/description calculation, leaving tech specific aspects to
> the spec that defines that tech.

Steve is correct.

The Accname-AAM was excised from the Core-AAM, leaving behind a link to the Accname-AAM (see: http://localhost/~clown/GitHub/aria/core-aam/core-aam.html#mapping_additional_nd). Both the Core-AAM and the Accname_AAM define core features only.

It's up to language specific "X-AAM" documents to define how native markup fits in.  As an(other) example, the SVG-AAM name and description section says to follow the Accname-AAM, but with the some modifications:
http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html#mapping_additional_nd

Hope that helps.

Oh, crap, the dreaded "localhost" url.

What I meant was:

>...
> Steve is correct.
> 
> The Accname-AAM was excised from the Core-AAM, leaving behind a link to the
> Accname-AAM (see:
> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#mapping_additional_nd). Both the Core-AAM and the Accname_AAM define
> core features only.
> 
> ...

(In reply to Dominic Mazzoni from comment #6)
> > note the HTML aam references the Accname AAM for the
> > aria-label/aria-labelledby calculation
> 
> Maybe I'm missing something. I'm looking here:
> 
> http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#accessible-name-and-
> description-calculation
> 
> I see this text:
> 
> If the control has an aria-label or an aria-labelledby attribute the
> accessible name is to be calculated using the algorithm defined in section
> 5.2.7. Accessible Name Calculation of the WAI-ARIA 1.0 specification.
> 
> that links to here: http://www.w3.org/TR/wai-aria/roles#namecalculation
> 
> ...which is the ARIA specification, not the AccName AAM.

Which is old, going forward.  When the Accname-AAM was excised from the Core-AAM, it was likewise removed from the ARIA spec.  The latest ARIA 1.1 TR reflects that:
http://www.w3.org/TR/wai-aria-1.1/#namecalculation

(In reply to Dominic Mazzoni from comment #6)
> > note the HTML aam references the Accname AAM for the
> > aria-label/aria-labelledby calculation
> 
> Maybe I'm missing something. I'm looking here:
> 
> http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#accessible-name-and-
> description-calculation
> 
> I see this text:
> 
> If the control has an aria-label or an aria-labelledby attribute the
> accessible name is to be calculated using the algorithm defined in section
> 5.2.7. Accessible Name Calculation of the WAI-ARIA 1.0 specification.
> 
> that links to here: http://www.w3.org/TR/wai-aria/roles#namecalculation
> 
> ...which is the ARIA specification, not the AccName AAM.

gotta fix that


> 
> > It is my understanding that the accName AAM will only
> > define core cross tech aspects of name/description calculation,
> > leaving tech specific aspects to the spec that defines that tech.
> 
> Well, it already has specific mappings to the various tech specific APIs,
> which is incredibly useful. I don't know of any native accessibility API
> documentation that gets anywhere near this specific, so I don't see how we
> can leave the tech specific aspects to the spec - it requires interpretation.
> 
> For example, the AXAPI spec says that AXTitle should be used for visible
> text, and AXDescription for alternative text - but given that alone it's not
> at all obvious how to map the accessible name onto that API. Earlier
> versions of WebKit would sometimes map different strings to both AXTitle and
> AXDescription, which was inconsistent with other platforms.
> 
> The current AccName AAM really helps a lot by saying that you run the same
> (cross-platform) name calculation and the result gets put in AXTitlte if it
> came from visible text, and in AXDescription otherwise, and the other
> property stays blank - then the accessible description goes in AXHelp.
> 
> I think we could further amend this to say: if the result of the name
> calculation comes from the placeholder, put it in AXPlaceholder instead and
> leave AXTitle/AXDescription both blank. If the result of the description
> calculation comes from the placeholder, put it in AXPlaceholder and leave
> AXHelp blank.
> 
> > If you have any ideas about how the calculations for specific
> > elements/attributes should be defined, feedback is welcome,
> > the current format was developed in consultation with alex
> > surkov who considered that a minimalistic approach was adequate.
> 
> I don't have any issues with the specific elements/attributes, it's more
> about how to map those to AXAPI in particular

ok will look into this

> 
> I'm also trying to figure out what to do on Android since we only have one
> accessible name field to work with, not two.

do you have a pointer to the android acc API?

I'm going through currently open bugs and am trying to identify which need to be added to AccName 1.2. Is this still an open issue and what is the recommendation based on those familiar with it here?
Thanks,
Bryan

Please move any further discussion into a new issue against AccName on GitHub if this is still applicable.