The Great Redesign : 2015 #324

Closed
grayghostvisuals opened this Issue Feb 24, 2015 · 48 comments

Comments

Projects
None yet
6 participants
@grayghostvisuals
Contributor

grayghostvisuals commented Feb 24, 2015

Ok so here's what is happening. I've been breaking things down to the bare metal on the redesign branch. Basically removing bootstrap classes and useless scripts / files no longer needed. I also removed the rake file because it drives me nuts. I think we can use better tooling in this area.

Noteworthy Aspects

  • Bootstrap is removed
  • Rake file is removed
  • Compass is removed

Using Sass is a must going forward. I suggest libsass based on our use with the current site. We were not using much Compass anyways and it's slow so lets go with node based tooling instead. Looking forward to the new design everyone. Feel free to let us know if you are attacking something relating to the design so we know :)

@heitzke

This comment has been minimized.

Show comment
Hide comment
@heitzke

heitzke Feb 24, 2015

Contributor

Nice! I'd love a gulp/grunt workflow here.

Also noteworthy from the other redesign PR was Dave's codepen work on the articles: http://codepen.io/davatron5000/pen/PwQgwM - Looks pretty clean

Contributor

heitzke commented Feb 24, 2015

Nice! I'd love a gulp/grunt workflow here.

Also noteworthy from the other redesign PR was Dave's codepen work on the articles: http://codepen.io/davatron5000/pen/PwQgwM - Looks pretty clean

@grayghostvisuals

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals Feb 24, 2015

Contributor

@heitzke Definitely! Thanks for the forgotten link from Dave 👍

Contributor

grayghostvisuals commented Feb 24, 2015

@heitzke Definitely! Thanks for the forgotten link from Dave 👍

@heitzke

This comment has been minimized.

Show comment
Hide comment
@heitzke

heitzke Mar 2, 2015

Contributor

I've been tinkering with a gulp workflow this weekend to handle the asset task running, but also keep jekyll rolling for the template work. Right now it's watching all the scss/js/images, compiles them out normally and then copies them into the _site build. It's sort of cool, but don't know if this is getting too complex

Contributor

heitzke commented Mar 2, 2015

I've been tinkering with a gulp workflow this weekend to handle the asset task running, but also keep jekyll rolling for the template work. Right now it's watching all the scss/js/images, compiles them out normally and then copies them into the _site build. It's sort of cool, but don't know if this is getting too complex

@davatron5000

This comment has been minimized.

Show comment
Hide comment
@davatron5000

davatron5000 Mar 2, 2015

Contributor

If it's just Sass, we could do Jekyll's default Sass compilation (supported by Github). http://jekyllrb.com/docs/assets/#sassscss

And then for JS... I dunno. We don't have lots of JS, so maybe it's fine in a couple files. We could even scope things like Garlic.js to just the Checklist.

Contributor

davatron5000 commented Mar 2, 2015

If it's just Sass, we could do Jekyll's default Sass compilation (supported by Github). http://jekyllrb.com/docs/assets/#sassscss

And then for JS... I dunno. We don't have lots of JS, so maybe it's fine in a couple files. We could even scope things like Garlic.js to just the Checklist.

@heitzke

This comment has been minimized.

Show comment
Hide comment
@heitzke

heitzke Mar 3, 2015

Contributor

Yeah that's true. The more I think about it, the more that a gulp flow could be more of an obstacle to contribution than be helpful for all.

Contributor

heitzke commented Mar 3, 2015

Yeah that's true. The more I think about it, the more that a gulp flow could be more of an obstacle to contribution than be helpful for all.

@joe-watkins

This comment has been minimized.

Show comment
Hide comment
@joe-watkins

joe-watkins Apr 8, 2015

Contributor

Hi team,.. just checking in on this topic. @grayghostvisuals is there anything I can help with? Feel free to hit me with some tasks. Have we considered Yeoman's Jekyll I use it for my site and it's pretty sweet. Grunt-based using Sass.

Contributor

joe-watkins commented Apr 8, 2015

Hi team,.. just checking in on this topic. @grayghostvisuals is there anything I can help with? Feel free to hit me with some tasks. Have we considered Yeoman's Jekyll I use it for my site and it's pretty sweet. Grunt-based using Sass.

@heitzke

This comment has been minimized.

Show comment
Hide comment
@heitzke

heitzke Apr 8, 2015

Contributor

That sounds pretty promising actually. I've been slacking :-\

Contributor

heitzke commented Apr 8, 2015

That sounds pretty promising actually. I've been slacking :-\

@grayghostvisuals

This comment has been minimized.

Show comment
Hide comment
Contributor

grayghostvisuals commented Apr 8, 2015

@davatron5000

This comment has been minimized.

Show comment
Hide comment
@davatron5000

davatron5000 Apr 8, 2015

Contributor

@joe-watkins Yeoman Jekyll might be fine, but does it deploy/compile on Github Pages? That's my biggest question. I really think the /sass/ directory stuff in Jekyll 2 might be the best way forward since we know it's supported by Github.

For Javascript, we use very little right now (possibly even less in the redesign). So I don't think a JS compiler is super necessary at the moment.

Contributor

davatron5000 commented Apr 8, 2015

@joe-watkins Yeoman Jekyll might be fine, but does it deploy/compile on Github Pages? That's my biggest question. I really think the /sass/ directory stuff in Jekyll 2 might be the best way forward since we know it's supported by Github.

For Javascript, we use very little right now (possibly even less in the redesign). So I don't think a JS compiler is super necessary at the moment.

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Jun 26, 2015

Member

I've been lurking around a11y for a few months, hoping I'd get some time between projects to help out with this redesign. Can I help make this redesign happen? I've played around with jekyll in the past and enjoy using Sass, compiled with libsass on a gulp workflow and Susy for layouts. I'm open to other workflows though.

Could I start by expanding the goals of the a11yproject into design goals for the site?

Member

jeryj commented Jun 26, 2015

I've been lurking around a11y for a few months, hoping I'd get some time between projects to help out with this redesign. Can I help make this redesign happen? I've played around with jekyll in the past and enjoy using Sass, compiled with libsass on a gulp workflow and Susy for layouts. I'm open to other workflows though.

Could I start by expanding the goals of the a11yproject into design goals for the site?

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Jul 10, 2015

Member

I wrote up design goals and ideas of how to implement them. Is there a better place to post this to make it more community editable? And can I get some feedback if these goals are appropriate to move forward with?

Primary Goals

