New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SC1-1-1-filename-is-valid-accessible-name #263
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to resolve the filename referencing issue.
Simplified applicability Changed 1st inapplicable test case. Added 2nd inapplicable test case
updated applicability
This comment has been minimized.
This comment has been minimized.
Updated title and description to target `alt` instead of accessible name
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Corb O'Connor comments in the CFC email chain:
|
@goetsu thanks for your comment. Your example would not be marked as a failure with this check because the alt "serves an equivalent purpose to the non-text content". You could write a rule that looks for that exact scenario and fully automate it but I don't think that building rules for a single purpose would be the most efficient approach. |
In this instance, the accessible name of "Barack Obama" does not include the file extension which is part of the filename specified in the |
Serving only an aesthetic purpose, providing no information, and having no functionality. | ||
|
||
**Note:** Authors can mark an `img` element as decorative to indicate that it should be ignored by assistive technology by using either `role="presentation"`, `role="none"`, or `alt=""`. An element should only be marked as decorative if removing the element does not cause a loss of information to the user. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any elements other than 'img' that could be marked as decorative, such as 'svg'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The context of this rule is img
so the note addresses that specifically and not other elements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could change this to say "Authors can mark elements as decorative..." if you think that would make more sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK with this apart from my question on the 'decorative' definition. Seems very thorough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some editorial issues yet, but rule is looking good
Minor editorial edit.
Minor template edits
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for putting this in the CFC. I'm afraid I found some problems with the way this is done. I don't think your test cases are actually applicable. It seems to me the applicability is missing some of its key parts.
|
||
## Test Cases | ||
|
||
### Passed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't seem like any of the passed / failed examples would be applicable. The applicability doesn't say to ignore file extensions or its file path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@WilcoFiers the applicability refers to a definition of "filename" https://github.com/auto-wcag/auto-wcag/blob/master/pages/glossary/filename.md which excludes the file path and appended query strings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@WilcoFiers @kasperisager and I have reworked some of the test cases to fit the applicability. Please can you give this another look.
@Brynanders, I think that since Carlos' permissions changed the other day, the status of this PR is now "changes requested" instead of "approved". I think you will have to dismiss Carlos' (old) review to get things back in order. |
@Brynanders, @JKODU, @WilcoFiers, can this one be merged? |
* master: Rule update: "HTML page has a title" (#440) Rule update: "aria attribute allowed" and "aria required states and properties" (#436) Changed succescriteria from 4.1.2 to 1.3.1 (#449) Rename SC1-2-Video-description-track.md to SC1-2-video-description-track.md Glossary: add "Accessibility Support" to "Semantic role" term (#442) SC1-1-1-filename-is-valid-accessible-name (#263) Added assumption for SC3-1-2-lang-valid (#413) Update SC4-1-1-unique-id.md fix: update applicability fix: revert definitions fix: update glossary fix: applicability
<< Describe the changes >>
Closes issue: #216
Guidance for the PR (pull request) creator
When creating PR:
After creating PR:
Rule
,Definition
orChore
(more to the administrative side)How to Review And Approve