[Suggestion] It will be better to divide this list in two categories 1) Visual designers and 2) Developers

[jitendravyas]

No description provided.

[Heydon]

I disagree. People write code that affects visual design (CSS). They have responsibility over (for example) color contrast — not just 'designers'. Also, this division of responsibilities forgets writers and information architects (and others!). You can divide this up as you like for your own purposes, but I prefer it as it is here.

[morajabi]

I suggest dividing by tags and categories (e.g. color, contrast, accessibility, etc) to be easier on eyes

[Heydon]

I'm not willing to do that, because I think it encourages pigeon-holing responsibilities by prescribed role. But as I said to @jitendravyas, you could divide up this list for yourself however you want.

[morajabi]

@Heydon OK!

Just one simple tip for involving in the open source world in Github. Since all of us are only talking by text in the issues and comments, we do not have access to changing voice tones, facial expressions and much more, we should speak with extended kindness and friendliness so no one will feel offended or feel somehow bad (maybe you don't mean it but as I said it's just plain text). We are all here to help each other and speaking a bit unfriendly can scare newcomers and push them back from speaking or contributing. 😊

It was my opinion from my recent experiences. If I was a newcomer to Github, maybe this way you expressed your preference (the 2 comments above) could scare me from talking in issues or making a new one anywhere else. As we know, we all want to help each other and we may not know what are the reasons someone is doing something.

I hope you won't take this in a bad way and hope I could say my point. I didn't mean anything bad just wanted to remind myself and others this tip.

Thank you for making this open source. 👏👌

[andrewhowdencom]

NRP radio show the other day suggested that in order for people to use checklists effectively they need to be chunked according to logical criteria, approx 7 - 8 items. How they're chunked doesn't matter -- just chunking them works.

https://www.npr.org/2017/10/30/559996276/the-trick-to-surviving-a-high-stakes-high-pressure-job-try-a-checklist

[cwbit]

+1 for Grouping by "thought" (topic), but not by responsibility (not by designer vs developer)

The topic grouping seems more natural (you yourself used it naturally in the opening line of the project)

Includes items for accessibility, performance, device support, interoperability, and language.

If your goal is to have the most extensive/inclusive list then to be usefully parse-able in the future it helps to have to have some sort of mental breakpoints.

Having everyone "divide the list up how [they] want" will make synchronization and maintenance for users more difficult, which will hamper adoption of the list.

For further backing of this idea, I'd point you right back to the checklist itself - specifically the letter and intent behind the following ...

• Provide alternatives and/or descriptions for complex visualizations
• Provide clear, unambiguous focus styles
• Make sure heading levels describe a logical section/subsection structure

One FINAL thought would be that grouping things then allows for numbering/labelling of topics and items so that they can be easily referenced.

This helps adoption as a standard, allowing commits, issues, etc to reference a specific checklist item. Example " blah blah needs to be brought into compliance with IDC A.2" or "please see IDC R.24 for clarification". JohnPapa's AngularJS Style Guide uses this idea with great success.

[danyalaytekin]

Great list. It has a good chance of becoming a regular place of pilgrimage for many of us so +1 for some kind of organisation (the version as suggested by @morajabi and @cwbit). It might also make it easier for the document's maintainers to avoid duplicates and overlaps as the list grows.

[AutoSponge]

Instead of grouping by technology (CSS/JS), how about grouping by pattern (forms, content, images, etc.).

[Heydon]

Nobody seems to be able to agree on how to group items, which I anticipated, and it's why the master list remains 'unchunked'. In the future, a small app that lets one filter by technology etc might be cool.

[andrewhowdencom]

It is indeed a hard problem. I would probably imagine people will accept any kind of grouping; simply establishing one will give some structure to the document - which doesn't matter so. I would pick the one with the most number of the "thumbs up" emoji in a week or so.

Still, can we stop and reflect on the irony that is we're discussing the usability of a usability checklist without resolution. :D

[Heydon]

@andrewhowdencom Leaving the list uncategorized is quite deliberate. It allows people to take the items and organize/omit them as they wish (according to their project requirements and organizational structure). In other words, making no assumptions about categories is more inclusive.

[tedw]

I agree in theory, but the list is hard to scan and will only get harder as more items are added. In the interest of getting more people to actually use it—which we all want—I’m on the side of grouping.

