we did this. see today's editors' draft.

(In reply to Charles McCathieNevile from comment #1)
> we did this. see today's editors' draft.

Hi Chaals,

I checked the 13 June 2014 editors draft but don't see the normative statement changed. Is the change in a different document? 

The document at:
https://dvcs.w3.org/hg/html-proposals/raw-file/default/longdesc1/longdesc.html#authors
still says "should not". It reads:

"Authors should not rely solely on longdesc where standards exist to provide direct, structured access." 

I suggested making it a "may" something such as:
"Authors may use other standards in addition to longdesc if those standards provide semantic, programmatic, direct, and structured access." 

And the example was not improved. It reads:

"For example a MathML version of mathematical content, or an SVG image that uses the accessibility features of SVG, can provide better accessibility to users with appropriate technology. In such cases, it is appropriate to use longdesc as a fallback strategy, in combination with more modern techniques."

I had suggested something such as:

"For example a MathML version of mathematical content, or an SVG image that uses the accessibility features of SVG, can provide good accessibility to users with appropriate technology. In such cases, it is appropriate to use those techniques in combination with longdesc."

This current spec text still contains incorrect and prejudicial longdesc information as it infers that longdesc is not modern. The fact that we have a new longdesc spec and new a longdesc implementation with FireFox does indeed make longdesc modern.

In addition the normative statement is confusing in relation to aria-describedat. Using a bridging technology would backward. Please consult [2] for full rationale. HTML has native, built-in long description semantics with longdesc. 

I noticed John's email and conclusion regarding MATHML [3]. He wrote:

"Conclusion: neither technique has robust support today, and recommending either is problematic. Recommendation is to strike any reference to the suitability or non-suitability of using @longdesc for complex math, but to avoid suggesting that MathML has sufficient support today."

I would be fine with striking any reference to MathML and for the spec to read:

"For example a SVG image that uses the accessibility features of SVG, can provide good accessibility to users with appropriate technology. In such cases, it is appropriate to use those techniques in combination with longdesc."

Thanks,
Laura

[2] http://www.d.umn.edu/~lcarlson/research/constriants/bridging.html 
[3] http://lists.w3.org/Archives/Public/public-html-a11y/2014May/0090.html

Hi Laura,

Thanks for pointing out this oversight.  While we partially accepted your comment, the changeset was never uploaded to the repository.  

We agree with you that the words "modern" and "better" are judgmental. We have replaced that language with purely descriptive text instead.

> For example a MathML version of mathematical content, or an SVG 
> image that uses the accessibility features of SVG, can provide direct 
> accessibility to users with appropriate technology. In such cases, it is 
> appropriate to use those techniques in combination with longdesc.

However, we do want to encourage authors to use other markup solutions in addition to longdesc if those solutions may result in better accessibility in user agents that support them.

Feel free to mark this bug closed if you are satisfied with this response.

Changeset: https://dvcs.w3.org/hg/html-proposals/rev/08ac9fad22bd

(In reply to Mark Sadecki from comment #3)

Hi Mark,

Thank you very much for removing the incorrect and prejudicial language from the example. Much appreciated.

However, the categorical normative statement "Authors should not rely solely on longdesc where standards exist to provide direct, structured access." is still an issue.

For instance a direct aria-describedat image description solution may be good choice if native HTML semantics did not already exist or if it was supported better than longdesc.  But it would be foolhardy to use aria-describedat if it provided less or the same accessibility support as longdesc. If aria-describedat provides less or equal accessibility authors should not use it instead of longdesc. 

The introduction to ARIA clearly states, "WAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement. When the host language provides a feature that provides equivalent accessibility to the WAI-ARIA feature, use the host language feature." [4] 

As Derek Featherstone has stated, "ARIA is designed to provide accessibility at a technical level - what you might call 'programmatic accessibility' - where it doesn't already exist." Longdesc exists.  

The first rule of ARIA use is "If you can use a native HTML element [HTML5] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."  [5] For further rationale please consult: "Using a Bridging Technology is Backward". [2] 

I suggest changing the normative statement to something that takes this into consideration such as:

"Authors should not rely solely other standards to provide direct, structured access when longdesc provides equivalent accessibility."

Or I suggest adding clause to qualify and explain the circumstance of when it would be appropriate, such as:

"Authors should not rely solely on longdesc when a standard exists to provide direct, structured access and that standard provides increased accessibility."

If the categorical normative statement is not changed it will be confusing, could lead to less accessible content, violate other specifications [5], and be an unnecessary burden upon authors who have already expended time and effort in using longdesc correctly in their work.

Thank you,
Laura

[2] http://www.d.umn.edu/~lcarlson/research/constriants/bridging.html 
[4] http://www.w3.org/TR/wai-aria/introduction
[5] http://www.w3.org/TR/2013/WD-aria-in-html-20131003/#first-rule-of-aria-use

Hi Janina,

In reply to your email:
http://lists.w3.org/Archives/Public/public-html-a11y/2014Jun/0116.html

I wholeheartedly agree that it would be nonsensical to mention aria-describedat in the longdesc spec. That is not what I suggested. I suggested clarifying the categorical normative statement. 

In bug Comment 3 Mark stated: "we do want to encourage authors to use other markup solutions in addition to longdesc if those solutions may result in better accessibility in user agents that support them." Increased accessibility is what we all want. 

However, that is not what the normative statement says. It categorically proclaims: "Authors should not rely solely on longdesc where standards exist to provide direct, structured access." 

There is no qualifying phrase saying anything about increased accessibility. Again, I request adding a clarifying clause to the end of the normative statement, letting people know when the statement would be appropriate such as:

"and that standard provides increased accessibility."

So the full statement would read:

"Authors should not rely solely on longdesc when a standard exists to provide direct, structured access and that standard provides increased accessibility."

Please fix this issue. If it is not fixed it 1) will be confusing, 2) could lead to less accessible content, 3) violate other specifications, and 4) be an unnecessary burden upon authors who have already expended time and effort in using longdesc correctly in their work.

