Wiki source code of Testing needed

Version 2.4 by Lizzie Bruce on 2019/04/04 18:38

Show last authors
1 We want to find usability evidence to answer 4 style points we did not identify sufficient usability evidence for in Beta. If no evidence exists, we'll carry out new usability studies.
2
3 If you know of any evidence for any of these please add a comment on this page, if possible link to the usability study.
4
5
6 == Positive contractions ==
7
8 We know negative contractions cause issues for some users. Do positive contractions also reduce readability for people with dyslexia, low vision and learning difficulties?
9
10
11 == Link placement in sentences ==
12
13 We have evidence that mid-sentence links cause readability issues. But one evidence items is slightly ambiguous, another is in an unreadable format and 2 sources are behind a paywall.
14
15 === Paywall or member content ===
16
17 These are locked:
18 [[IEEE Xplore Digital Library – Imprudent linking weaves a tangled Web>>https://ieeexplore.ieee.org/document/596641]]
19 [[SAGE Journals – Explicitness of local navigational links>>https://journals.sagepub.com/doi/abs/10.1177/0165551506068144]]
20
21 Can anyone access them for the project?
22
23 === Autism ===
24
25 We have anecdotal evidence suggesting mid-sentence links cause difficulty for autistic users. But do not know of usability studies or academic papers to support this specifically. 
26 \\Does anyone know of usability research around mid-sentence links and autistic users?
27
28
29 == Numbers ==
30
31 Does type font sufficiently reduce any confusion people experience between 1 (one), l (lowercase letter l) and I (uppercase letter i) and 0 (zero) and O (capital letter o)? Is it enough to recommend writing sentences another way to avoid this or do we need special style rules for 0 and 1 in long form copy? Should we recommend removing these from automatically generated passwords and customer codes?
32
33
34
35
36 == Punctuation and screen readers ==
37
38 We know users can:
39
40 * configure their screen reading software
41 * adapt to idiosyncrasies of software
42 * use software that learns user preferences
43 * comprehend spoken text at very high speeds
44 * slow down, pause and replay spoken text for clarity
45
46
47 But we would still like to know if having punctuation, for example "en dash", read out is problem, even a low level one, for any users. As we can alleviate that type of thing with sensible content readability guidelines. That is what they are for.
48
49 Can we gather a comprehensive list of how screen readers read out dashes? And find out what they do with hyphens? Can we comprehensively research screen readers with other punctuation that conveys meaning or adds nuance, like brackets?
50
51
52 == Our approach ==
53
54 First we're searching through existing usability evidence available from:
55
56 * [[Abilitynet – resources>>https://abilitynet.org.uk/free-resources]]
57 * [[WEBaim – articles>>http://www.webaim.org/articles]]
58 * [[Digital Accessibility Centre – resources>>http://www.digitalaccessibilitycentre.org/index.php/resources]]
59 * [[RNIB linked site – accessible websites>>https://www.sightadvicefaq.org.uk/independent-living/technology/accessible-website]]
60 * [[Scope – designing content for everyday equality>>https://www.scope.org.uk/news-and-stories/designing-content-to-achieve-everyday-equality]]
61
62
63 Then, if applicable, we'll investigate carrying out new usability testing.