Vox did a good job of grouping items in their Accessibility Guidelines:

• Designers
• Engineers
• Project Managers
• QA
• Editorial

However, I would suggest using more general terms instead of job titles:

• Design
• Development
• Project Management
• Testing
• Editorial

Either way, looking forward to watching this list grow! Thanks, @Heydon, for starting this and for sharing so much a11y information over the years. My team and I eagerly await each new post on https://inclusive-components.design 😄

[Heydon]

@tedw Thank you for the kind words!

Those seem like sane categories to me. However, as I've said elsewhere, I don't want to make any assumptions over how orgs divide responsibilities. There are also things that could be considered both design and development etc and wanted to avoid long discussions over that ;-)

I think taking the items and forking (or just writing them up on post-its!) and then dividing them as suits your/anyone else's specific team should work?

[lazarljubenovic]

Would be the best if we could agree on human-and-machine-readable format for tagging items. Then it can be parsed and easily converted into a differently categorized lists. Thoughts?

[scottaohara]

isn't tagging an item the same as categorizing it?

or were you thinking potentially multiple tags per item?

[lazarljubenovic]

Yup, multiple tags per item in the list. Multiple tags will allow for both high-level and fine-grained categorization, and multiple types of categorization (per job title/field, per type -- accessibility, perf, etc). You can of course also have multiple tags from the same group: lots of things are both designers' and developers' responsibilities.

[Heydon]

I am more keen on tagging than categorizing, but uncertain about the 'how'. Should this master list be built from a JSON file of tagged entries?

[morajabi]

@Heydon Yes and no... it can be but to necessarily.

[lazarljubenovic]

I'd like to keep the list as a single markdown file that people can edit easily from the browser when contributing (or reading). I mean, you can edit everything from the browser no matter what extension it is, but then you'd have to be careful about JSON formatting which is easy to screw up: a missing comma, an additional comma, a missing quote...

How about listing tags as comma-separated values in {} after the checklist item?

- [ ] [Use content-based, not device-specific, media queries](http://bradfrost.com/blog/post/7-habits-of-highly-effective-media-queries/#content) {development, design, responsive, css}

I'd suggest [] instead of {} as it seems more human-readable but I'm afraid of clashing with markdown links. Then we can easily parse this to use for a website or whatever we're planning to have.

[Heydon]

@Heydon Yes and no... it can be but to necessarily.

I'm not sure what this is referring to, but if it's to my question "should this be in JSON?" then I am already aware that things can or cannot be in JSON. That's one of the facts of life. I mean "do we think this is a good way forward?"

[englishextra]

I bet, this awesome list is condemned from the start. Just find bravity to stop at some point.

[samnabi]

One person has already forked this repo and categorized it according to their particular workflow: https://github.com/BaseDesign/inclusive-design-checklist

It takes a lot of thoughtful consideration to group these tasks, and those groupings will change depending on the team!

I for one would encourage people to fork and group this list for themselves, according to their needs.

[englishextra]

@samnabi

fork and group this list for themselves, according to their needs.

That's what should be advised at the beginning of this very readme.

[mgifford]

@samnabi Ya, it's just too long and unorganized a list to maintain right now. Without order it's really hard to even know what is missing.

I forked it here:
https://github.com/mgifford/inclusive-design-checklist

then got a note from @Heydon after submitting a pull request pointing me here.

That's not a bad way to do it @tedw thanks for the suggestion.

[ireade]

Great work with this list @Heydon !

I think JSON is the way forward here. It'll still be relatively easy to edit, plus will allow as much customisability as possible. I created a fork with what I think the JSON file could look like - see checklist.json.

What do you think?

[Heydon]

@ireade Nice! I think we can have a tags property for each of those too, then we'll go some way to address concerns about categorization. I've been thinking about what might make legitimate tags. Probably:

• Visual design
• Structure
• Language
• Performance
• Ethics

(Sorry @mgifford, I'm not convinced about having "Accessibility" and "Accessible Design" etc. Drawing the line would be hard + I don't see design as purely visual.)

Thoughts on these welcome. Then we need to work out an easy way to compile the README.md from the JSON dynamically. Underscore? EJS? At the moment it's really easy to just add items in the markdown raw, so trying to keep the workflow simple would be great.

EDIT: Would be nice to have separate templates to generate categorized and uncategorized, linked and unlinked versions. That way we can all consume it as we wish.

[Andy-set-studio]

A little script could probably do that I reckon, @Heydon. Maybe a little node one that can be run with an npm task.

Happy to give it a go!

Also, great stuff on the JSON @ireade 🙂

[Heydon]

@hankchizljaw Absolutely, nothing special and no need for Grunt/Gulp etc. Best if it runs as a pre-commit task too. If you can help out there, great!

[mgifford]

@Heydon Ya the sections I came up with were just a first hack based on the list. The list is just too long. Like the idea of a JSON list though. looking forward to see how this goes. Then we can move to having it presented something like this https://github.com/uxchecklist/uxchecklist.github.io

Nice to have a solid presentation layer for folks. :)