Alternatively if a categorical normative statement is needed, simply add the following to the spec:

"Authors should not rely solely on other standards to provide direct, structured access when longdesc provides equivalent accessibility." 

Thank you very much.

Kindest Regards,
Laura

Closing as FIXED since the original comments were addressed.

The task force did not accept the change requested in the final comment, but did accept the other halpful suggestions - thank you for those.

Please note you can reopen the issue if this is not satisfactory.

Thank you.

(In reply to Liam R E Quin from comment #6)

> Closing as FIXED since the original comments were addressed.

Hi Liam,

I am reopening this bug as the normative statement has not been fixed and no rationale has been provided for not adding the clause that I suggested, which would fix it.

> The task force did not accept the change requested in the final comment

Could you please let me know:

* Where is it documented that the task force did not accept the change? 

* What is the rationale for not fixing the issue by adding a clarifying clause to the end of the normative statement? Why not let people know when the statement would be appropriate?  Specifically my question is why not add:

"and that standard provides increased accessibility."

So the full statement would read:

"Authors should not rely solely on longdesc when a standard exists to provide direct, structured access and that standard provides increased accessibility."

Thank you,
Laura

I haven't looked for the relevant minutes.

As far as I am concerned the effect is editorial, rather than substantive, and stating that authors should not rely *solely* on longdesc implies that they should retain it as a front-line tool.

At the same time, while "provides increased accesssibility" makes sense in conversation, it isn't at all clear what it requires or what qualifies in a given case.

I doubt the specification is going to be revised soon. Given that, I doubt much will happen with this bug in practice.

If there is ever an effort to revise the specification again, it may be worth looking carefully at the overall relationship of longdesc to alternatives available at that time - currently there are few if any formats that provide equivalent access to graphics in practice.