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?