Closed scottaohara closed 2 years ago
Just had a thought... maybe we can prefix the commit messages with "correction:" and "addition:"? That could also help us identify what's what.
@marcoscaceres is every edit one of those? from now on and forever? most of these, i suppose would additions i suppose. corrections would indicate that we should have had the spec perfect from the onset?
@marcoscaceres is every edit one of those? from now on and forever?
Not every edit... some are a "chore" (e.g., a typo, grammar, or markup fix). However, most would be either an "addition" (new feature) or "correction" (bug fix).
most of these, i suppose would additions i suppose. corrections would indicate that we should have had the spec perfect from the onset?
"correction" means, "we found and fixed a bug". There is never an assumption that a spec is perfect: on the contrary, the assumption is that specs have bugs, and "corrections" fixes those bugs.
closes issue #325
This update allows authors to specify the
link
orbutton
roles on anarea
with nohref
attribute.Any more complex widget, particularly any that would need to convey a visual state or updated styling, would be far more practical for authors to create another accessible control instead. As these elements do not allow nested content (and even CSS pseudo element content appears in a different location than where the
area'
s coordinates place it, no container-type role would make sense here either.Ideally, authors would be using a
tabindex
on these elements when specifying a role.... but as there could be situations where a role needs to be conveyed, but it is not necessary to make the particular element keyboard accessible (alternate mechanism available), the requirement for including atabindex
was left off this PR. Additionally, we make no such requirements for other widget roles, so on second thought it seemed out of place to require one for this role.Need at least two checkers to accept this change before we can merge.
Preview | Diff