Make web accessibility easier for developers to implement.

  • Make it easy.
    • You can never learn enough being a developer. Convince them it's worth their time to learn how to make their sites more accessible.
    • Teach them something useful they can implement in their code within the first 20s they're at the site.
    • Show how a few key changes can make a website go from annoying to usable.
    • Personalize accessibility. Use short stories from people who deal with web accessiblity issues everyday?
  • Be Forgiving.
    • Make people feel good about what they're learning, rather than feel bad for the lack of accessibility in their past code.
  • Encourage community.
    • We're all learning and improving. Join us in making the web more accessible.

Additional Design Goals

  • Make sure people know that information is up-to-date.
  • Quickly communicate what kinds of content are on the a11y project website.

Users

Should we make any assumptions, to allow for different users to easily segment themselves?

  • Back-End Developers
  • Front-End Developers
  • Designers
  • People to who use accessibility technology to use the web? Give them a way to share their frustrations, knowledge, and experiences? I'm thinking of the user MarjaE2 who opened #341
Member

jeryj commented Jul 10, 2015

I wrote up design goals and ideas of how to implement them. Is there a better place to post this to make it more community editable? And can I get some feedback if these goals are appropriate to move forward with?

Primary Goals

Make web accessibility easier for developers to implement.

  • Make it easy.
    • You can never learn enough being a developer. Convince them it's worth their time to learn how to make their sites more accessible.
    • Teach them something useful they can implement in their code within the first 20s they're at the site.
    • Show how a few key changes can make a website go from annoying to usable.
    • Personalize accessibility. Use short stories from people who deal with web accessiblity issues everyday?
  • Be Forgiving.
    • Make people feel good about what they're learning, rather than feel bad for the lack of accessibility in their past code.
  • Encourage community.
    • We're all learning and improving. Join us in making the web more accessible.

Additional Design Goals

  • Make sure people know that information is up-to-date.
  • Quickly communicate what kinds of content are on the a11y project website.

Users

Should we make any assumptions, to allow for different users to easily segment themselves?

  • Back-End Developers
  • Front-End Developers
  • Designers
  • People to who use accessibility technology to use the web? Give them a way to share their frustrations, knowledge, and experiences? I'm thinking of the user MarjaE2 who opened #341
@davatron5000

This comment has been minimized.

Show comment
Hide comment
@davatron5000

davatron5000 Jul 21, 2015

Contributor

Hey @jeryj,
I thought I'd pick up the Twitter conversation here. I think your outline is spot on. I don't think there's much need to segment people. If there were segmentations I'd probably take "back-end" off the list since very little of the back-end (other than spitting out HTML) affects accessibility.

2min catch up

Just to catch up on design. I started on an Article Component trying to make things a little more easier to read (bit larger font size, more open line-height). If you've got a better typeset ideas, by all means go ahead. I'm not attached to anything.

It might help if we break out site down into atomic components, we have:

  • header
    • logo
    • responsive navigation
  • list of articles
  • category subnav
  • article
    • headings
    • code blocks
    • lists
  • resource/pattern grid
  • checklist
  • footer
    • contributors
    • Google Translate

Hopefully that helps tell you where we're at and where we need to go. Would love to hear/see your thoughts.

Contributor

davatron5000 commented Jul 21, 2015

Hey @jeryj,
I thought I'd pick up the Twitter conversation here. I think your outline is spot on. I don't think there's much need to segment people. If there were segmentations I'd probably take "back-end" off the list since very little of the back-end (other than spitting out HTML) affects accessibility.

2min catch up

Just to catch up on design. I started on an Article Component trying to make things a little more easier to read (bit larger font size, more open line-height). If you've got a better typeset ideas, by all means go ahead. I'm not attached to anything.

It might help if we break out site down into atomic components, we have:

  • header
    • logo
    • responsive navigation
  • list of articles
  • category subnav
  • article
    • headings
    • code blocks
    • lists
  • resource/pattern grid
  • checklist
  • footer
    • contributors
    • Google Translate

Hopefully that helps tell you where we're at and where we need to go. Would love to hear/see your thoughts.

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Jul 21, 2015

Member

@davatron5000, Thanks for taking time to respond. That all makes a lot of sense to me.

Would a good first step be for me to make a broad style guide (goal summary, colors, typography), then start applying styles to specific atomic components? Basically, create more CodePens like the article you made? I really like the articles that include the "Short Answer" and "Rule of Thumb" tip.

Source Sans Pro looks like a good choice. It's got all the essential characters and glyphs, it's readable for headings and paragraphs, lots of language support, reflects a modern style that I think a lot of devs and designers dig, and it isn't Helvetica :)

When reviewing typefaces, should we limit to only open source? For example, I have a typekit account, but should I not look there? I don't imagine looking much, but if I did, I wouldn't want to waste time looking at typefaces that can't be used. I would primarily be looking at pairings for Source Sans Pro.

Also, is CodePen the best place to post these style guides and components for now so everyone can easily see and collaborate without having to git pull just to check out the proposed styles?

Looking forward to getting started :)

Member

jeryj commented Jul 21, 2015

@davatron5000, Thanks for taking time to respond. That all makes a lot of sense to me.

Would a good first step be for me to make a broad style guide (goal summary, colors, typography), then start applying styles to specific atomic components? Basically, create more CodePens like the article you made? I really like the articles that include the "Short Answer" and "Rule of Thumb" tip.

Source Sans Pro looks like a good choice. It's got all the essential characters and glyphs, it's readable for headings and paragraphs, lots of language support, reflects a modern style that I think a lot of devs and designers dig, and it isn't Helvetica :)

When reviewing typefaces, should we limit to only open source? For example, I have a typekit account, but should I not look there? I don't imagine looking much, but if I did, I wouldn't want to waste time looking at typefaces that can't be used. I would primarily be looking at pairings for Source Sans Pro.

Also, is CodePen the best place to post these style guides and components for now so everyone can easily see and collaborate without having to git pull just to check out the proposed styles?

Looking forward to getting started :)

@heitzke

This comment has been minimized.

Show comment
Hide comment
@heitzke

heitzke Jul 22, 2015

Contributor

The idea of designing component by component out in the open sounds pretty fun.

Seems that shooting for an open font helps reinforce it 'being for everyone', but that may be a little idealistic. Open Sans feels pretty good, has a little less motion than Source. Lato might be another good option to entertain, although it can get light pretty easily.

Contributor

heitzke commented Jul 22, 2015

The idea of designing component by component out in the open sounds pretty fun.

Seems that shooting for an open font helps reinforce it 'being for everyone', but that may be a little idealistic. Open Sans feels pretty good, has a little less motion than Source. Lato might be another good option to entertain, although it can get light pretty easily.

@grayghostvisuals

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals Jul 22, 2015

Contributor

Since everyone and their grandmother uses Open Sans, my suggestion w/type: make it easy to read and choose a font that fits the purpose and tone of the project. Think of words like humble, patient, warm, cozy etc. Just making words up, but hopefully the point gets across 🐻

Contributor

grayghostvisuals commented Jul 22, 2015

Since everyone and their grandmother uses Open Sans, my suggestion w/type: make it easy to read and choose a font that fits the purpose and tone of the project. Think of words like humble, patient, warm, cozy etc. Just making words up, but hopefully the point gets across 🐻

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Jul 22, 2015

Member

@heitzke It does sound fun! My only concern is keeping everything consistent so we don't have to make changes on every pen when we make a new change. Also, I think it'll be easy for people to lose scope if they're all too separated. Can we pack it all into one codepen? Basically an overly simplified PatternLab.

@grayghostvisuals - I agree :) Except, I'd add serious and professional to the list too.

Our typeset needs to be like a parent who just found out that their child flushed an heirloom down the toilet, and addresses the situation with forgiveness, patience, understanding, and love, but also seriousness and authority so it doesn't happen again :)

I don't think it'll be too hard. We don't need the typeset to stand out here, more so just not hurt us by setting the wrong tone.

Member

jeryj commented Jul 22, 2015

@heitzke It does sound fun! My only concern is keeping everything consistent so we don't have to make changes on every pen when we make a new change. Also, I think it'll be easy for people to lose scope if they're all too separated. Can we pack it all into one codepen? Basically an overly simplified PatternLab.

@grayghostvisuals - I agree :) Except, I'd add serious and professional to the list too.

Our typeset needs to be like a parent who just found out that their child flushed an heirloom down the toilet, and addresses the situation with forgiveness, patience, understanding, and love, but also seriousness and authority so it doesn't happen again :)

I don't think it'll be too hard. We don't need the typeset to stand out here, more so just not hurt us by setting the wrong tone.

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Jul 22, 2015

Member

I forked @davatron5000's codepen and stripped down the html for the pen. I used Source Sans Pro for headings and paragraphs, but am definitely not 100% committed to them. I think they work fine though. I increased the font size to get a character count per line closer to 75. It's 84-ish on this pen, so it could still be reduced more if people feel strongly enough about it. I am a fan of having the smaller text though, since I think it gives it more of a textbook or technical document feel to it.

Here's my forked article codepen.

I have a few questions about some elements though:

  • Edit on Github button - I like that this communicates it's an open source site that encourages community and learning. But, should we have it be in the footer of the article instead? It's not very useful for someone to click on it and edit it before even reading the article.
  • Bootstrap Lingering Styles - Can we remove the underlines and change up the colors? Right now the color palette and feel is still very Bootstrap inspired. I'd recommend still staying with neutral colors that don't stand out a ton, but creating an environment that's more welcoming. I'm happy to explore those options.
  • In general - What needs to remain consistent and what is open for adaptation? Is it OK to question the placement of all things, or is that more in-depth of a redesign than we're really trying to accomplish here?
Member

jeryj commented Jul 22, 2015

I forked @davatron5000's codepen and stripped down the html for the pen. I used Source Sans Pro for headings and paragraphs, but am definitely not 100% committed to them. I think they work fine though. I increased the font size to get a character count per line closer to 75. It's 84-ish on this pen, so it could still be reduced more if people feel strongly enough about it. I am a fan of having the smaller text though, since I think it gives it more of a textbook or technical document feel to it.

Here's my forked article codepen.

I have a few questions about some elements though:

  • Edit on Github button - I like that this communicates it's an open source site that encourages community and learning. But, should we have it be in the footer of the article instead? It's not very useful for someone to click on it and edit it before even reading the article.
  • Bootstrap Lingering Styles - Can we remove the underlines and change up the colors? Right now the color palette and feel is still very Bootstrap inspired. I'd recommend still staying with neutral colors that don't stand out a ton, but creating an environment that's more welcoming. I'm happy to explore those options.
  • In general - What needs to remain consistent and what is open for adaptation? Is it OK to question the placement of all things, or is that more in-depth of a redesign than we're really trying to accomplish here?
@davatron5000

This comment has been minimized.

Show comment
Hide comment
@davatron5000

davatron5000 Jul 22, 2015

Contributor
  • Edit on Github: Yeah, could go anywhere. I like that it's obvious up top. Either way tho.
  • Lingering styles: Yeah play with colors all you want. There's some accessibility concerns when it comes to links.
    • We want to pass WCAG AA for large and small text.
    • Links should probably have an underline and try to get close to the 3:1 contrast ratio
  • In general: Feel free to question whatever. I don't think anyone is too overly attached. I'd probably argue getting something up and out that we can nudge later is pretty key.

Thanks for your help on this.

Contributor

davatron5000 commented Jul 22, 2015

  • Edit on Github: Yeah, could go anywhere. I like that it's obvious up top. Either way tho.
  • Lingering styles: Yeah play with colors all you want. There's some accessibility concerns when it comes to links.
    • We want to pass WCAG AA for large and small text.
    • Links should probably have an underline and try to get close to the 3:1 contrast ratio
  • In general: Feel free to question whatever. I don't think anyone is too overly attached. I'd probably argue getting something up and out that we can nudge later is pretty key.

Thanks for your help on this.

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Jul 28, 2015

Member

Thanks for the info - that's all great to know for going forward. I'll start with a 3:1 contrast ratio for links and build up from there.

I'm on vacation this week, so I'll work more on it when I get back. I should have some downtime to read through WCAG AA this week before I make any design decisions. Thanks for mentioning that.

Member

jeryj commented Jul 28, 2015

Thanks for the info - that's all great to know for going forward. I'll start with a 3:1 contrast ratio for links and build up from there.

I'm on vacation this week, so I'll work more on it when I get back. I should have some downtime to read through WCAG AA this week before I make any design decisions. Thanks for mentioning that.

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Aug 10, 2015

Member

So, I've done a bunch of work on the redesign branch. Rather than reiterate everything little thing I did, it's probably easiest to get the details from the commits on my pull request. Basically, the base theme is there. Here's a desktop screenshot.

a11y-redesign

We can add more complexity as needed. Here's a few things that I think could happen:

  • The category sidebar is sticky and uses waypoints js to highlight which category you're on. What do you all think about having a similar solution for the Patterns and Resources pages? And should we use a smooth scroll technique for the internal links? Or is that an animation concern that could trigger some users?
  • I think the "Quick tips" section should come first on the homepage. It would allow people to instantly learn something and see how easy it is to start improving their code's accessibility. I could figure out how to make this happen, but it'd probably take me a bit to look into jekyll's sorting and looping and probably wouldn't be as efficient as someone else who knows jekyll well.

