WebControl Accessibility Audit Fixes - #1254
Conversation
…es and Text Localization Sweep
…ummary - Accessibility corrections
| if (($caption = $this->getCaption()) === '') { | ||
| $caption = ' '; | ||
| } | ||
| $writer->write("<a href=\"{$url}\">{$caption}</a>"); |
There was a problem hiding this comment.
Unfortunately this is a breaking change we already made in the past. Removing the from the tab will break custom css targeting the tab captions. That's why the 'javascript://' fake url workaround was introduced.
There was a problem hiding this comment.
We do need to encode the rule regarding "javascript://"-urls into the agent files. Obviously, the first instinct is to revert the url links for another solution. But depending on the research, you may be correct about dropping the workaround.
Accessibility is HUGE, especially for a framework.
|
Looks really good, thank you! A small note on a TTabView change.. maybe it's time to just drop the workaround and make people update their css. Your choice |
|
I'll do some more research on options regarding the fake js url. There will be some changes to this PR, eg we may upgrade this PR to addressing the js urls, but maybe not. Basically, this aspect of PRADO probably needs a review given how far, how standardized, and how ubiquitous browser technology has become. |
2 participants
I ran an audit of the WebControls and found more than a few serious issues with accessibility.
The ActiveControls (In-Place too) and their parent controls were fixed up.
then the rest of the WebControls were the natural follow up.
[x] ActiveControls, In-Place, and their non-active Parents.
[x] all the rest of the non-active controls.
PS. This came about because of an accessibility audit on the [some new] In-Place controls and found lots of issues in general too.