search

freeCodeCamp / CurriculumExpansion

Creative Commons Attribution Share Alike 4.0 International
314 stars 104 forks source link

Learn Accessibility by Building a User Feedback Survey #127

Closed QuincyLarson closed 2 years ago

lionel-rowe commented 5 years ago

I'd be interested in contributing to this challenge.

QuincyLarson commented 5 years ago

@lionel-rowe Great - what are you thinking for the project?

The first step is to build the project itself. Then you can work backward to break it down into steps, like this: https://github.com/freeCodeCamp/CurriculumExpansion/pull/135/files#diff-99314d694942b489d28d8a6f0c3bc5a3

lionel-rowe commented 5 years ago

I have a few preliminary ideas. It would start with an existing project (probably something with lots of form fields) that breaks all the accessibility best practices, then the student is tasked with fixing it. It'd be interesting to consider the various use cases (use of a screen reader to aid partial sight, exclusive use of screen reader, mouse vs. keyboard navigation, color blindness, etc.)

lionel-rowe commented 5 years ago

Something like this as a skeleton of the pre-refactoring version:

https://codepen.io/lionel-rowe/pen/QozEKZ

thecodingaviator commented 5 years ago

@QuincyLarson Blind people is a very strong and controversial term to use, besides not only blind people require such accessibility. Something like for People with Vision Difficulties would be better and less controversial

lionel-rowe commented 5 years ago

@thecodingaviator I have to admit I'm not super familiar with the terminology around blindness and sight loss, but usually I see "blind and visually impaired" as a catch-all term, with "blind" implying complete or almost complete lack of sight. I'm not aware of anyone taking offense to the term "blind", as long as it's being used accurately for the context. WHO definitions for both terms are given in the Wikipedia article on visual impairment.

I might suggest an updated title as "learn accessibility by building a site usable by blind and visually impaired people". IMO the "usable by" part is also important, because "for" implies that the point of a11y is to build new products specifically for certain groups of users, when really it's to expand the reach and usability of existing products to be accessible to all users.

thecodingaviator commented 5 years ago

@QuincyLarson What do you thin?

@lionel-rowe I guess it's best to leave it to Quincy to decide what to do

QuincyLarson commented 5 years ago

@thecodingaviator I don't think there's anything wrong with saying "blind people". We have several blind people in the freeCodeCamp community who often give us feedback on accessibility. I will @-mention @zersiax here to get his opinion on this matter.

zersiax commented 5 years ago

i wouldn't say blind people is especially offensive. This, however, is a hotly debated topic and the terminology changes quite rapidly. I most often see "the blind and visually impaired" a lot in the wild, but you don't want to even mention a specific disability in my opinion. Keyboard accessibility also benefits RSI patients. Proper labeling of form fields and buttons also really helps mobility-impaired users that rely on speech recognition. "Learn accessibility by making a website that is accessible / that is built according to Accessibility Standards" might work for a title. Ease of access, universal design and friends are used almost interchangeably at this point. I hope that might give some more inspiration :)

QuincyLarson commented 5 years ago

Thanks for your feedback, @zersiax. Based on your many insights, I recommend we use the title "Learn Accessibility by Building a Website for People with Disabilities" and we can focus on making the website accessible for people with a range of disabilities, including mobility impairment and.

zersiax commented 5 years ago

Yep, that one fits. That way you even cover temporary disabilities like a broken arm

scissorsneedfoodtoo commented 5 years ago

@lionel-rowe, your survey page looks like it's off to a great start! Can't wait to see the finished project. Please let us know when you're done and if there's anything we can do to help.

lionel-rowe commented 5 years ago

@scissorsneedfoodtoo Thanks! I'm working on turning this into a proper first draft/PR now.

scissorsneedfoodtoo commented 5 years ago

@lionel-rowe, just wanted to check in and see how everything's going with your draft. Is there anything you can show us? If so, we could give some early feedback.

lionel-rowe commented 5 years ago

Sure, I'll get something up over this weekend.

scissorsneedfoodtoo commented 5 years ago

@lionel-rowe, thanks for your patience. This is looking good so far, but would you be able to rewrite this so it uses plain CSS? We're trying to avoid things like SASS unless the project specifically requires or teaches it. Also, could you show us your prototype on CodePen or some other site?

lionel-rowe commented 5 years ago

Sure thing, I'll remove the SCSS in the final version (write with SCSS, compile to CSS, then do any cleanup needed). The student will barely need to touch the CSS, anyway — almost all required changes are in the HTML.

