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.


Difference between revisions of "RD Symposia Design"

From Education & Outreach
Jump to: navigation, search
(IP 6 July)
(Converting old to new design)
Line 22: Line 22:
  
 
===Converting old to new design===
 
===Converting old to new design===
* Add [http://www.w3.org/WAI/RD/wiki/Indexing metadata]
+
* Papers:
* Move content from main page & CfP as needed @@
+
** Add [http://www.w3.org/WAI/RD/wiki/Indexing metadata] to each paper. (We also need to add it to the Reports (W3C Notes).)
* In Scientific Committee listing: add organizations where they are missing
+
** Add BibTex file link and data to bottom.
 +
* Main pages:
 +
** Scientific Committee listing: add organizations where they are missing
 +
** Move content from main page & CfP as needed @@
 
* (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.
 
* (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.
 
* @@
 
* @@

Revision as of 16:29, 17 January 2013

Nav: EOWG wiki main page


To Do

Template new design

  • Shadi: why is bibtex in < pre >? can we take it out?
  • Liam: nav links not self-reference (CSS is on the a so not trivial to change)
  • Liam: check link colours. consider darker so higher contrast.
  • Liam: Clean up CSS & HTML, add wai-aria, skiplinks, etc.
  • Liam: Consider a style switcher widget to change to sans-serif font and headings not-all-caps & not italicized
  • Liam: add brief replies to issues below where @@s are (I think most are addressed, but need to briefly document what was done)
  • [in progress] 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] page titles

Converting old to new design

  • Papers:
    • Add metadata to each paper. (We also need to add it to the Reports (W3C Notes).)
    • Add BibTex file link and data to bottom.
  • Main pages:
    • Scientific Committee listing: add organizations where they are missing
    • Move content from main page & CfP as needed @@
  • (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.
  • @@
  • ...@@...

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.

Should there be a visited link colour?

  • 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. [@@open]

font

  • 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

[@@open - taking out of pre will fix box stopping short]

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.
<nav>

  • <a href="home.html">Home</a>
  • <a href="proceedings.html">Proceedings</a>
  • <a href="transcript.html" class="here">Transcript</a>
  • <a href="cfp.html">Call for Papers</a>
  • <a href="report.html">Report</a>

</nav>

or

<nav>

  • <a href="home.html">Home</a>
  • <a href="proceedings.html">Proceedings</a>
  • <a href="transcript.html" class="here">Transcript</a>
  • <a href="cfp.html">Call for Papers</a>
  • <a href="report.html">Report</a>

</nav>

but dropping the <nav> element such as:

  • <a href="home.html">Home</a>
  • <a href="proceedings.html">Proceedings</a>
  • <a href="transcript.html" class="here">Transcript</a>
  • <a href="cfp.html">Call for Papers</a>
  • <a href="report.html">Report</a>

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. [@@ 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. [@@ done ?]

YY 3 July

and some other comments for editors discretion:

  • [closed] 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.

  • [closed] link to slides in the proceedings tab might not be available in all symposiums.

reply Shawn: correct - probably only n the first one.

  • [closed] 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)

  • [closed] 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.

reply Shawn: yes.

reply: recorded as issue above, thanks.
and some minor comments about the content.

reply Shawn: Yes, that is on the To Do list. :)

IP 6 July

  • [@@ open?] Text is too small with the specified font. I would suggest not reducing the font size from the default 16 pixels.

reply: will try and see.
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.

  • [pen?] 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: @@

  • [open] I found the contrast of the focus / hover link styles a little low, and the colour a bit bright.

reply: [@@?]

  • [open] 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 - hadn't touched the behaviour layer yet.

  • [?] 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]

  • [open] 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: 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?] 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.