ToDo

  • Add a text resize button for users to increase font size up to 200% to meet WCAG 2.0 AA.
  • Check typography with WCAG 2.0 AA.
  • Improve small screen table of contents category menu on homepage. Right now it's just a list at the top of the page. Could look nicer and provide better functionality. I generally don't like sticky stuff on small pages, but this could be useful. Any ideas?
  • I'm sure lots of other things to meet WCAG.
  • Reduce size of the images being loaded in the github contributor section. We don't need to be loading 460px images.

Comments? Thoughts?

Member

jeryj commented Aug 10, 2015

So, I've done a bunch of work on the redesign branch. Rather than reiterate everything little thing I did, it's probably easiest to get the details from the commits on my pull request. Basically, the base theme is there. Here's a desktop screenshot.

a11y-redesign

We can add more complexity as needed. Here's a few things that I think could happen:

  • The category sidebar is sticky and uses waypoints js to highlight which category you're on. What do you all think about having a similar solution for the Patterns and Resources pages? And should we use a smooth scroll technique for the internal links? Or is that an animation concern that could trigger some users?
  • I think the "Quick tips" section should come first on the homepage. It would allow people to instantly learn something and see how easy it is to start improving their code's accessibility. I could figure out how to make this happen, but it'd probably take me a bit to look into jekyll's sorting and looping and probably wouldn't be as efficient as someone else who knows jekyll well.

ToDo

  • Add a text resize button for users to increase font size up to 200% to meet WCAG 2.0 AA.
  • Check typography with WCAG 2.0 AA.
  • Improve small screen table of contents category menu on homepage. Right now it's just a list at the top of the page. Could look nicer and provide better functionality. I generally don't like sticky stuff on small pages, but this could be useful. Any ideas?
  • I'm sure lots of other things to meet WCAG.
  • Reduce size of the images being loaded in the github contributor section. We don't need to be loading 460px images.

Comments? Thoughts?

@davatron5000

This comment has been minimized.

Show comment
Hide comment
@davatron5000

davatron5000 Aug 12, 2015

Contributor

@jeryj hey! this looks good. Thoughts:

  • Not all pages would have the "jumbotron", so maybe a flat color instead of the gradient is a better choice?
  • I can make the Quick Tips come first.
  • Like the waypoints idea. interested to see it on resources pages. I sorta worry about scroll fatigue. but right now we have density fatigue. so let's try it?
  • I wouldn't worry about adding a text resize button at the moment, that can all be handled in browser.
  • re: small-screen subnavigation - we could maybe look at something like an Accordion-to-Full pattern (never ran that through a screen reader tho)
Contributor

davatron5000 commented Aug 12, 2015

@jeryj hey! this looks good. Thoughts:

  • Not all pages would have the "jumbotron", so maybe a flat color instead of the gradient is a better choice?
  • I can make the Quick Tips come first.
  • Like the waypoints idea. interested to see it on resources pages. I sorta worry about scroll fatigue. but right now we have density fatigue. so let's try it?
  • I wouldn't worry about adding a text resize button at the moment, that can all be handled in browser.
  • re: small-screen subnavigation - we could maybe look at something like an Accordion-to-Full pattern (never ran that through a screen reader tho)
@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Aug 12, 2015

Member

@davatron5000 Thanks for the input!

Ha! Jumbotron - that's perfect and the first time I've heard it called that. The rest of the pages have zero jumbotrons, just a flat color behind the little header. Here's a screenshot:

everything but homepage design

I used the gradient to make the distinction between the jumbotron and content more distinct, but there could easily just be a border like on the rest of the pages, or no border and not worry about it. Whatever people like best is fine by me. I'm not overly picky or attached here.

  • Quick Tips- Thanks! I'll be interested to see how you do it.
  • Waypoints on Resources- I'll give it a try and we can see how it feels.
  • Text Resize-The text resize thought was to overly-satisfy criterion 1.4.4 - Resize Text (AA level). It's a little vague, because pretty much all browsers can handle it. In the understanding section for Resize Text, they end up saying: "The author cannot rely on the user agent to satisfy this Success Criterion for HTML content if users do not have access to a user agent with zoom support. For example, if they work in an environment that requires them to use IE 6."
    So, I don't know. I could go either way. I think the design is clean and open enough to easily add it without it feeling cluttered. But, I also think the font is already on the larger end and if IE6 is the only browser that doesn't have zoom support, I don't see much of a reason to add a feature just for IE6.
  • Accordion to Full - Nice! Thanks for the input there. Simple and effective. I was testing an accordion on a screen reader yesterday, actually. I think as long as we code it with <a> tags to open/close sections, we'll be fine. OR - we DON'T use <a> tags and hide/show with CSS classes via javascript.
    Actually, how about this: The HTML already has a table of contents (TOC) that internally links to the headings. What if we add the class="screen-reader-text" to the TOC if the window is not wide enough to accommodate the waypoints sidebar-TOC. Then, to a screen reader, the content flow is identical. Now, we make sure we DON'T hide content on the accordion via display: none; but rather overflow: hidden; and animate the open/close with CSS. That way, everything is still accessible and navigable on screen readers, but condensed visually for small screen devices. Then, we add/remove classes for open/close of accordion via js on click to the headings. Sound reasonable? Am I missing anything obvious here?

P.S. @davatron5000, Word on the tweet is that you gave a killer AEA talk. I enjoyed your picture of the ways to spot the CEO/Designer/Coder via their attire :)

Member

jeryj commented Aug 12, 2015

@davatron5000 Thanks for the input!

Ha! Jumbotron - that's perfect and the first time I've heard it called that. The rest of the pages have zero jumbotrons, just a flat color behind the little header. Here's a screenshot:

everything but homepage design

