This makes sense to me too. Brett
Brett Lewis VFO | Software Engineer 11800 31st Court North, St. Petersburg, FL 33716 T 727-299-6270 ble...@vfo-group.com<mailto:ble...@vfo-group.com> www.vfo-group.com<http://www.vfo-group.com> From: Alexander Surkov [mailto:surkov.alexan...@gmail.com] Sent: Wednesday, September 14, 2016 4:56 PM To: James Teh <ja...@nvaccess.org> Cc: Brett Lewis <ble...@vfo-group.com>; accessibility-...@lists.linux-foundation.org Subject: Re: [Accessibility-ia2] HTML placeholder attribute Fine with me. On Wed, Sep 14, 2016 at 7:08 PM, James Teh <ja...@nvaccess.org<mailto: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<mailto: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<tel:727-299-6270> ble...@vfo-group.com<mailto:ble...@vfo-group.com> www.vfo-group.com<http://www.vfo-group.com> From: Alexander Surkov [mailto:surkov.alexan...@gmail.com<mailto:surkov.alexan...@gmail.com>] Sent: Tuesday, September 13, 2016 1:52 PM To: Brett Lewis <ble...@vfo-group.com<mailto:ble...@vfo-group.com>>; James Teh <ja...@nvaccess.org<mailto:ja...@nvaccess.org>> Cc: accessibility-...@lists.linux-foundation.org<mailto: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<mailto: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/master/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<tel:727-299-6270> ble...@vfo-group.com<mailto:ble...@vfo-group.com> www.vfo-group.com<http://www.vfo-group.com> _______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org<mailto:Accessibility-ia2@lists.linuxfoundation.org> https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 -- James Teh Executive Director, NV Access Limited Ph +61 7 3149 3306<tel:%2B61%207%203149%203306> www.nvaccess.org<http://www.nvaccess.org> Facebook: http://www.facebook.com/NVAccess Twitter: @NVAccess SIP: ja...@nvaccess.org<mailto:ja...@nvaccess.org>
_______________________________________________ Accessibility-ia2 mailing list Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
