Gitter Channel Archive 12th of September 2017
Gitter Channel Archive 12th of September 2017
What fresh hell is THIS now? - Patrick Lauke
Hmm, I think it's what ugi said. I just thought it had a name. People do it all the time in Sass (often using a lightness conditional statement, mayabenari) to generate this contrasting color.
I really thought it had a common name. I thought it was like me describing a "cylindrical rotating door appendage" and I was waiting for someone to say "you mean a door knob?"
[phoebe] Hi, I have some upcoming usability testing where we’d like to test users who are visually impaired. The team has said they only want to test two people who are blind. I think that number is too low and that we should also test people who are low-vision or color-blind, as well. In the past, my company has only usability-tested for accessibility a handful of times, during which we were thrilled if we could test 2-3 people (I’m honestly not sure why we only tested 2-3 people each time, all of which were blind. I think my manager at the time was going for extremes and assumed any changes made for blind users would cover any issues other visually-impaired users would have).
About the system we’re wanting to test: It’s a touchscreen with accessibility controls, such as screen reader, color contrast controls, volume controls, and font size controls. There is also a handset you can use instead of navigating with your fingers. The color contrast, volume and font all meet WCAG 2.0 AA standards. There is no flexibility at this point regarding semantic order (unfortunately). However, the screen reader copy (Google TalkBack) and handset controls are basically blank slates that we’ll have to determine based on testing.
My questions for you all are:
A. Is two people too few? If so, how many users is enough to start seeing trends, especially if we’ll most-likely have varying levels of familiarity with Google TalkBack and the specific kind of system we’re testing?
B. I really think we should be testing with a few people who are low-vision or color-blind, but I’m struggling to come up with an argument for this because (a) we’ve never tested either user group before for any of our other products and (b) the team I’m working with knows the system already meets WCAG standards, so when I’ve brought it up with them in the past, they just tell me it already meets the standards.
Any thoughts or help on this would be hugely appreciated. Thank you!
[ghanek] It sort of depends on what you expect to get from the testing. If you want to find out points of friction in that design (aka where does this design suck?) then Nielsen et al have shown that 5-6 representative users are sufficient. If you want to know if your design is actually good, then you'll need at least 30 users (I know T. Frick published a study supporting this assertion.)
Is two people too few? If so, how many users is enough to start seeing trends, especially if we’ll most-likely have varying levels of familiarity with Google TalkBack and the specific kind of system we’re testing?
[elisaf] I've got a two-fold question.
I'm working on a web app where users can upload their own images to put into a gallery. Devs made it so that there is a required "caption" field that defaults to the file name because they can still bulk upload hundreds of photos. They can certainly change it to be descriptive for the photos (as we made it so that caption is the generated alt text) -- *Is this acceptable?*
Second question: We are migrating an existing group of people from a different application into ours. The previous app did not require any sort of description for the photo, and they did not retain any file names. What should be the acceptable route here considering having something for alt text is required?
alt attribute is required. Text is determined by the image context, whether it adds content or is just decorative, etc.
DSCSBCS4757.jpg does not communicate a lot of information about a photo’s contents
[svinkle] @elisaf, to @eric’s point, you may want to consider something like:
if image.caption then alt = image.caption else alt = gallery.description endif
At least then the alt won’t be empty and the image will “appear” when navigating through the gallery. Not exactly ideal though. (thinking face emoji)
alt. Thinking here if the photo is on a bio page, and it’s next to the persons name; having the name as the alt would be redundant if in close proximity to the name.
[elisaf] Maybe some context would help? The only photos that exist that aren't just a decorative element are uploaded into the photo albums.
If It's the "Apiary Club" which is basically beekeeping club, they might have an album that is "9/24 Weekend Beekeeping Outing," which may or may not have a description, and most of the photos are of people outside with suits on near the little hive things (sorry, no idea what they're called), or pictures of bees and segments of honey.
[laura.ciporen] @elisaf, in terms of user experience for those relying on screen readers, having an empty alt attribute would be preferable than having the file name. File names are often long strings of gobbledygook which provide no information anyway. Personally, if I were a user, I would rather hear nothing than a long string of gobbledygook that provides the same amount of information as not hearing anything. Then it would also be easier for users to find the images that do have alt descriptions and thus are accessible.
And if there are lots of clubs that take pictures of the same things all the time, perhaps there could be a club-created list of alt text options that could be chosen from a dropdown to make adding tags to lots of images simpler. Alongside that, could be an easy way to add the names of people who are in the images (from a list of club members) so you could wind up with "Jenny, Mike, and Joe at their hive harvesting honey" without too much work. ::shrug::
[svinkle] > gobbledygook
(sweat smile emoji)