PF/XTech/HTML5/AltCurlyBraces
Curly Braces Used to Contain Generic Type value for alt
Precis
The alt
attribute is intended to convey human-parseable output, not a means of annotating markup with machine-extractable semantic information about the purpose of an element.
Is This an Abuse of @alt?
Use of the alt
attribute for generic placeholding text leaves no mechanism for the conscientious author or ATAG-compliant authoring tool to provide a textual equivalent for the image or object, in addition to an indicator of the role
of the image or object for machine processing. Therefore, alt
should: (a) be a required attribute reserved for human-parseable content; (b) that role
be used to provide machine-processable information. This is particularly important in the case of those using assistive technologies (AT), as the role
attribute can be used as a selector or hook by which, in accordance with user preferences and needs, is capable of exposing increasing levels of granularity to the user. (For example, a screen-reader user or the user of a refreshable braille display, might want to set their assistive technology to skip all images whose role
value is layout
, but include those whose role
value is button
. If alt
is omitted due to author error/choice or the limitations of the tools the author is using, role
provides a fall-back mechanism whereby an object can at least be identified by its purpose, for appropriate exposure to the user.
The curly braces proposal in the editor's draft of HTML5 doesn't appear to be a text equivalent per WCAG. The HTML WG needs to be sure deliverables satisfy accessibility requirements. PF are the "go-to-guys" for guidance in accessibility matters. PF's counsel is needed BEFORE any particular solution is chosen to be added to the next published draft. The curly braces proposal should not be published outside of an editor's draft without consultation and collaboration with PF.
The Protocols and Formats Working Group (PFWG) has not yet provided guidance with regarding curly braces proposal in the the IMG
section of the editor's draft with respect to conformance with:
- Web Content Accessibility Guidelines (WCAG)
- Authoring Tool Accessibility Guidelines (ATAG)
- User Agent Accessibility Guidelines (UAAG)
This is, at heart, an authoring tool implementation problem, not a declarative language problem.
Are There Negative Effects of the Use of Curly Brackets in alt Text?
The curly braces proposal is meant for meta data and would fit better in a separate IMG
attribute. In any event, it isn't a text equivalent per WCAG. Not only do reserved characters pollute the possible values available for an attribute whose data type is string, but also it is meta data about the image -- not an equivalent. They are two different things.
What will happen when author wants to add alt
text as equivalent and machine parseable info for application processing?
What if someone actually has an image of {} or {captcha}, for example -- text shouldn't be in graphics, but what if this is needed where say someone is showing how text appears in a new font they are designing?