This repository was archived by the owner on Dec 4, 2017. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 877
docs(a11y-sweep): Apply baseline accessibility to the examples #1613
Open
AlmeroSteyn
wants to merge
1
commit into
angular:master
Choose a base branch
from
IdeaBlade:docs-a11y-sweep
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
body{ | ||
color: #5E5E5E; | ||
} | ||
|
||
dt { | ||
float: left; | ||
clear: left; | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
body{ | ||
color: #5E5E5E; | ||
} | ||
|
||
dt { | ||
float: left; | ||
clear: left; | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
body{ | ||
color: #5E5E5E; | ||
} | ||
|
||
dt { | ||
float: left; | ||
clear: left; | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
body{ | ||
color: #5E5E5E; | ||
} | ||
|
||
dt { | ||
float: left; | ||
clear: left; | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
11 changes: 5 additions & 6 deletions
11
public/docs/_examples/toh-5/ts/app/dashboard.component.html
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,11 +1,10 @@ | ||
<!-- #docregion --> | ||
<h3>Top Heroes</h3> | ||
<h2>Top Heroes</h2> | ||
<div class="grid grid-pad"> | ||
<!-- #docregion click --> | ||
<div *ngFor="let hero of heroes" (click)="gotoDetail(hero)" class="col-1-4"> | ||
<!-- #enddocregion click --> | ||
<div class="module hero"> | ||
<h4>{{hero.name}}</h4> | ||
</div> | ||
<div *ngFor="let hero of heroes" | ||
class="col-1-4"> | ||
<a class="module hero" [routerLink]="['/detail', hero.id]">{{hero.name}}</a> | ||
</div> | ||
<!-- #enddocregion click --> | ||
</div> |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Is there a project preference for nested inputs vs.
for
/id
-based association?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.
No specific preference yet but I would prefer implicit labelling where possible as it removes the need to generate/bind unique IDs to controls in components. Although both options lead to valid accessible form controls.
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 think that makes sense, but I'd maybe like to see both techniques demonstrated at some point, simply because the explicit/non-nested labelling is pretty popular and also much easier to mess up.
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.
Fully agree, but don't think this is the place. I'm also working on an a11y cookbook that should see the light in the near future. That has a whole section on labelling, including the explicit labelling version. Here, however, the purpose is to get folks started with Angular2 so I think adding the extra stuff to generate the IDs right off the bat will distract from what the TOH docs are all about.
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.
Yup, I looked through the a11y cookbook PR a while back. Good stuff! Is it worth commenting on that PR now or are you making big changes?
I guess my concern with the implicit labelling is just that devs who're accustomed to doing explicit labelling incorrectly might learn something from seeing it done correctly here, whereas devs who are accustomed to doing implicit labelling are probably already doing it correctly. But I may be over-thinking it, and this is definitely an improvement in any case.
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.
Nah that one is outdated. Did that, then life happened, with some changes and edits. I just created a new one at #1625
Agree to a certain extent but what we don't want are devs copying and pasting it from TOH because they think that is what is needed to make Angular work
I think most devs looking here will be mostly concerned with getting their first app off the ground and we should not confuse them with extra code. So in the TOH examples I think we should look at the big wins that require little to no extra code. The rest will come later.
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.
Yeah I think as long as it's accessible in some manner I'm OK. I can appreciate not wanting to confuse people but I also think it's important to position accessibility as a first-class concern and embed it throughout the documentation.
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.
There I fully agree with you. This exercise is exactly about giving a11y that position but to find the balance where the lessons of the separate docs are not diluted. Stuff not added to to the examples due to complexity could eventually be added as comments/notes in the examples or docs.