Re: Distinguishing different aspects of accessibility

On Aug 4, 2007, at 00:00, Sander Tekelenburg wrote:

>> Do deaf users generally wish that UAs suppressed or compacted
>> indicators of non-decorative (decorative being those marketing site
>> background jingles) audio content availability? (This is an honest
>> question. I don't know.
>
> I don't know either, but whether they do or don't, there's still  
> the argument
> that forcing users to choose between equivalents is 'bad'.

Perhaps this should be approached by finding out the actual user  
needs are through observational user testing to see which choices  
presented to users actually cause badness by, for example, slowing  
users down.

My hypothesis is that some scenarios cause more slowing down than  
others (because different browsing situations have different  
properties when it comes to skimming over content one doesn't want to  
read in detail) and if so, we should probably only address the cases  
where addressing the case involves a clear win instead of addressing  
all cases involving alternatives for the sake of overall consistency.

> Note that I'm think of a general indicator here.

On the page-level as in the feed case or local to the rendering of  
the part of content that has a hidden (except for the indicator)  
alternative?

> Not ideal, but hopefully good enough for
> this discussion's attempt at understanding each other, might be a  
> cursor
> change on hover, and a listing and access to the equivalents through a
> contextual menu. [But this is jumping to UA implementations again,  
> before
> establishing agreement on actual needs.]

FWIW, I think a cursor change on hover is a rather awful indicator in  
terms of discoverability. It requires the user to scan the page with  
a cursor to find out if alternatives exist.

>> That is, would it be important to
>> suppress or compact a link "Download podcast" if there was a link to
>> transcript next to it?)
>
> Unless I'm the only one who thinks that *many* users would be  
> confused by
> being forced to choose between equivalents, yes.

I guess the best way to answer this would be getting observational  
data on how deaf user react to pages with "Download podcast" compared  
to mockups where the audio link has been suppressed.

I wonder if the participants who work on Web accessibility have  
pointers to pre-existing research of this kind.

> By default, in the sense of "fallback", whichever is defined as  
> preferred. A
> sensible factory default would probably be PDF, but the user should be
> allowed to change that default to PowerPoint.

Wouldn't that involve asking the user to order a list of known file  
formats to an order of preference? Seems like a task one wouldn't  
want to put forward to J. Random User.

>> The user but not the browser can probably guess that the PowerPoint
>> file is the master file and the PDF was generated from it.
>
> Is that really relevant?

For the purpose of guessing if something has been "lost in  
translation", yes.

>> But what if the page said this
>> <p>Presentation Foo Bar is available as a <a
>> href="foobar.ppt">PowerPoint file</a> and as a <a
>> href="foobar.pdf">PDF without animations</a>.</p>
>
> I think this merely underlines that "PowerPoint" is not an appropriate
> description of a *type* of equivalent (one reason why I have my  
> doubts that
> the type attribute could/should be used). Probably appropriate would:
>
> <p>Foo Bar is available as a <a
> href="foobar.ppt">animated presentation</a> and as <a
> href="foobar.pdf">pretty text with images</a>.</p>

If the motivation for providing alternatives is to cater to users who  
are differently equipped to consume different file formats, it seems  
to me that trying to hide the file format aspect of the choice is  
entirely counter-productive and does a disservice to the user.

> But the file format *alone* doesn't serve most users. Quite the  
> contrary.
> Many won't know what PDF is, let alone what PowerPoint is.

Quite a few users know what PDF and PowerPoint are. For those who  
don't, how would "animated presentation" and "pretty text with  
images" allow them to make an informed choice?

> By default, in the sense of "fallback", whichever is defined as  
> preferred. A
> sensible factory default would probably be PDF, but the user should be
> allowed to change that default to PowerPoint.

I have rather serious doubts about the UI feasibility of such  
configuration, because it isn't just about PowerPoint vs. PDF but  
about various file format juxtapositions in various contexts  
depending on whether the user is seeking a read-only file or  
something to remix.

> A tool that encourages or even just allows authors to define  
> somethign as
> equivalent makes that just as visbile as a text editor does.  
> Perhaps even
> more so, because such a tool can do that through more user-friendly
> terminology than HTML can.

Considering the UI paradigms in use, it is pretty hard to beat the  
obviousness of the presence of textual prose. Making invisible  
metadata visible would involve a novel visualization (in visual  
editors) and would necessarily be against WYSIWYG if the data being  
visualized is invisible in a usual visual browser.

>> If software were smart enough to figure out whether explicit
>> assertions are lies, why bother with making explicit assertions in
>> the first place instead of letting the software do its smart thing?
>
> I understood you to say that current search engine technology is  
> smart enough
> to index prose, ignoring markup.

Moreover, e.g. Google Scholar, AFAIK, uses the layout conventions of  
scholarly publications for extracting data that is not explicitly  
marked up.

> If that's the case, then I don't see why it
> couldn't compare its indexed prose with the content of explicit  
> 'invisible'
> metadata.

Would there be any case where if the comparison resulted in a  
"invisible metadata disagrees" result, the search engine would want  
to use invisible metadata nonetheless?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 6 August 2007 09:18:13 UTC