[Andy-set-studio]

No worries, @Heydon. Glad to help!

[ireade]

@Heydon @hankchizljaw thanks! :)

@Heydon Regarding the tags, I think it will be difficult to find a tag structure that everyone agrees on. IMO I think you should categorise them as you see fit and we can add/change things if necessary from there. I like the initial tags you've suggested.

Should I submit a PR with the json file I created now? Or do you want to wait till after the tags have been decided on?

[Heydon]

@ireade Sure! Submit it now and then @hankchizljaw can work with it ;-) Thanks!

[Andy-set-studio]

Nice one ;)

I’ve got a hack night on weds, so I’ll probably put it together then 👍🏼

[ireade]

@Heydon Done :) #20

[Andy-set-studio]

So I've created a PR with the little generator script (#22).

As @Heydon mentioned, it'd be great to have this as a pre-commit hook. I've written the hook, but not sure how we want it to be shared as you can't commit .git/hooks. I'm cautious of making things too complicated, so left it out...

I'd really appreciate any opinions on this.

The hook

#!/bin/sh
# Check if this is the initial commit
if git rev-parse --verify HEAD >/dev/null 2>&1
then
node generator/index.js
git add README.md
exit 0
else 
exit 0
fi

[peter-mouland]

@hankchizljaw husky would be perfect for this sort of thing 👍
you would then simply add a package.json with a precommit task which points to your script

[ireade]

Hey all! (cc @Heydon )

I've been playing around with how to add tags to the checklist, and created a fork with what I think is a good starting point (see - https://github.com/ireade/inclusive-design-checklist/blob/master/checklist.json)

These were the tags I came up with (based on Heydon's original suggestions):

• Visual Design
• Content
• Implementation
  • HTML
  • CSS
  • JS
• Performance
• Ethics

I liked the idea of subcategorising things (e.g. how I added extra tags to the Implementation tag to get more specific). This could be useful for allowing people to separate things by role. E.g. someone who just works with HTML/CSS or someone who just works with JS.

What do you think?

[Andy-set-studio]

I like it, @ireade.

I like the idea of subtags. Maybe tags should be structured like objects though to make things in the generator a touch easier:

{
  "name": "Implementation",
  "children": [
    {
      "name": "HTML"
    },
    {
       "name": "CSS"
    }
  ]
}

If we were to play with that approach, how many levels would we go?

If we kept it shallow, I could get the generator to group stuff into a nice heading structure.

What do you think?

Edit: formatting.

[ireade]

Thanks @hankchizljaw !

I like the idea, but I'm worried that using this structure may add too much of an overhead. I think we should have a flat tag structure as much as possible for simplicity. My idea of subcategorisation doesn't necessarily mean it should appear subcategorised, I just meant it as a way for people to search more specifically within a broader category. I assume that, if/when a proper UI is built for this checklist, the notion of nesting the tags could be more adequately handled there.

[Andy-set-studio]

Fair point @ireade. I suppose multiple tags would give us filtering options if/when there's a UI to work with too 🙂

[Heydon]

@hankchizljaw @ireade Thanks for the discussion!

• I think subdivision by technology is an interesting idea
• I do think the structure should remain as simple as possible, though. I want people to feel they are able to hand-add entries into the JSON. It doesn't have to be their responsibility to tag, of course (and we certainly don't want to enforce adding tags in validation or anything) but still.

[Andy-set-studio]

Tagging could be a good opportunity for someone to contribute. If we make it known that it's more than ok to add an item that's untagged, someone else can jump in a create a PR that tags it. A proper community effort can be achieved then 🙂