Skip to content
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

Review 1.1.1 images #25

Closed
WilcoFiers opened this issue Dec 6, 2016 · 4 comments
Closed

Review 1.1.1 images #25

WilcoFiers opened this issue Dec 6, 2016 · 4 comments
Assignees

Comments

@WilcoFiers
Copy link
Member

Action on me to review 1.1.1. images, see given our current approach if where we can break up this rule.

@dd8
Copy link
Collaborator

dd8 commented Dec 14, 2016

Problems

Steps 3-5 are likely to cause harm for code like this:

<button onclick="stars(2)">
	<img src="star.png"><img src="star.png">
</button>

Placing role=”img” onto the button will break the button in AT, and you'd probably want to use aria-label since it's a very reliable means of labelling the button element:
http://www.powermapper.com/tests/screen-readers/labelling/button-aria-label-img-no-alt/

  1. The XPath selector mentions <embed> and <object> elements, but this doesn’t match the text in step 1, and there’s no further mention of these elements

  2. Steps 9 and 10 should probably apply to elements other than <a> For example: <button>, <h1>- to <h6> and probably others too.

  3. The way the rule is structured misses some opportunities for automation. For example <input type="image" src="book-flight.png"> is never decorative. The same is true of a heading element containing only an image.

General rule structure

Would it make sense to organize rules by how the user perceives them? For example, all of these cause exactly the same problem and need the same fix – a label saying ‘Book Flight’:

<input type="image" src="book-flight.png"> 
<button><img  src="book-flight.png"></button>
<button><svg>...</svg></button>
<button><canvas>...</canvas></button>
<button style="background-image: book-flight.png"></button>
<button class="icon-font">&4F6d;</button>
<a role="button" onclick="book()"><img  src="book-flight.png"></a>

If the rule is organized like this adding new failure selectors seems less risky, because the rule flow-of-control is much simpler. It also seems easier to identify gaps (e.g. list all the ways in HTML to create an image button without a label)

If you went this route, you'd probably want a parent markdown document listing all the high level ways to violate 1.1.1 linking to specific rules. Again this makes it easier to identify gaps:

  • unlabelled HTML image button
  • unlabelled HTML image link
  • non-decorative plain HTML image
  • and so on...

If this approach is used it may take a while to figure out the correct structure. For example, consider these:

<h1><img src="logo.png"></h1>
<legend><img src="flight-picker-header.png"></legend>
<a href="http://w3.org/tr/wcag20"><img src="wcag.png"></a>

Rule naming (naming things is hard)

  1. The rule naming convention seems to assume there will be no other rules for 1.1.1. What happens if you want to add checks for <svg> and <canvas>? And what about formats other than HTML? PDFs and Word have very different mechanisms for specifying alt text and indicating decorative images, so it would be difficult to add to this rule.

  2. Related to the above - some of the failures in this rule also fail other SC – user interface controls not having names due to missing text alternatives is usually a 1.3.1 and 4.1.2 fail as well. The rule organization above might fix this since it splits the SC from the failure test (and lets a rule trigger multiple SC failures)

  3. Checkpoint numbering changed dramatically between WCAG 1.0 and 2.0. What happens to the rule naming convention when WCAG 3.0 is released?

@dd8
Copy link
Collaborator

dd8 commented Feb 6, 2017

The classification of images and the decision tree in the WAI image tutorial is very relevant to this rule:
https://www.w3.org/WAI/tutorials/images/
https://www.w3.org/WAI/tutorials/images/decision-tree/

@dd8
Copy link
Collaborator

dd8 commented Feb 8, 2017

The classification of images in the WAI tutorial is very useful:

  • Informative - hard to identify automatically
  • Decorative - hard to identify automatically
  • Functional - easy to identify automatically (any image used in an interactive element)
  • Images of text - hard to identify automatically
  • Complex images - hard to identify automatically
  • Groups of images - should be possible to identify automatically (but see below)
  • Image maps - easy to identify automatically (area element)

This should be treated as a group of images:

<img src="star-full.jpg"  alt="3.5 out of 5 stars">
<img src="star-full.jpg"  alt="">
<img src="star-full.jpg"  alt="">
<img src="star-half.jpg"  alt="">
<img src="star-empty.jpg" alt="">

But this shouldn't:

<img src="star-full.jpg"  alt="1 star">
<img src="star-full.jpg"  alt="2 stars">
<img src="star-full.jpg"  alt="3 stars">
<img src="star-full.jpg"  alt="4 stars">
<img src="star-full.jpg" alt="5 stars">

<script>
$( "img[src^='star']" ).onclick=rate(this);
</script>

and neither should this:

<img src="spacer.gif"  alt="">
<img src="spacer.gif"  alt="">
<img src="spacer.gif"  alt="">
<img src="spacer.gif"  alt="">
<img src="spacer.gif"  alt="">

@WilcoFiers
Copy link
Member Author

This rule has been superseded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants