Fine with me. On Wed, Sep 14, 2016 at 7:08 PM, James Teh <ja...@nvaccess.org> wrote:
> Visually, placeholder is certainly more like a value than a > name/description. However, arguably, it is semantically different to a > value in that it's more of a hint for the user as to what to enter there. > The reason for the name mapping was partially because it's a nice fallback: > having no label at all is probably an authoring error, so it's reasonable > to fall back to placeholder. > > I think I originally supported the description idea, but on further > reflection, I'm not so sure this isn't going to cause problems. It just > occurred to me that if an author sets title or aria-describedby, that will > get mapped to description, thus killing the placeholder. So, we definitely > need to expose the placeholder attribute. However, once we have that (plus > AT support), we then always have to compare description with placeholder > "just in case", which is pretty ugly. Name is different because while no > name is probably authoring error, no description certainly isn't. > > In short, I'd like to propose that we: > 1. Expose the placeholder attribute; > 2. Keep the current behaviour of falling back to placeholder for name as a > last resort; > 3. When 1) happens, expose explicit-name:false; > 4. Don't ever fall back to placeholder for description. > > Jamie > > > On 15/09/2016 2:38 AM, Alexander Surkov wrote: > > Jamie, do you have objections? > > On Wed, Sep 14, 2016 at 12:30 PM, Brett Lewis <ble...@vfo-group.com> > wrote: > >> Hi, >> >> I have always thought of the placeholder more like a value for the edit >> field rather than a name or description. >> >> However, I think the important thing is that we have a mechanism that >> allows assistive technology to “know” that the place holder is present and >> what the value of the placeholder is. >> >> Your suggestions accomplish that. >> >> Brett >> >> >> >> >> >> *Brett Lewis* >> >> *VFO* | Software Engineer >> >> 11800 31st Court North, St. Petersburg, FL 33716 >> >> *T* 727-299-6270 >> >> ble...@vfo-group.com >> >> www.vfo-group.com >> >> >> >> >> >> *From:* Alexander Surkov [mailto:surkov.alexan...@gmail.com] >> *Sent:* Tuesday, September 13, 2016 1:52 PM >> *To:* Brett Lewis <ble...@vfo-group.com>; James Teh <ja...@nvaccess.org> >> *Cc:* accessibility-...@lists.linux-foundation.org >> *Subject:* Re: [Accessibility-ia2] HTML placeholder attribute >> >> >> >> Hi, Brett and all. >> >> There's some discrepancy in the specs between UIA and IAccessible2 >> mappings. UIA column states [1] that HTML placeholder is mapped to >> accessible name and description, while IAccessible2 column says HTML >> placeholder has same mapping as aria-placeholder. aria-placeholder is >> exposed it in AriaProperties [2] for UIA and as object attribute for >> IAccessible2, the generic name computation doesn't mention aria-placeholder >> [3]. >> >> Leaving aside the specs, in case of IAccessible2 Firefox does similar >> things to UIA. Iirc we agreed [4] to expose placeholder as >> name/description, because it requires zero adoption efforts from AT, and >> since nobody claimed they need semantics of placeholder. >> >> If semantics loss is crucial for you, then I think we could fix it by >> exposing HTML placeholder this way: >> >> * name and description as Firefox does (fix the spec to make it clear) >> >> * expose placeholder object attribute >> >> * do not expose explicit-name='true' object attribute if placeholder was >> used as name >> >> >> >> aria-placeholder may be left with the current mapping. How does it sound? >> >> >> [1] https://w3c.github.io/aria/html-aam/html-aam.html >> [2] http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html >> [3] https://w3c.github.io/aria/accname-aam/accname-aam.html >> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=545817 >> >> >> >> On Thu, Sep 8, 2016 at 11:07 AM, Brett Lewis <ble...@vfo-group.com> >> wrote: >> >> Hi All: >> >> I have been looking at how the HTML placeholder attribute is supported by >> IA2. >> >> According to the HTML accessibility API mappings at: >> https://www.w3.org/TR/html-aam-1.0/ >> >> The placeholder in HTML should be handled just like the >> aria-placeholder. >> >> According to the core api accessibility mappings >> http://w3c.github.io/aria/core-aam/core-aam.html >> >> The aria-placeholder is mapped to an Ia2 object attribute of placeholder. >> >> So, it sounds like the HTML placeholder should be mapped to an IA2 object >> attribute of placeholder. >> >> Currently Firefox seems to support the placeholder as the name of the >> field if there is no other name provided by the page author (from >> https://bugzilla.mozilla.org/show_bug.cgi?id=545817. >> >> This seems to contradict the description of aria-placeholder from >> >> the WAI-ARIA) 1.1 spec at http://rawgit.com/w3c/aria/mas >> ter/aria/aria.html#aria-placeholder >> >> Says: >> >> >> >> “[ARIA 1.1] Defines a short hint (a word or short phrase) intended to aid >> the user with data entry when the control has no value. A hint could be a >> sample value or a brief description of the expected format. >> >> >> >> Authors should not use aria-placeholder >> >> instead of a label as their purposes are different: The label indicates >> what kind of information is expected. The placeholder text is a hint about >> the >> >> expected value. See related aria-labelledby and aria-label. >> >> >> >> Authors should present this hint to the user by displaying the hint text >> at any time the control's value is the empty string. This includes cases >> where >> >> the control first receives focus, and when users remove a >> previously-entered value. >> >> >> >> NOTE >> >> >> >> As is the case with the related HTML placeholder >> >> attribute, use of placeholder text as a replacement for a displayed label >> can reduce the accessibility and usability of the control for a range of >> users >> >> including older users and users with cognitive, mobility, fine motor >> skill or vision impairments. While the hint given by the control's label is >> shown >> >> at all times, the short hint given in the placeholder attribute is only >> shown before the user enters a value. Furthermore, placeholder text may be >> mistaken for a pre-filled value, and as commonly implemented the default >> color of the placeholder text provides insufficient contrast and the lack >> of a separate visible label reduces the size of the hit region available >> for setting focus on the control.” >> >> >> >> >> >> I am suggesting that we all agree to present the HTML placeholder just >> like the aria-placeholder using the IA2 object attribute of placeholder? >> >> This provides the most flexibility for screenreaders to present the >> placeholder information anyway they see fit. Using the placeholder as the >> name is not as flexible as the screenreader cannot distinguish between the >> placeholder and the label in this case. >> >> What does everyone think? >> >> Thanks, >> >> Brett >> >> >> >> >> >> *Brett Lewis* >> >> *VFO* | Software Engineer >> >> 11800 31st Court North, St. Petersburg, FL 33716 >> >> *T* 727-299-6270 >> >> ble...@vfo-group.com >> >> www.vfo-group.com >> >> >> >> >> _______________________________________________ >> Accessibility-ia2 mailing list >> Accessibility-ia2@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 >> >> >> > > > -- > James Teh > Executive Director, NV Access Limited > Ph +61 7 3149 3306www.nvaccess.org > Facebook: http://www.facebook.com/NVAccess > Twitter: @NVAccess > SIP: ja...@nvaccess.org > >
_______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
