Reported by jteh on 2013-11-12 06:15
Issue raised by Adobe.
For some buttons, IPDDomNode::GetTextContent returns something different to the name. GetTextContent is supposed to account for alternate and actual text, but it seems that overriding a button's name is not considered alternate/actual text. Apparently, authors can override the name using the tooltip and this is what they (and Adobe) expect an AT user to see.
I guess it makes sense to do this for all controls for which the name is generally the content; i.e. the useNameAsContent flag in the backend.
The text was updated successfully, but these errors were encountered:
Comment 2 by James Teh <jamie@... on 2013-11-13 03:12
In [d196b3f]:
In browse mode in Adobe Reader, the correct text is now rendered for buttons, etc. where the label has been overridden using a tooltip or other means.
In the backend, where useNameAsContent is true, IPDDomNode::GetName is now tried before IPDDomNode::GetTextContent.
Re #3640.
Comment 6 by James Teh <jamie@... on 2013-11-26 22:59
In [0b55f19]:
In browse mode in Adobe Reader, the correct text is now rendered for buttons, etc. where the label has been overridden using a tooltip or other means.
In the backend, where useNameAsContent is true, IPDDomNode::GetName is now tried before IPDDomNode::GetTextContent.
Fixes #3640.
Reported by jteh on 2013-11-12 06:15
Issue raised by Adobe.
For some buttons, IPDDomNode::GetTextContent returns something different to the name. GetTextContent is supposed to account for alternate and actual text, but it seems that overriding a button's name is not considered alternate/actual text. Apparently, authors can override the name using the tooltip and this is what they (and Adobe) expect an AT user to see.
I guess it makes sense to do this for all controls for which the name is generally the content; i.e. the useNameAsContent flag in the backend.
The text was updated successfully, but these errors were encountered: