Password reset for wiki

Hi there,

Can anyone tell me where I can reset my password to access the editing features of the wiki?

I can't remember what my password is and can't find a place to reset it either.

Thanks,

/Denis



On 2010-06-02, at 11:45 PM, Philip Jägenstedt wrote:

> I'm still unsure who these requirements are for. If they are *user needs* (as John Foliot stated in his last mail) then we should remove any reference to the underlying technology. The requirement should be that it's possible to switch between alternative audio tracks. If this is achieved by multiplexing several audio tracks into a single file or playing two separate resources in sync is really an implementation issue.
> 
> I don't think many (any?) of the requirements are impossible on a desktop PC, but the web is not just for the desktop. If something is simply impossible to implement on an important category of hardware, then that makes a big difference to how strong the requirement can be and the willingness to implement it at all.
> 
> Regardless who these requirements are for, the specific problems from an implementor perspective are in the survey results, so I won't go into any more specifics here.
> 
> Also, thanks to those who helped put this together. It's my job to give constructive criticism, so I hope it doesn't come across as anything else.
> 
> Philip
> 
> On Tue, 01 Jun 2010 08:28:20 +0800, Janina Sajka <janina@rednote.net>
> wrote:
> 
>> I cannot claim expertise in all the areas covered by our requirements
>> document. I am not, for instance, particularly knowledgeable on
>> captioning. However, as far as I can tell, this is a requirements
>> document and not a wish list. We're talking about what it takes to make
>> multimedia accessible to a wide range of users with disabilities.
>> 
>> 
>> I can understand that all devices will not support all users. I don't
>> have a problem with that. However, it would be most inappropriate to
>> attempt to remove requirements to get to some minimal specification that
>> is arguably supportable on the most scaled down device. It just may have
>> to be acceptable that some devices will not fully support accessibility.
>> Certainly, that wouldn't be anything new in the marketplace. What's
>> important is that we know what it takes to support users with
>> disabilities, and our require4ments constitute, imho, an excellent start
>> at quantifying that.
>> 
>> 
>> Let me ask it this way -- What in our requirements is unsupportable on
>> today's desktop PC? What have we specified that a quad-core with a gig
>> of RAM can't perform? That's were I'd like to start. From there we can
>> identify what small devices can, and can't do. Perhaps small device
>> manufacturers might look at these requirements as a way to quantify to
>> potential customers what devices are likely to serve them. That doesn't
>> happen today. Walk into any cell store as a blind user, and you get
>> confusion or sheer bluster from the sales staff--if you get any help at
>> all. Well, maybe these requirements give us a start of specifying what
>> is, and isn't supported, in product docs--directly. That would be a
>> major win, imho.
>> 
>> 
>> Janina
>> 
>> Silvia Pfeiffer writes:
>>> Hi Eric, and also Philip,
>>> 
>>> I agree that there are many details that we need to address in the
>>> requirements document and it will be great to start a detailed
>>> discussion about every single topic brought up in the requirements
>>> document. I also think that some of the requirements may well go
>>> beyond what is technically possible now. However, I do not think that
>>> it is the aim of the document to only specify what should actually go
>>> into HTML5 now. Instead, I look at the requirements document simply as
>>> a wishlist created by folks with an accessibility background of things
>>> that would be awesome to have around audio and video on the Web. And I
>>> think it is good to capture this, even if some of it can not (yet)
>>> technically be realised.
>>> 
>>> It is also important, though, for accessibility folks to understand
>>> that this is a wishlist and may not result in all of this technology
>>> actually being available in HTML5 in the near future. Thus, it is good
>>> to flag this early.
>>> 
>>> Maybe we need to make a general addition to the document stating this
>>> clearly? John, Janina, what do you think?
>>> 
>>> Also, we need to take on board the points where Eric and Philip have
>>> directly pointed out that sentences/requirements are not
>>> comprehensible and explain these better.
>>> 
>>> I suggest what we do with your inputs is the following:
>>> 1/ add an explanation at the top that this is a list for what should
>>> be made available in a perfect world and that this may result in a
>>> long-term work-plan with some more important dimensions solved earlier
>>> than others. Maybe we can even come to an agreement on what is of
>>> higher priority?
>>> 2/ go through and fix up the requirements that are not understood.
>>> 3/ start discussions on the mailing list for every single section to
>>> get closer towards technical recommendations on how it could be done
>>> in HTML5.
>>> 
>>> Cheers,
>>> Silvia.
>>> 
>>> 
>>> On Sat, May 29, 2010 at 9:38 AM, Eric Carlson <eric.carlson@apple.com> wrote:
>>> > All -
>>> >   I haven't responded to the WBS survey yet, but here is my feedback.
>>> >   I think there are enough issues with the document that it would be helpful
>>> > for the task force to have a discussion via email to sort it all out.
>>> > eric
>>> >
>>> > Audio Description
>>> > This content type will be very difficult or impossible to support on some
>>> > resource constrained devices because it requires the media engine to decode
>>> > and play more than one audio stream simultaneously. For example, with the
>>> > audio chips used in many modern cell phones  it is impossible to decode and
>>> > play more than one stream of digital audio data at a time.
>>> > • (AD-4) Any digital audio format should be able to handle "real human
>>> > speech", it doesn't need to be called out. Synchronizing audio
>>> > and video loaded from  different files can be very difficult to do well.
>>> > • (AD-5) and (AD-6) These require multiple audio streams to play
>>> > simultaneously. This is not possible on all devices.
>>> > • (AD-7) What does "The degree and speed of volume change should be under
>>> > provider control" mean? Is it really crucial for this feature?
>>> > • (AD-9) We have not been able agree on required audio and video codecs,
>>> > what makes you think we will be able to agree on a code specialized for
>>> > speech? Is it really required?
>>> > • (AD-11) This requires multiple audio streams to play simultaneously. See
>>> > above.
>>> > • (AD-12) What does this mean? What are programs and channels?
>>> >
>>> > • (AD-13) I have no idea what this means.
>>> >
>>> > • (AD-14) What does "support metadata" mean? Digital media files can already
>>> > carry metadata, is the requirement to expose it to the DOM?
>>> >
>>> > Texted Audio Description
>>> > If we want people to be able to create interoperable pages, this requirement
>>> > must specify a TAD file format.
>>> > (TAD-1), (TAD-2),  (TAD-4), and (TAD-5) Aren't these all requirements for
>>> > the TAD file format?
>>> > (TAD-3) This won't be possible on all platforms, for example devices that
>>> > only allow one mode of audio output.
>>> >
>>> > Extended audio description
>>> > This is impossible to evaluate without a specification for an EAD file
>>> > format. WCAG2 recommends using SMIL 1 or 2, which would be an *enormous*
>>> > implementation burden an a UA.
>>> >
>>> > Clear audio
>>> > (CA-1) - (CA-3) These require a UA to play multiple tracks of audio
>>> > simultaneously. As previously noted, this is not possible on all devices.
>>> >
>>> > Content Navigation by Content Structure
>>> > This will require a mandated CN file format if we want interoperable
>>> > content. The two formats mentioned are quite complex and will require
>>> > enormous implementation effort. Do we actually *require* that level of
>>> > sophistication?
>>> > (CN-2) - This may not be possible with all CN formats as not all are
>>> > self-contained.
>>> > (CN-3) - (CN-5) These are functions of a CN file format.
>>> > (CB-8) - (CN-10) I don't know what these mean.
>>> >
>>> > Captioning
>>> > (CC-1) Not all media files have audio.
>>> > (CC-17) Does this mean that captions are rendered from more than one
>>> > external caption file simultaneously?
>>> > (CC-25) What must a UA do differently for edited vs full verbatim captions?
>>> >
>>> > Extended Captioning
>>> > (ECC-1) What does this mean? What is the format of "metadata markup"?
>>> > (ECC-2) What are "other activation mechanisms"?
>>> > (ECC-4) How does this work? Who decides if "overlap is OK ..."?
>>> >
>>> > Sign Translation
>>> > Decoding and rendering multiple streams is even more difficult with video
>>> > than with audio. Video decoding hardware used in many mobile devices is not
>>> > able to decode more than one video stream simultaneously.
>>> > (SL-1) and (SL-3) Playing multiple media files in sync is not currently
>>> > supported by HTML5, and will be a significant amount of work for some UAs.
>>> >
>>> > Transcripts
>>> > (T-2) Does this affect page layout, eg. does change the size of the <video>
>>> > element or appear above other page content?
>>> > How will this work on a device with a small screen or a device that only
>>> > allows fullscreen playback,?
>>> > I don't understand "If the author chose to create a new interface using
>>> > scripting, that interface MUST map to the native controls in the user
>>> > agent". Controls implemented with scripting should *use* the same interface
>>> > to control a media file, but they do not use the native controls. Like
>>> > Philip, I suggest we add a requirement that it must be possible to enable
>>> > native controls even if a page has custom controls.
>>> >
>>> > Granularity Level Control for Structural Navigation
>>> > I don't understand this requirement at all.
>>> >
>>> > Time Scale Modification
>>> > (TSM-2) As I have noted before, it is not possible to change speed without
>>> > changing pitch on all devices that are capable of playing digital audio.
>>> > (TSM-3) - (TSM-5) These are already required by the HTML5 spec.
>>> >
>>> > Production practice and resulting requirements
>>> > This is advice for people authoring media, not HTML. It isn't something the
>>> > HTML WG needs to consider.
>>> >
>>> > Discovery and activation/deactivation of available alternative content by
>>> > the user
>>> > (DAC-1) - (DAC-1) How will the user control reflow and layout?
>>> > (DAC-4) Isn't this fundamental to the concept of an alternative? If it needs
>>> > to be mentioned at all, it should be in the section(s) about specific
>>> > alternatives.
>>> > (DAC-5) This needs to be fully specified, eg. what happens when alternative
>>> > content doesn't fit into the <video> region, etc.
>>> > (DAC-7) This should be mentioned in the section(s) about alternative
>>> > content.
>>> > (DAC-8) This changes behavior of 'autoplay' and 'preload', say so.
>>> >
>>> > Requirements on making properties available to the accessibility interface
>>> > (API-4) Why is this an issue for the HTML WG?
>>> >
>>> > Requirements on the use of the viewport
>>> > (VP-3) Need details about how this is supposed to work, eg. does the video
>>> > pop up over the page content or does the rest of the page reflow? Is page
>>> > zoom enough? "with the ability to preserve aspect ratio" - when would the
>>> > user ever not want to preserve aspect ratio?
>>> > (VP-5) All existing browser, and many stand-alone media player applications,
>>> > place controls along the bottom edge of the movie. Where should they go
>>> > instead?
>>> >
>>> > Requirements on the parallel use of alternate content on potentially
>>> > multiple devices in parallel
>>> > (MD-3) I don't understand this, an example would be helpful.
>>> > (MD-4) "This assumes the video element will write to the DOM" - does this
>>> > mean the media element's properties are accessible via the DOM?
>>> > (MD-5) "e.g., by checking a box ..." because this document is about *media*
>>> > accessibility, the example should be about a media element
>>> > (MD-7) I don't understand this.
>>> >
>>> > On May 27, 2010, at 9:58 PM, John Foliot wrote:
>>> >
>>> > Hello All,
>>> >
>>> > I just wanted to send out a quick note about this very important survey
>>> > (scheduled to close Wednesday, 2 June 2010), which is envisioned as much as
>>> > a straw poll as anything else.
>>> >
>>> > It is important that this document be *very* right, as it will become the
>>> > basis for a number of critical decisions moving forward, and having a
>>> > complete Requirements Document will be hugely beneficial when it comes to
>>> > some differing views down the road, as it will contribute significantly in
>>> > removing 'emotion' from the discussion (and having broad consensus within
>>> > the Task Force will be important).
>>> >
>>> > Even if you really don't think you have much to contribute here, please take
>>> > a few minutes to review what we have... maybe we *do* have it right, but
>>> > this really is a "many eyes" work effort at this time, and if one extra
>>> > requirement or equivalent feedback comes back that improves what we have
>>> > then it has been a worthwhile exercise. As well, if you know individuals or
>>> > organizations in your locality that might have something to contribute, feel
>>> > free to solicit their feedback as well.
>>> >
>>> > Survey:
>>> > http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/
>>> > (Note the Draft Requirements are listed in the survey)
>>> >
>>> > Requirements:
>>> > http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements
>>> > (for those not part of the TF, but may have feedback)
>>> >
>>> > (If you know of any such individual or group, but require more time for
>>> > their feedback, please ping me.)
>>> >
>>> > Thanks in advance for your participation!
>>> >
>>> > JF
>>> >
>>> > **************
>>> >
>>> >
>>> > A survey on media accessibility requirements is available:
>>> >
>>> > http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/
>>> >
>>> > The media sub-group discussed this survey 26 May 2010 and it was announced
>>> > to the general task force 27 May 2010. This survey is to gather opinions
>>> > on Media Accessibility Requirements. Each of the Alternative Content
>>> > Technologies and System Requirements are separately presented for feedback.
>>> >
>>> > As a point of interest, there are 110 numbered requirements, with a lot of
>>> > related explanatory material. In the survey this is presented as 17 separate
>>> > questions for input. Please allocate enough time to complete this survey. ;)
>>> > The survey is currently scheduled to close Wednesday, 2 June 2010, at the
>>> > end of the day Boston time.
>>> >
>>> > If you need to work on this in multiple sessions, you can always enter as
>>> > many answers as you can, submit them, and return to the survey later. It
>>> > will still have your original answers and will allow you to modify them and
>>> > enter new answers. Just remember to submit your work at the end of each
>>> > session.
>>> >
>>> > Michael
>>> >
>>> >
>>> >
>> 
> 
> 
> -- 
> Philip Jägenstedt
> Core Developer
> Opera Software
>

Received on Thursday, 3 June 2010 05:39:31 UTC