I used the gradient to make the distinction between the jumbotron and content more distinct, but there could easily just be a border like on the rest of the pages, or no border and not worry about it. Whatever people like best is fine by me. I'm not overly picky or attached here.

  • Quick Tips- Thanks! I'll be interested to see how you do it.
  • Waypoints on Resources- I'll give it a try and we can see how it feels.
  • Text Resize-The text resize thought was to overly-satisfy criterion 1.4.4 - Resize Text (AA level). It's a little vague, because pretty much all browsers can handle it. In the understanding section for Resize Text, they end up saying: "The author cannot rely on the user agent to satisfy this Success Criterion for HTML content if users do not have access to a user agent with zoom support. For example, if they work in an environment that requires them to use IE 6."
    So, I don't know. I could go either way. I think the design is clean and open enough to easily add it without it feeling cluttered. But, I also think the font is already on the larger end and if IE6 is the only browser that doesn't have zoom support, I don't see much of a reason to add a feature just for IE6.
  • Accordion to Full - Nice! Thanks for the input there. Simple and effective. I was testing an accordion on a screen reader yesterday, actually. I think as long as we code it with <a> tags to open/close sections, we'll be fine. OR - we DON'T use <a> tags and hide/show with CSS classes via javascript.
    Actually, how about this: The HTML already has a table of contents (TOC) that internally links to the headings. What if we add the class="screen-reader-text" to the TOC if the window is not wide enough to accommodate the waypoints sidebar-TOC. Then, to a screen reader, the content flow is identical. Now, we make sure we DON'T hide content on the accordion via display: none; but rather overflow: hidden; and animate the open/close with CSS. That way, everything is still accessible and navigable on screen readers, but condensed visually for small screen devices. Then, we add/remove classes for open/close of accordion via js on click to the headings. Sound reasonable? Am I missing anything obvious here?

P.S. @davatron5000, Word on the tweet is that you gave a killer AEA talk. I enjoyed your picture of the ways to spot the CEO/Designer/Coder via their attire :)

@grayghostvisuals

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals Aug 12, 2015

Contributor

Just wanted to say the single articles design looks really great. Love that the typography is being brought to attention and focused on the reading experience as the priority.

Contributor

grayghostvisuals commented Aug 12, 2015

Just wanted to say the single articles design looks really great. Love that the typography is being brought to attention and focused on the reading experience as the priority.

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Aug 12, 2015

Member

@grayghostvisuals Awesome! Glad to hear we're on the right track.

Member

jeryj commented Aug 12, 2015

@grayghostvisuals Awesome! Glad to hear we're on the right track.

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Aug 13, 2015

Member

I added waypoints to the Resources page and altered the menu to be left aligned. With so many categories, it was difficult to read a right aligned list. I also had to widen it to account for some categories wrapping to a new line. This amount of items is definitely pushing the limit to the usefulness of this waypoints category pattern.

Here's a screenshot of it.

resources page layout on desktop

If we decide to use this, we'd need to add some code to stop the list as it hit the footer. Right now it just slides behind the footer. Also, we'd need to tweak the set-up so that it "feels" right when you hit the corresponding section from the categories list.

I think this waypoints set-up is OK for the resources page, but definitely not perfect.

Does anyone think it'd be better on the right side for the longer list? And maybe rather than sinking time into perfecting the waypoint active class on the category menu, just remove it from the long list and only do that on the homepage?

Member

jeryj commented Aug 13, 2015

I added waypoints to the Resources page and altered the menu to be left aligned. With so many categories, it was difficult to read a right aligned list. I also had to widen it to account for some categories wrapping to a new line. This amount of items is definitely pushing the limit to the usefulness of this waypoints category pattern.

Here's a screenshot of it.

resources page layout on desktop

If we decide to use this, we'd need to add some code to stop the list as it hit the footer. Right now it just slides behind the footer. Also, we'd need to tweak the set-up so that it "feels" right when you hit the corresponding section from the categories list.

I think this waypoints set-up is OK for the resources page, but definitely not perfect.

Does anyone think it'd be better on the right side for the longer list? And maybe rather than sinking time into perfecting the waypoint active class on the category menu, just remove it from the long list and only do that on the homepage?

@joe-watkins

This comment has been minimized.

Show comment
Hide comment
@joe-watkins

joe-watkins Aug 13, 2015

Contributor

@jeryj "Does anyone think it'd be better on the right side for the longer list?"

I'd say there would be a benefit to having it in the left column so AT/keyboard only users could get to that handy-dandy feature sooner since it would hit sooner in the markup.

Contributor

joe-watkins commented Aug 13, 2015

@jeryj "Does anyone think it'd be better on the right side for the longer list?"

I'd say there would be a benefit to having it in the left column so AT/keyboard only users could get to that handy-dandy feature sooner since it would hit sooner in the markup.

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Aug 13, 2015

Member

I completely agree that we shouldn't compromise the markup in order to move it to the right. It'd take a little bit of work, but it is doable to float it to the right and rework the waypoint to be fixed on the right. Here's a screenshot of it floated right with the same markup.

Resources page category sidebar right

Member

jeryj commented Aug 13, 2015

I completely agree that we shouldn't compromise the markup in order to move it to the right. It'd take a little bit of work, but it is doable to float it to the right and rework the waypoint to be fixed on the right. Here's a screenshot of it floated right with the same markup.

Resources page category sidebar right

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Aug 21, 2015

Member

Here's where I'm at with the Accordion view. I'd love feedback and help on this, as I feel a little stuck.

My thoughts:

  • If we do an accordion pattern, it doesn't make sense to have a Table of Contents first. This is what I did on my first attempt. Left both the TOC and the accordion and didn't worry about showing the content for screen readers. It worked fine, but it felt really weird to not be able to open the accordion content via the screen reader.
  • Then, I went with leaving the TOC and implementing something that the screen reader could open via keyboard commands. After checking that out, it also felt weird because I had a TOC that linked to the title of the accordion, that you then had to click to open.
  • Finally, I removed the TOC and implemented the accordion-to-full pattern that @davatron5000 mentioned earlier. It seems sporadic when the tabpanel semantics are honored and when they aren't. I'm not familiar enough with these semantics to make a decisive decision, I don't have any other screen readers to test with.

The JS I wrote for it isn't very well structured right now (I know there are some bugs). I'm not going to worry about it until we have a definitive route to go with it.

So, yeah. Any ideas?

Member

jeryj commented Aug 21, 2015

Here's where I'm at with the Accordion view. I'd love feedback and help on this, as I feel a little stuck.

My thoughts:

  • If we do an accordion pattern, it doesn't make sense to have a Table of Contents first. This is what I did on my first attempt. Left both the TOC and the accordion and didn't worry about showing the content for screen readers. It worked fine, but it felt really weird to not be able to open the accordion content via the screen reader.
  • Then, I went with leaving the TOC and implementing something that the screen reader could open via keyboard commands. After checking that out, it also felt weird because I had a TOC that linked to the title of the accordion, that you then had to click to open.
  • Finally, I removed the TOC and implemented the accordion-to-full pattern that @davatron5000 mentioned earlier. It seems sporadic when the tabpanel semantics are honored and when they aren't. I'm not familiar enough with these semantics to make a decisive decision, I don't have any other screen readers to test with.

