Re: Distinguishing different aspects of accessibility

On Aug 6, 2007, at 4:17 AM, Henri Sivonen wrote:

>
> On Aug 4, 2007, at 00:00, Sander Tekelenburg wrote:
>
>> 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.

No, that's not necessarily true. If a user is curious about  
alternative equivalents, they're interested in the equivalent of the  
focussed element. In other words they only need to hover (or focus)  
over the embedded content they're currently interested in. A browser  
could offer a feature to show all embedded content and their  
equivalents (through e.g., a hierarchical list view), similar to the  
way they provide a list of links on a page. But that would be an  
extra UA feature, and not something required to use thee features  
we're discussing here.

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

Many times a user wouldn't have a reader or editor for a particular  
content type installed. The UA could easily eliminate all of those  
from consideration. When an author provides so many rich  
alternatives, the user would need to make a choice. That doesn't  
sound like a bad thing to me. Web authors would need to weigh the  
benefits of adding more varied alternates to the costs of slowing  
users down. However, everything we've discussed has included a  
primary default equivalent that would be presented to users without  
any user intervention.

> [... ]
>> On Aug 6, 2007, at 4:17 AM, Henri Sivonen wrote:
>>> 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.

The content type would not be hidden. It just doesn't require  
redundant exposition by the web author. The UA should have the  
ability to describe in a natural language localized way any content  
type it can consume given the OS environment (and what's installed on  
the system).

>
>> 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?

Again, the UA can convey the type information without any author  
intervention at all.

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

I imagine a user who has both a PDF editor and a PowerPoint editor  
would need to know that the PowerPoint alternate would probably give  
them more editing control than the PDF alternate. UAs could be built  
with such information, but that's far from the common case today.  
However, for a user that didn't know such things, it may also not be  
relevant. Or the user would just have to try each alternate until  
they found (learned) which one they needed.

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

UAs have been doing wonderful things with novel visualizations. I see  
no dearth of creativity from UA vendors when it comes to novel  
visualizations. It's not hard to imagine deployments of already  
existing GUI conventions to display alternates side-by-side (while  
still preserving an authors overall design). It's even easier to  
imagine already existing GUI conventions to alternatively display  
equivalents one at a time.

Take care,
Rob

Received on Monday, 6 August 2007 17:19:59 UTC