Is including Bootstrap OK? Zero knowledge required, but it's included as a dependency. IMO it better represents something you'd see in production, and it also helps reinforce the point that “semantic-looking” classes like .form-group are still meaningless to user agents.

I'll get a CodePen up over the next couple of days.

QuincyLarson commented 5 years ago

@lionel-rowe Awesome! I'm excited to see this.

We want to use as foundational tools as we can, which means we shouldn't use bootstrap.

It's OK for this to look rough. The focus shouldn't be on the design, but rather the specific accessibility considerations.

eschafer commented 5 years ago

Hi! I'm just starting to learn about freeCodeCamp, and love the concept. Thanks for all the work you're putting into this!

I had a few thoughts about this accessibility project:

lionel-rowe commented 5 years ago
  • The title sounds a little off to me. It makes it sound like there are lots of different kinds of websites you can build, and if you happen to need to build a site aimed directly at people with disabilities, this is how you do it. But in reality, all websites should be built this way. I'd narrow it down like in other projects - something like "Learn Accessibility by Building a User Feedback Survey"

Yeah that's sorta what I was trying to get at earlier, but I think your suggestion is better as it expresses the actual end "product". @QuincyLarson @scissorsneedfoodtoo thoughts?

  • Accessibility is a huge topic. I was just wondering how you'd figure out what to cover in a single project, or if this was something that could potentially be split into multiple projects.

This project won't cover every aspect of a11y by any stretch of the imagination. It's more of a beginner's tutorial that will teach the basics and hopefully provide a solid foundation for adopting it as a way of thinking about design.

Covering more advanced stuff, like how to make an SPA router accessible, is beyond the scope of this lesson and will most likely remain that way. Perhaps it could be incorporated into one of the React lessons, though.

  • I'm not sure if you're already doing this, but would it be possible to make sure that all the other projects in the curriculum are also accessible? That'd be a nice way to reinforce and normalize the concepts. And I don't necessarily mean explicitly talking about accessibility everywhere, just making sure that the code examples at least pass accessibility guidelines (which generally/ideally shouldn't be hard to do).

That's definitely a good ideal to aim for. Certainly anything that's clearly inaccessible (non-descriptive alt text, semantically incorrect markup, etc.) should be fixed IMO.

I should have the next version of this up shortly. Once that's up, I'd welcome code review (material covered, copy, pedagogical approach, etc.) if you'd like to contribute @eschafer ! :smile:

lionel-rowe commented 5 years ago

Live demos:

Questions:

Apologies about the delay in creating the various incremental versions 010..xx0. I'm aiming to finish a few of them today, but I may not finish all of them until next week.

zersiax commented 5 years ago

@eschafer I agree with you regarding the title. A smaller tweak than the one you are suggesting might be to make "for " into "that works for" , e.g. make a website that works for people with disabilities. That still has a ring of "This is a nitch thing" to it, but less so, and it indicates that accessibility is the focus of the exercises. What we need to get rid of is this mindset that somehow this is some specific thing you do for only websites that need to work for assistive technology. Accessibility is often thought of as this extra thing we do to make certain websites work for those people who can't use "normal" websites. We need to be very careful not to encourage that mindset, and I agree that the current title seems to be doing that rather strongly. @lionel-rowe I can't help you with the colors , as I am a blind developer myself, but what I can tell you is that the thing about article tags having their own semantic context for headings is correct, but ultimately rarely really observed. What I mean is that generally, screen readers don't really do much with article tags currently. Landmarks, like main, nav, footer etc are observed, but generic article tags tend not to do much at least to my knowledge. The discussion about multiple heading level 1's on one page is to my knowledge still on-goign, as is the topic about multiple

roles on one page, so I can't really give you a definitive answer on that one I'm afraid :-)

lionel-rowe commented 5 years ago

Awesome, thanks for the insight @zersiax !

I'm asking about h1s because my "finished" version has a main > h1 (the main page heading) and also a nav > h1 (the main heading for that specific nav element). In my opinion, it seems unsemantic to change the nav > h1 to an h2, and even less semantic to change the main > h1 to an h2. Ultimately though, I'd rather base this on how screen readers and other user agents parse things, rather than my own personal biases. :wink:

zersiax commented 5 years ago

@lionel-rowe I would lose the h1 above the nav and rely on the fact screen readers can jump to landmarks like a nav element for your instant jump instead. Having a heading 1 above your nav is somewhat non-standard. You could add an h2 to the nav, if your site title is an h1 and your main is also an h2, but you're right that adding an h2 to the nav f your main content is preceded by h1 is a bit odd.