The JS I wrote for it isn't very well structured right now (I know there are some bugs). I'm not going to worry about it until we have a definitive route to go with it.

So, yeah. Any ideas?

@grayghostvisuals

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals Aug 21, 2015

Contributor

@jeryj Spatial navigation done in an accessible manner! 🎆 🔥 🚒

Contributor

grayghostvisuals commented Aug 21, 2015

@jeryj Spatial navigation done in an accessible manner! 🎆 🔥 🚒

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Aug 24, 2015

Member

@grayghostvisuals, any recommendations on how we should address it? Anyone want to do a google hangout for 15 or so minutes so we can hopefully figure out a good solution?

Or, is the first thing I tried OK? The one where I hid the TOC visually, and the mobile experience was exactly the same for screen readers on desktop, but you couldn't open the accordion tabs via the screen reader click. That solution is great, other than it feels weird if you're a user that uses a screen reader while still wanting visual feedback. Do people who can see the screen well enough to read (even with larger font sizes), also use a screen reader?

Member

jeryj commented Aug 24, 2015

@grayghostvisuals, any recommendations on how we should address it? Anyone want to do a google hangout for 15 or so minutes so we can hopefully figure out a good solution?

Or, is the first thing I tried OK? The one where I hid the TOC visually, and the mobile experience was exactly the same for screen readers on desktop, but you couldn't open the accordion tabs via the screen reader click. That solution is great, other than it feels weird if you're a user that uses a screen reader while still wanting visual feedback. Do people who can see the screen well enough to read (even with larger font sizes), also use a screen reader?

@grayghostvisuals

This comment has been minimized.

Show comment
Hide comment
@grayghostvisuals

grayghostvisuals Aug 24, 2015

Contributor

@jeryj Not ATM. Just dropping suggestions to make it harder on everyone ;)

Contributor

grayghostvisuals commented Aug 24, 2015

@jeryj Not ATM. Just dropping suggestions to make it harder on everyone ;)

@davatron5000

This comment has been minimized.

Show comment
Hide comment
@davatron5000

davatron5000 Aug 24, 2015

Contributor

@jeryj I could do a Hangout like Wednesday morning (9:30am Central?)

Contributor

davatron5000 commented Aug 24, 2015

@jeryj I could do a Hangout like Wednesday morning (9:30am Central?)

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Aug 24, 2015

Member

9:30am Central on Wednesday works great for me. Here's a permalink for the hangout.

Member

jeryj commented Aug 24, 2015

9:30am Central on Wednesday works great for me. Here's a permalink for the hangout.

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Aug 27, 2015

Member

@davatron5000 I continued accordion pattern research, and I still can't get a perfect solution. I pushed three different types to three different branches on my fork of the a11yproject. Just the scripts.js file is different on each so you can easily switch it out however is best for you.

Here's a rundown of each.

Redesign Branch: Accordion HTML - H3 with bunch-o-aria-attributes

It works via a screen reader click on the h3 and announces that it's collapsed or expanded. It's smooth and works really well. The bummer... it removes the h3s from the VO rotor headings!

I think this would be a great solution if it included the headings in the rotor. I found this on Stack Overflow where people suggested this was a VO bug, and that NVDA handles it fine by showing it in the rotor. Even if it's a VO bug, it still doesn't feel good to release something that makes the site less accessible for our users. I did notice that the headings end up showing in the rotor under the form controls when you use role="tab".

Alt-Accordion Branch: Accordion HTML - Just a plain H3

There's nothing special here. The HTML is the same as on the desktop view, and operates the same for screen readers as on a desktop. It operates by click via a mouse. We could (and should) add a keyboard open as well. The issues are that it doesn't open via screen reader click (but hopefully we could add that?) so the screen reader can read the content easily, and it doesn't display visually. It's just hidden content that's accessible to the screen reader. This MIGHT be a problem, but might not. Headings DO show in the rotor though, which is good.

Alt-Accordion-Button: Accordion HTML - H3 + Button with bunch-o-aria-attributes

This one is the same as the first one on the redesign branch. The difference is that a click on the button is what opens the accordion. This means you have to do the shift+VO+down arrow to interact with the button to make it open. That's more clicks just to access content. Doesn't seem good. The upside is that the H3 reappears in the rotor when it's interior is the button HTML, presumably because role=tab is on the button and not the H3.

Why am I so hung up on the headings rotor?

From the webAIM.org screen reader survey, 65% of screen reader users navigate via headings. Seems pretty crucial that we design the interactions in the way that screen reader users WANT to interact with them, not compromise their navigation because we want to change the visual presentation.

What to do

If people could test out the three options and see how it feels and provide ideas/feedback, that'd be great. I'm a little concerned that such a simple pattern to do via mouse is so difficult to implement ideally via screen reader. It makes me think we should go a different route entirely. It'll be a hard sell to tell developers, "Accordions? No problem! Just add these 75 lines of javascript and a ton of HTML markup!"

Overall

We're really close. The website is working fine and I think the basics are ready for launch after this view is complete. We could keep improving things for sure, but I think the bones and base experience is complete.

Member

jeryj commented Aug 27, 2015

@davatron5000 I continued accordion pattern research, and I still can't get a perfect solution. I pushed three different types to three different branches on my fork of the a11yproject. Just the scripts.js file is different on each so you can easily switch it out however is best for you.

Here's a rundown of each.

Redesign Branch: Accordion HTML - H3 with bunch-o-aria-attributes

It works via a screen reader click on the h3 and announces that it's collapsed or expanded. It's smooth and works really well. The bummer... it removes the h3s from the VO rotor headings!

I think this would be a great solution if it included the headings in the rotor. I found this on Stack Overflow where people suggested this was a VO bug, and that NVDA handles it fine by showing it in the rotor. Even if it's a VO bug, it still doesn't feel good to release something that makes the site less accessible for our users. I did notice that the headings end up showing in the rotor under the form controls when you use role="tab".

Alt-Accordion Branch: Accordion HTML - Just a plain H3

There's nothing special here. The HTML is the same as on the desktop view, and operates the same for screen readers as on a desktop. It operates by click via a mouse. We could (and should) add a keyboard open as well. The issues are that it doesn't open via screen reader click (but hopefully we could add that?) so the screen reader can read the content easily, and it doesn't display visually. It's just hidden content that's accessible to the screen reader. This MIGHT be a problem, but might not. Headings DO show in the rotor though, which is good.

