w3c / wai-website-design Goto Github PK

Write test plan, recruit users, and conduct benchmarking usability test (qualitative sample size) to gain insight into current pain points and uncover unknown IA issues.

To improve display in social networks.

Collect and refine a list of top tasks commonly performed on site by visitors (personas). This will be used to refine the IA and to inform the test plan for the benchmarking usability study.

See:
https://www.digitalgov.gov/2014/07/02/using-top-tasks-to-be-top-notch-federal-reserve-board-usability-case-study/
http://alistapart.com/article/what-really-matters-focusing-on-top-tasks
http://www.measuringu.com/blog/top-tasks.php
http://www.gerrymcgovern.com/new-thinking/top-task-analysis-evidence-over-opinion

I'm hoping we can add this to the September sprint. If wireframes can be in place by end of September then (combining them with style tiles) I think we can have prototypes as an October sprint. My guess is we won't need to do comp's.

1. font-weight:

• Minimum font weight for text to be readable is 400 (rely on the font-weight numbers rather than names like "regular" or "book")
• For very large text >24px you can get away with 300. But its contrast ratio minimum must be 4.5:1.
• See the second chart "Font Weight and Contrast" on my page about fonts here: http://haltersweb.github.io/Accessibility/font-sizing-and-contrast.html

2. font-family:
   Some custom fonts don't render so well on a PC. Also, browsers use poorer rendering engines than Adobe products. Therefore you should do a test in HTML and view in IE and FF on PC. Squint and see if it looks alright.

Charlotte and Shawn will work on this offline.

@lakeen’s action item (I can’t assign you… finding out how that works)

follow up from #29

I don’t know if this has to do with the IA EPIC, so feel free to reassign. I also don’t think that the TF needs to spend a lot of time right now.

https://www.w3.org/WAI/EO/wiki/WAI_Website_Redesign/Footer

also define meta data on draft documents so they don't come up

For many pages, we would like to have easy access to translations of that page. That involves:

• UI to easily discover and get to the translations - in separate issue #32
• backend for it

Additional info:

• Current W3C database discontinued (e-mail), not-yet-updated W3C Translation page
• I18N and CSS translations pages
• outdated WAI translating page

We want to meet Level AAA for contrast ratios. In several ways, it would be best and easiest if all text contrasts were 7:1.

We could use less that 7:1 for large text, but then we would:

• Need to be careful that when designing various components of the WAI site, someone doesn't accidentally use a lower contrast on small text. It would be important to note that in the style guide if we have any contrasts less than 7:1 in the final color palette.
• Risk criticism for lower than 7:1, when they don't realized we only use that for large text.

Also note that WCAG 2.1 is likely to have additional requirements for contrast of other elements. It's still being refined, but here is a draft.

I would love to see a design for the focus states for everything from navigation to links and buttons.

Remember you need unique look and feel for 4 focus states for things like navigation or radio buttons/check boxes:

• not-active focused
• active focused
• not-active not-focused
• active not-focused

Level: [medium] I would like to get input from others.
Reference: 26 Jan mockups, screen 5 of 9

Some concern with in-page navigation on the left. W3C and WAI site users are used to site nav on the left and in-page nav on the right (e.g., Mobile page). My gut is that it's OK to have site-wide nav at the top and no nav on the left, but it could be confusing to some users to have in-page nav on the left. (from 13 Dec e-mail and Nov F2F)

Also, the Tutorial mockup has different navigation on the left.

Perhaps the WAI site is so different from current w3.org and previous WAI site, that it won't mess up too many people too much? On the other hand, why risk confusing users? Why have in-page on the left instead of the right?

Will use OptimalSort (Visa has a paid full service account we can use) to card sort navigation terms after top tasks, content inventory, and benchmark testing is done.

https://www.w3.org/WAI/EO/wiki/WAI_site_plans has:

The highest priority for the IA of the site is to have really good search ability

Is there any reason to wait to do that? I'd like for us to consider making that a short-term improvement that we start very soon.

send URLs and ideas to AB by Sept 20th.

https://projects.invisionapp.com/share/H299QZZGZ#/screens/215895967

• I think the buttons in the “Help Improve this page” section need a border (or we’d need to underline the text in the buttons) as the background color of the button and the background color behind the button have not enough contrast.

Minor fix...

On the Text and Background Combinations pallets, the visual color of the black background box for the "yellow on dark grey" combination is the wrong color. The hex code is correct, the contrast ratio is correct, but the color used in the box is actually #1D1D1D instead of #3B3B3B.

Please adjust the color visually to be 3B3B3B.

As some people can’t use fly-out menus, so clicking on the main menu item should either

1. keep the fly-out menu in place or
2. open a sub-page with the fly out menu inline.

bar

After all IA activities and initial benchmarking test is done, create a new sitemap using DynoMapper or similar tool.

Please read/skim: Design Parameters

For input:

• How does this visual design reinforce WAI brand and strong relationship with W3C?
• Any suggestions for strengthening WAI brand and W3C — while being awesome, modern design? :-)

Get existing analytics for the site.

[strong]
In some of the current resources, there are a lot of anchor links and "back to top" links throughout. Will that functionality remain in the new design? If so, I would like to see a mock-up of how those would look visually so that they could be implemented consistently throughout the site.

Here's an approach I'd suggest. If you like it, I expect these need to be broken into individual backlog items, so feel free to do with this item as you see fit. Thanks.

1. Settle on a format to give to designers. I'd suggest the one at http://styletil.es/ -- especially the downloadable PSD.
2. Decide on time frame and other ground rules, including when needed, fine to do multiple style tiles, send results to James, know that we are very grateful for all efforts, and that we may or may not use them (however one can say this kindly).
3. Draft an email to the designers that includes these ground rules, the 3 adjective pairs we came up with, the personas, and the primary goal. Don't weigh these volunteers down with our wiki pages, etc. -- just cut to the design chase.
4. Email the wonderful volunteers who are willing to jump in and give this a go.

• The font size in the footer should be at least 14px. It appears that it’s smaller.
• I think in general for me the font size could be larger, but that’s a personal preference.

For many pages, we would like to have easy access to translations of that page. That involves:

• UI to easily discover and get to the translations
• technical backend for it - in separate issue #31

Complete list of new and retired (hidden) content for the new site. Is there anything beyond Shawn's great list from #5 (included below from ):

https://www.w3.org/WAI/sitemap.html is updated.

Planned new resources:
•more Tutorials
•Inclusion doc draft: http://w3c.github.io/wai-inclusion/ (project page links to requirements, etc: https://www.w3.org/WAI/EO/wiki/Accessibility_and_Inclusion)
•possibly 1-3 more Tips for Getting Started (draft of 3 new ones: http://w3c.github.io/wai-quick-start/)

Planned changes:
• https://www.w3.org/WAI/intro/accessibility.php to be updated and then not need to point to http://www.w3.org/standards/webdesign/accessibility
• Working Group, Interest Group, Task Force, etc. pages (listed under WAI Groups in sitemap) might become out of scope depending on future W3C website decisions.

Changes to IA:
•WCAG 1.0, ATAG 1.0, and UAAG 1.0 resources should have much less predominance. They still need to be find-able, but not primary. 2.0 versions should be primary.

Possible new resources:
•more/better intro guidance on WAI-ARIA
•guidance on specific topics [ask Denis...]

Eric (with Shawn) is working on a new navigation generation - that will work for the existing site and the redesign.

(TF doesn't need to spend time on this - it's just here fyi ;-)

As discussed between @lakeen and me on Jan 6th.

• Eric to send Laura the current metadata. ✅
• Eric to talk to Shawn to determine the first set of pages. ✅
• Eric/Shawn to send first set of pages to Laura. ✅
• Laura crafting descriptions and tags (more or less) for this first set of pages.

[slh updated ✅ on items 2 & 3]

Reference: 26 Jan mockups, screen 5 of 9
Related issue: #38

Maybe it's just the nature of a draft mockup, but it's not clear what that box is. I assume we will want to include a header such as "On this page" and make the links look like links.

For EOWG and other input:
1. I'm a bit uncomfortable with blue for heading level 3 and callout box headings, since blue has such strong affordance for clickable link.

For Alicia (awesome visual designer):

2. We will also need to provide styles for more heading levels -- at least level 4.

3. Is that link text color set, or browser default? What about visited link color?

On the current site, "WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities" is the tagline -- featured on every page near the top. Taglines are related to visual design -- affecting perception of the site. IMO this tagline is too blah-blah -- and thus we need to either do away with it or replace it with a very brief phrase that's in sync with our goal of "the WAI site as the #1 Go-To place for Web accessibility." To quote Copyblogger (copyblogger.com/create-a-tagline/) : "More often than not, [most people] get [taglines] wrong by focusing on what their product or service is and neglecting what it offers."

Using code snippet syntax coloring is very important. I'm so glad to see it here.

But the different syntax colors might cause contrast problems against the gray.

You could test all the colors, but...

...another option would be to have a button at every code snippet that changes it to black and white. That way you can maintain the semantic color that developers are used to while solving for low vision.

We currently have this feedback box, and I hope we can integrate this more in the new layout.

https://www.w3.org/WAI/EO/wiki/WAI_Website_Redesign/Feedback_Box

(Feel free to reassign and re-label as you see fit.)

Reference: 26 Jan mockups

The "Help improve this page" box is missing from some of the pages, including the Tutorials (8 of 9) and How to Manual page (6 of 9)

I assume that's just because this is a draft mockup, and it would go at the bottom of those pages. If so, please close this issue. :-)