Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.
RD Symposia Design
Nav: EOWG wiki main page
- 1 To Do
- 2 Converting old pages to this new design
- 3 Misc
- 4 Browser & AT testing
- 5 Review questions and grouped replies
- 6 JO 2 July
- 7 YY 3 July
- 8 IP 6 July
- 9 VMM 4 Oct
- latest draft - links in the nav tab all work, plus in the Proceedings tab, the "Paper n" links go to an example paper.
- WAI intro page
- Design specs
- clean up CSS & HTML; add wai-aria, skiplinks; and such
- clean up meta - document what's left :-)
- [wishlist for later?] consider a style switcher widget to change to sans-serif font and headings not-all-caps & not italicized.
reply from Shawn: Let's not delay completing the template for this functionality-- can add to wishlist for later.
- [done] check link colours. consider darker so higher contrast. (there are some notes on link colors in comments below)
- [done] finish addressing issues below. add brief replies & mark as closed. open comments have "@@" to make find-in-page-able. (I think most are addressed, but need to briefly note what was done, or why not.)
- [done] fix nav links so not self-reference (CSS is on the a so not trivial to change)
- [done] Shawn check with Shadi on check requirements for BibTex (not pre or highlighted)
- [done] Shawn ask EOWG for more browser & AT testing
- [done] fix IE 7 bug: nav looks like just a plain list - no formatting into tabs. reply from Liam & Shawn: IE7 usage is under 3% so not going to polish visual design -- it does work fine
- [done] Shawn fix page titles
Converting old pages to this new design
- Add metadata to each paper. (We also need to add it to the Reports (W3C Notes).)
- Add reference format, BibTex file link, and BibTex data to bottom.
- Main pages:
- (low priority) Transcript: Add headings & maybe anchors to particular points. Add high-level agenda with links to headings or Contents list with links to headings.
- [closed] Should the < h1 > be in the < header >?
reply: Liam Hmm. Typically, but not necessarily. Currently the WAI bar, the symposium name and the main navigation tabs are in the <header> section as introductory elements. The H1 sits outside it... in part because that's the only way I can do the 'wrapper' around the main content. That kind of feels right, semantically, in this case, because of the weirndess of having repeating 'super headings' (Symposium Name, Wai bar) on every page. I guess technically I could use multiple section elements with their own header elements, but I worry about the AT knock on effects of doing so. I really don't want multiple H1s on a page...
JB 27 May 2014
[Shawn thinks these should not be show-stoppers for first roll-out, and should be fairly easy to do so maybe Liam or other can do them quickly anyway.]
- suggest tabs have rounded edges.
- suggest selected tab not have the underline.
- [slh: can look like tab folder, e.g., http://franklinplanner.fcorgp.com/static/catalog/products/lrgcase/36625_lrgcase.jpg]
- page contents box looks unachored and awk.
- [closed] through narrow width would make page longer [slh said width is based on optimum line length on common configurations. jb said OK.]
Browser & AT testing
- IE 7 on Windows Vista - nav at top is plain list - reply from Liam & Shawn: IE7 usage is under 3% so not going to polish visual design -- it does work fine in IE7
- Firefox 3.6 on Windows Vista - good
- Opera 12 on Windows Vista - good
- Firefox 5.0.1 on Windows XP: functionality: fine, very minor style sheet differences
- Chrome 19 - minor style sheet differences
- IE 7 on Windows XP - tabs appear in text, minor style sheet issues
- IE 8 on Windows XP - tabs appear in text
Review questions and grouped replies
Is the use of all caps and italics acceptable?
- YY: I think they look good.
- SK: ...I have spent my professional life discouraging people from using caps and italic as being more difficult to read.
I'd worry about the impact of starting a whole new trend that ignores established research. I would have to vote no to caps, italics and caps AND italics!
- JO: Personally, I think its fine if used in moderation. Some may have legibility issues with it.
- IP: Use sentence case for headings.
- SLH: I'm torn. All caps is harder to read for almost all people, but maybe it is acceptable for short amounts of text in this case? Certainly the all caps heading look nice aesthetically.
- VMM: I like "SK" above have spent a lot of time discouraging people from using caps and italics, including too often caps (caps on title of web site, caps on h1, caps on month (unnecessary))
Liam: Caps, Italics are important ways of adding meaning and readability to texts. Legibility/readability research tends to focus on passages of body copy, not heading/display text. Moderation is the key.
- SLH: Yes - it helps people know which pages they have already been to.
- YY: I think this would be useful, especially reading long research pages, this could be useful.
- JO: Maybe, but I think the links should highlight on keyboard focus (using CSS pseudo classes etc).
- IP: The site and page navigation links do not need a visited style, but the links in the copy do.
- VMM: Current (mauve) visited link is in my view too mauve.
Liam: Agree with all - especially kb focus. Will implement.
- JO: I do think the font used for body copy of the page could be difficult. A sans serif font may be preferable - but again it can depend on who you ask.
- SK: My copy is also displaying with a serif face which has been a long term no-no for computing, although good for reading print text. It is of course about time that all the typeface usability research was redone in relation to current display screen technology which is hugely superior to the days when the earlier research was done!
- IP: The serif body font is hard to read. The Trebuchet MS and default serif font used by the tagline works well though.
- IP: I think that PT Serif is a stronger font than Old Standard TT for the headings.
- SLH: I support the use of serif font in this case because it is trying to look like an academic journal. Studies on readability of serif vs. sans serif is not clearly for one or the other in today's environment.
- VMM: current font presents some font differences across browsers.
Liam: yes, all the research I have read on serif vs sans is extremely inconclusive. Seems that it's the wrong question - an oversimplification. Things such as margins, leading, counters and x heights seem to have similar if not greater effect. Old Standard TT is used as a display font just to give a feel of academia. See the lovely 'Origin of Species' setting at http://hellohappy.org/beautiful-web-type/. PT Serif is a good choice for body as, of course, supports Cyrillic.
Is the yellow box giving the bibtext too much prominence?
- I am also seeing the box stopping short in Aurora (firefox 15)
- VMM: Same for FF 5.0.1, IE7, Chrome 19
- Shawn: Yes it is. Would like style to de-emphasize it even more than the regular text.
- note: Got confirmation from Shadi no need to keep it in < pre >.
- Liam: no more pesky pre, no more pesky yellow boxes.
HTML5 & WAI-ARIA
Is the HTML5 used (e.g., <header> and <nav>) sufficiently supported by AT? Do we need redundant indications, e.g., hidden heading for the nav?
- IP: Steve Faulkner's latest research suggests adding the appropriate ARIA roles to nav and the primary <header> elements (see http://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/index.html). If this is done the add a <hx> as the first element within the element with a role, as Voiceover on iOS does not state which landmark is used, instead reading 'landmark start' and then the first element content.
- JO: Nope. Not at all. So really, I wouldn't use them, but including them isn't going to break anything it's just that they are just of no earthly use to AT users right now. If you wish to denote any landmarks - use ARIA :-)
The <li items used for 'Home', 'Proceedings' etc could be given the ARIA role="navigation" for example.
but dropping the <nav> element such as:
is perfectly sufficient.
Liam: OK, sounds like the Jury is out. Will put in 5 bits on the basis of a gentle nod to the future. I have implemented <nav role="navigation"> to tick as many boxes as possible [done]
JO 2 July
Firstly, it is good to see some new designs being tried out so well done :-)
It is very text heavy and there is a lot white space around the text and containing design, so one comment is that this can cause some screen glare for VIP.
reply Shawn: I tried background: #ffebd7; color: #333; but not sure I like it. Liam, feel free to do something different.
reply Liam: OK, we'll try to warm it a little. Am ambivalent about white space - hefty margins/ limited line length wins for legibility reasons from my perspective. General background set to cool grey. [done]
YY 3 July
[closed - all in this section]
and some other comments for editors discretion:
- I think justified text would be useful as well (both left and right).
reply Liam: Justified text - very interesting. not sure how well browsers are at full justification yet, but I agree that it could look pretty good at full line-width. Could then change to ragged-right as line-length decreased to avoid horribleness on small screens, responsive-style. reply Shawn: Suggest keep it simple left justify only. Full justification could decrease readability for some people. Probably not worth the effort to make responsive.
- link to slides in the proceedings tab might not be available in all symposiums.
reply Shawn: correct - probably only n the first one.
- Links at the top (WAI R&D Symposia » Metrics Symposium Home ») are used as breadcrumbs but as I move along the tab, the tab items are not added to this list, so this might be a bit confusing.
reply Shawn: I added the current page (unlinked of course)
- Will the transcript page include some mechanism of highlighting, for example time stamps, or some headings, etc? This would be useful to guide people reading the transcript page, otherwise it might be too long. This page could also include agenda of the symposium to guide the reader so they would be able to jump to specific agenda items. Based on this, I wonder if the following symposiums can be recorded so that we also provide audio transcripts for people to follow.
reply Shawn: We can manually add headings to the transcript. RDWG has discussed audio recordings.
- I guess the link at the bottom of the page will be removed: <http://www.w3.org/WAI/EO/Drafts/rd/cfp.html>.
reply Shawn: yes.
- In my browser (Firefox v13.01), yellow box is not fully covering the bibtex item <http://www.w3.org/WAI/EO/Drafts/rd/report.html>. [addressed elsewhere]
reply: recorded as issue above, thanks.
and some minor comments about the content.
- I think it would be good to add affiliations of the scientific committee members to this page: http://www.w3.org/WAI/EO/Drafts/rd/home.html
reply Shawn: Yes, that is on the To Do list. :)
IP 6 July
- [closed] Text is too small with the specified font. I would suggest not reducing the font size from the default 16 pixels.
Shawn: for main body text, err on side of larger text and more leading - since users are reading big blocks of text in long articles, especially in the papers/proceedings. OK to have smaller text in navigation.
Liam: text size increased to 15pt, line height to 1.6 [done]
- [closed] Consider an off white background and a not-quite-black text colour. There is a lot of glaring white space at the moment.
reply Shawn: I tried background: #ffebd7; color: #333; but not sure I like it. Liam, feel free to do something different.
reply Liam: BG set to fffff6, text to #111 [done]
- [closed] I found the contrast of the focus / hover link styles a little low, and the colour a bit bright.
reply: focus is white on black. Hover is darkening the underline. link and visited link colour contrast improved. [done]
- [closed] Consider a background for links with focus in addition to the colour change. In most (non-webkit) browsers the default focus outline can be improved upon.
reply: Liam: absolutely - done for links (not for nav tabs).
- [?] Focus outline is almost invisible around the WAI logo link.
reply: Liam: ditto [Shawn says - can leave this undone as an overall WAI website issue if you want] reply Liam: done anyway, with suggestion to implement in main wai css file too... [done]
- [closed] The text in the main navigation link sits a bit too close to the border of the content containing box until the links are focussed / hovered over.
reply: Liam: OK will have a look at this reply Liam: tweaked a couple of px up.
- [closed] I don't know if the pre at the bottom of http://www.w3.org/WAI/EO/Drafts/rd/report.html is relevant, but if it is then overflow: auto; will add horizontal scroll bars instead of the contents escaping the bounding box.
reply: Liam: not sure if it's relevant either. Shawn? [Shawn says: we've got this as an open issue listed above -- will get clarification from Shadi & RDWG if needed] [closed]
- [closed] In my opinion, elastic design does not offer any accessibility advantages in modern browser as it effectively behaves like a limited zoom feature. It takes away the option of having an increased font size without increasing line lengths, something that is useful for some users.
reply: Liam maybe. Interesting point about taking away increased font size without increasing line lengths - but this can be accomplished with a window resize, of course. It doesn't cause problems for Zoom software here, so have left as is.
VMM 4 Oct
- Link colors show some failures albeit it does depend on what conformance level. From a personal point of view, I find that the color of the active link is too light and that the visited link is too mauve.
- Reply Liam: thanks, both now AAA compliant. [done]
- Links in the left short cut area: add a link hover over of some sort e.g. underline or focus
- Reply Liam: [done]
- I wouldn't place BLOCK CAPS too often. On most pages, there are two instances of block caps for reasons of legibility. Also block caps and italics are usually avoided.
- Reply Liam: I have increased letter-spacing for the uppercase heading. I think that should solve any lingering legibility problems.
- I would stick to standard fonts in order to have a consistent display across multiple browsers.
- Reply Liam: there is no requirement for consistent display across multiple browsers (although it does need to function correctly, of course). I believe that it would be a shame to reject the improvements in legibility and typographic quality made available to us via web fonts...
- (Personal comment) I find it bothersome that the tabs shift up a bit if focus is placed on the tab. I would prefer no movement except that once a tab is selected, then, it stands out from the others.
- Reply Liam: This is an intentional effect to highlight focus. I'd like to push back on this unless there is a general vote against.
- (Personal comment) I find the background too mauve.
reply: background de-mauved [closed]. Now slightly blue of grey.