Alt-Accordion-Button: Accordion HTML - H3 + Button with bunch-o-aria-attributes

This one is the same as the first one on the redesign branch. The difference is that a click on the button is what opens the accordion. This means you have to do the shift+VO+down arrow to interact with the button to make it open. That's more clicks just to access content. Doesn't seem good. The upside is that the H3 reappears in the rotor when it's interior is the button HTML, presumably because role=tab is on the button and not the H3.

Why am I so hung up on the headings rotor?

From the webAIM.org screen reader survey, 65% of screen reader users navigate via headings. Seems pretty crucial that we design the interactions in the way that screen reader users WANT to interact with them, not compromise their navigation because we want to change the visual presentation.

What to do

If people could test out the three options and see how it feels and provide ideas/feedback, that'd be great. I'm a little concerned that such a simple pattern to do via mouse is so difficult to implement ideally via screen reader. It makes me think we should go a different route entirely. It'll be a hard sell to tell developers, "Accordions? No problem! Just add these 75 lines of javascript and a ton of HTML markup!"

Overall

We're really close. The website is working fine and I think the basics are ready for launch after this view is complete. We could keep improving things for sure, but I think the bones and base experience is complete.

davatron5000 added a commit that referenced this issue Sep 2, 2015

Reduced image size and number of images on Contributers module. #324
Users will have to clear localhost to see the changes due to our
caching.
@chrisdemars

This comment has been minimized.

Show comment
Hide comment
@chrisdemars

chrisdemars Sep 25, 2015

Newcomer wanting to work on this project. Where can I fit in?

Newcomer wanting to work on this project. Where can I fit in?

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Sep 25, 2015

Member

@chrisdemars Great! Glad to have the help.

Our main goal right now is to get a website out the door. We're going for minimal viable right now. After we get the minimum launchable website live, then we'll add improvements as people have the energy, time, and ideas. So, if you do have ideas, document them here for now, and after we launch the new site, we can discuss what would be the best additions.

What would be really helpful right now is to test out the current redesign branch and do any bug fixes on the current design (basically just CSS). Browser testing would be fantastic too on whatever you'd like to test out. I've done visual testing in Chrome, Safari, Firefox, iPhone 4s (iOS 8), and VoiceOver (OSX 10.9) in Chrome, Firefox, and Safari.

As you're combing through the code, please feel free to provide feedback and ideas on this thread. But try to resist doing any feature additions or HTML restructuring for now. Though, DO document what you'd like do and why on this thread.

Let me know if you have any more questions on how to plug-in on the redesign. Thanks for offering to help!

Member

jeryj commented Sep 25, 2015

@chrisdemars Great! Glad to have the help.

Our main goal right now is to get a website out the door. We're going for minimal viable right now. After we get the minimum launchable website live, then we'll add improvements as people have the energy, time, and ideas. So, if you do have ideas, document them here for now, and after we launch the new site, we can discuss what would be the best additions.

What would be really helpful right now is to test out the current redesign branch and do any bug fixes on the current design (basically just CSS). Browser testing would be fantastic too on whatever you'd like to test out. I've done visual testing in Chrome, Safari, Firefox, iPhone 4s (iOS 8), and VoiceOver (OSX 10.9) in Chrome, Firefox, and Safari.

As you're combing through the code, please feel free to provide feedback and ideas on this thread. But try to resist doing any feature additions or HTML restructuring for now. Though, DO document what you'd like do and why on this thread.

Let me know if you have any more questions on how to plug-in on the redesign. Thanks for offering to help!

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Nov 6, 2015

Member

I just pushed a few more minor changes to the redesign branch. I think it's ready for a few people to review it, test it out, and then merge it to master (gh-pages) if everything looks good.

When reviewing, remember, the idea is if the site is in a launch-able state, not a perfect state. We're going for a base functionality that's ready to be expanded and improved upon.

Any volunteers to review and test?

Member

jeryj commented Nov 6, 2015

I just pushed a few more minor changes to the redesign branch. I think it's ready for a few people to review it, test it out, and then merge it to master (gh-pages) if everything looks good.

When reviewing, remember, the idea is if the site is in a launch-able state, not a perfect state. We're going for a base functionality that's ready to be expanded and improved upon.

Any volunteers to review and test?

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Jan 7, 2016

Member

@davatron5000 - Digging all the new article activity! Should we pull the recent changes from master into the redesign branch, clean up any issues, merge back to master, and launch it? I can help with the process if you can give your OK on it as well.

Member

jeryj commented Jan 7, 2016

@davatron5000 - Digging all the new article activity! Should we pull the recent changes from master into the redesign branch, clean up any issues, merge back to master, and launch it? I can help with the process if you can give your OK on it as well.

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Jan 7, 2016

Member

I had some time so I pulled upstream gh-pages into my redesign branch, merged everything, and cleaned up the conflicts from the patterns, checklist, and resources page. I think I got everything. The redesign branch should be up to date with the latest changes from gh-pages now.

@davatron5000 - Can I bug you to give it a look? I think you're the only other one that has the redesign branch set-up locally. But, this is definitely an open invite if anyone wants to find bugs and issues on the redesign before it launches!

Member

jeryj commented Jan 7, 2016

I had some time so I pulled upstream gh-pages into my redesign branch, merged everything, and cleaned up the conflicts from the patterns, checklist, and resources page. I think I got everything. The redesign branch should be up to date with the latest changes from gh-pages now.

@davatron5000 - Can I bug you to give it a look? I think you're the only other one that has the redesign branch set-up locally. But, this is definitely an open invite if anyone wants to find bugs and issues on the redesign before it launches!

@davatron5000

This comment has been minimized.

Show comment
Hide comment
@davatron5000

davatron5000 Jan 7, 2016

Contributor

I pulled it yesterday. Looks good! There were a couple issues I saw:

  • Checkboxes on checklist in Edge are too big. - [ ] H1s on mobile devices were a bit too large (3-4 line titles on mobile)
    I'm happy to knock those out real quick tomorrow morning and push it live. Or. We can push it all live and fix it after the fact.
Contributor

davatron5000 commented Jan 7, 2016

I pulled it yesterday. Looks good! There were a couple issues I saw:

  • Checkboxes on checklist in Edge are too big. - [ ] H1s on mobile devices were a bit too large (3-4 line titles on mobile)
    I'm happy to knock those out real quick tomorrow morning and push it live. Or. We can push it all live and fix it after the fact.
@chrisdemars

This comment has been minimized.

Show comment
Hide comment
@chrisdemars

chrisdemars Jan 7, 2016

I can also go through and give it a look see, if you are all cool with that.

