Closed pattonwebz closed 1 month ago
We could either simplify this to these phases:
$allowed_phrases = [
__( 'new window', 'accessibility-checker' ),
__( 'new tab', 'accessibility-checker' ),
];
Or we can keep limits on the phrases and add support for these:
$allowed_phrases = [
__( 'opens a new window', 'accessibility-checker' ),
__( 'opens a new tab', 'accessibility-checker' ),
__( 'opens new window', 'accessibility-checker' ),
__( 'opens new tab', 'accessibility-checker' ),
__( 'in a new window', 'accessibility-checker' ),
__( 'in a new tab', 'accessibility-checker' ),
__( 'in new window', 'accessibility-checker' ),
__( 'in new tab', 'accessibility-checker' ),
];
@amberhinds any preference?
Simplifying seems better. Grammatically, it doesn't make sense to me but from a literal rule standpoint it's probably fine.
A user made a feature request on the dot org forums about making the new window warning less rigid so that their links (which do indicate it opens on a new tab) to satisfy the warning.
Is your feature request related to a problem? Please describe.
A link on a page has a label saying it will be a new tab - but the warning is still flagged for it,
Describe the solution you'd like
A wider check that allows something like
new [tab|window]
to satisfy the issue.Why do you think this feature is something we should consider for this plugin?
Not mentioned in the request but it could reduce noise and make the warning more robust against the variance in labeling.
Additional context