lionel-rowe commented 5 years ago

@zersiax I'll probably keep the "skip to main content" link for the benefit of keyboard-first or keyboard-only users who aren't using screen readers, though I wasn't aware that modern screen readers include that functionality - good to know!

If h1 isn't suitable for the secondary-nav heading, what would be the most semantic way to mark it up? I suppose I could just use a plain div and style it. The "before" version uses strong, which I think is definitely (intentionally) wrong from a semantic standpoint.

zersiax commented 5 years ago

You could just not have a heading before the nav, which solves the semantics issue. I actually quite rarely see headings above main navigation bars. When I see them, generally the site title is a heading 1, which actually is rather useless but solves the issue, making the sections (navigation, main, etc) heading two's below the context of the entire page. If you want to have a heading 1 above the nav bar, I guess you could wrap that navbar in a header and argue that the h1 is the main element in that semantic context, making the second heading 1 the top of your main content in a

element. I'd generally just say not to use any semantic markup above your navbar, though. Screen readers landing on a
lionel-rowe commented 5 years ago

You could just not have a heading before the nav, which solves the semantics issue. I actually quite rarely see headings above main navigation bars.

@zersiax The rationale for the heading is that it's a secondary nav for the specialized purpose of displaying links to previous events. The whole thing is kinda contrived anyway, as they're fictitious events for a pretend organization. :wink:

Due to the specialized purpose, perhaps this shouldn't be a nav at all? I could make it an aside or something, instead.

lionel-rowe commented 5 years ago

I've removed all dependencies and updated PR #152 with steps 020 to 230.

@scissorsneedfoodtoo Does my numbering follow the convention correctly? Switching between changes to the HTML and CSS files, I'm just continuing to increment the numbers each time (e.g. index010.html => style020.css => index030.html).

scissorsneedfoodtoo commented 5 years ago

Hi everyone, great discussion here. @eschafer, you bring up a good point about narrowing the scope of the title. Doing this will make the title read similarly to some of the other projects. Like @lionel-rowe mentioned, this project won't cover every aspect of designing for accessibility, so narrowing of the scope of the title and project is a good idea.

@zersiax, thank you for your insight! As you mentioned, we need to be careful with our wording and make sure students understand that the concepts taught here are meant to be used everywhere, not just with certain websites. I'm all for changing the title to what @eschafer suggested, "Learn Accessibility by Building a User Feedback Survey" and removing the "for" or "that works for People with Disabilities" entirely. Hopefully this will help reinforce the fact that we want to focus on accessibility with this project, and encourage accessibility design for all websites going forward.

@lionel-rowe, thank you for all of your hard work here! The site is looking great so far. As for the numbering convention, don't worry about it. All of the projects use a slightly different system and the numbering probably have to change once we start porting the projects to the updated platform.

RandellDawson commented 5 years ago

@lionel-rowe, @scissorsneedfoodtoo There is an open issue for the current curriculum that has some valid points. I am wondering if we should incorporate these points into this project?

scissorsneedfoodtoo commented 5 years ago

@RandellDawson, yes, we definitely should incorporate them. Thank you for bringing them to our attention!

lionel-rowe commented 5 years ago

I'm a little confused by that issue and not convinced it's entirely correct, will continue the discussion in that issue's thread.

lionel-rowe commented 5 years ago

PR #152 is now a complete first draft. It'd be great if someone could code review the new content.

scissorsneedfoodtoo commented 5 years ago

Hi @lionel-rowe, just wanted to check in and see how things are going. Your first draft was great! I really enjoyed going through your lessons and can't wait for fCC students to do the same.

Were you able to start working on a second draft by any chance? I left some review comments over in #152 that I hope will help when you take another pass at this project. Please feel to discuss them here or in your PR.

scissorsneedfoodtoo commented 5 years ago

Hi @lionel-rowe, just wondering if you were able to start on a second draft and break down this project into more steps. Please let us know your status and if there's anything we can help with!

lionel-rowe commented 5 years ago

Draft 2 should be coming shortly, though I'm somewhat swamped with work at the moment. Aiming for within the week.

scissorsneedfoodtoo commented 5 years ago

@lionel-rowe, that's great! Thank you for the update. Looking forward to seeing your next draft soon :+1: :+1:

scissorsneedfoodtoo commented 5 years ago

Hi @lionel-rowe, were you able to make any progress on a second draft?

scissorsneedfoodtoo commented 5 years ago

@lionel-rowe, just wanted to see if there's an update on your second draft.