On Wednesday, January 6, 2016, Dave Rupert notifications@github.com wrote:

I pulled it yesterday. Looks good! There were a couple issues I saw:

  • Checkboxes on checklist in Edge are too big. - [ ] H1s on mobile
    devices were a bit too large (3-4 line titles on mobile)
    I'm happy to knock those out real quick tomorrow morning and push it live.
    Or. We can push it all live and fix it after the fact.


Reply to this email directly or view it on GitHub
#324 (comment)
.

I can also go through and give it a look see, if you are all cool with that.

On Wednesday, January 6, 2016, Dave Rupert notifications@github.com wrote:

I pulled it yesterday. Looks good! There were a couple issues I saw:

  • Checkboxes on checklist in Edge are too big. - [ ] H1s on mobile
    devices were a bit too large (3-4 line titles on mobile)
    I'm happy to knock those out real quick tomorrow morning and push it live.
    Or. We can push it all live and fix it after the fact.


Reply to this email directly or view it on GitHub
#324 (comment)
.

@davatron5000

This comment has been minimized.

Show comment
Hide comment
@davatron5000

davatron5000 Jan 7, 2016

Contributor

Definitely! All hands on deck. 
QA, screen reader, keyboard accessibility triple-checking would be super helpful. 

Contributor

davatron5000 commented Jan 7, 2016

Definitely! All hands on deck. 
QA, screen reader, keyboard accessibility triple-checking would be super helpful. 

@chrisdemars

This comment has been minimized.

Show comment
Hide comment
@chrisdemars

chrisdemars Jan 7, 2016

I will start this week. I also was going to start working on some articles
as well, I just haven't had a chance.

On Wed, Jan 6, 2016 at 11:24 PM, Dave Rupert notifications@github.com
wrote:

Definitely! All hands on deck.
QA, screen reader, keyboard accessibility triple-checking would be super
helpful.


Reply to this email directly or view it on GitHub
#324 (comment)
.

I will start this week. I also was going to start working on some articles
as well, I just haven't had a chance.

On Wed, Jan 6, 2016 at 11:24 PM, Dave Rupert notifications@github.com
wrote:

Definitely! All hands on deck.
QA, screen reader, keyboard accessibility triple-checking would be super
helpful.


Reply to this email directly or view it on GitHub
#324 (comment)
.

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Jan 7, 2016

Member

Great! I say let's get the low-hanging fruit fixed and then launch.

  • iPhone main navigation could probably fit all four links across
  • Line height on sidebar category links on homepage. New Assistive Technologies link wraps and has a big ol' space.

Semi-low hanging fruit

  • Remove link highlighting on waypoints for the Patterns page. It's so long and the sections are so short that the current calculations aren't very reliable.
  • viewport height check to turn off the waypoints sticky (fixed) sidebar if the viewport doesn't allow it all to fit.
Member

jeryj commented Jan 7, 2016

Great! I say let's get the low-hanging fruit fixed and then launch.

  • iPhone main navigation could probably fit all four links across
  • Line height on sidebar category links on homepage. New Assistive Technologies link wraps and has a big ol' space.

Semi-low hanging fruit

  • Remove link highlighting on waypoints for the Patterns page. It's so long and the sections are so short that the current calculations aren't very reliable.
  • viewport height check to turn off the waypoints sticky (fixed) sidebar if the viewport doesn't allow it all to fit.
@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Jan 15, 2016

Member

Low-hanging fruit items have been fixed and merged with redesign branch. I also reduced the font size of h1s and h2s for small screens.

@davatron5000 Do you have time to do the checkboxes fix for Edge? I'm on a Mac, and I say a small prayer of thanks everyday I don't have to launch a VM. I'm also 100% fine with launching without that fix.

Member

jeryj commented Jan 15, 2016

Low-hanging fruit items have been fixed and merged with redesign branch. I also reduced the font size of h1s and h2s for small screens.

@davatron5000 Do you have time to do the checkboxes fix for Edge? I'm on a Mac, and I say a small prayer of thanks everyday I don't have to launch a VM. I'm also 100% fine with launching without that fix.

@davatron5000

This comment has been minimized.

Show comment
Hide comment
@davatron5000

davatron5000 Jan 26, 2016

Contributor

@jeryj I just pushed a few commits up to the Redesign Branch. If they look good to you, feel free to make a PR or merge to Master. Since 5pm is a terrible time to announce anything, we can announce tomorrow!

Contributor

davatron5000 commented Jan 26, 2016

@jeryj I just pushed a few commits up to the Redesign Branch. If they look good to you, feel free to make a PR or merge to Master. Since 5pm is a terrible time to announce anything, we can announce tomorrow!

@davatron5000

This comment has been minimized.

Show comment
Hide comment
@davatron5000

davatron5000 Jan 27, 2016

Contributor

🎉 Hooray! I had some time tonight so I did the merge. Thanks to everyone who pitched in! Special thanks to @jeryj who took the helm on this. It would have never happened without his hard work. 👏 👏 👏

Also. I think it's really cool that we were able to remove Bootstrap, radically simplify the codebase, removed lots of dependencies, and do a complete redesign in the open. That's no small feat.

Collectively I feel we've paved the way for the project to be easier to read, use, contribute, and maintain. To me, that's the epitome of good design and should make the whole Accessibility Project more sustainable going forward. Thanks again to everyone who pitched in and helped.

And, of course, if something is broken, inaccessible, or bothers you - File an issue! Looking forward to the next 400 bugs 😜

Contributor

davatron5000 commented Jan 27, 2016

🎉 Hooray! I had some time tonight so I did the merge. Thanks to everyone who pitched in! Special thanks to @jeryj who took the helm on this. It would have never happened without his hard work. 👏 👏 👏

Also. I think it's really cool that we were able to remove Bootstrap, radically simplify the codebase, removed lots of dependencies, and do a complete redesign in the open. That's no small feat.

Collectively I feel we've paved the way for the project to be easier to read, use, contribute, and maintain. To me, that's the epitome of good design and should make the whole Accessibility Project more sustainable going forward. Thanks again to everyone who pitched in and helped.

And, of course, if something is broken, inaccessible, or bothers you - File an issue! Looking forward to the next 400 bugs 😜

@jeryj

This comment has been minimized.

Show comment
Hide comment
@jeryj

jeryj Jan 27, 2016

Member

🎉 🎉 Thanks for merging! Glad to see it online. Thanks to everyone who helped out!

Member

jeryj commented Jan 27, 2016

🎉 🎉 Thanks for merging! Glad to see it online. Thanks to everyone who helped out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment