Thread Subject: Re: "closed software"

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Gregg Vanderheiden
Date: Wed, Jan 03 2007 8:10 AM

I thought of that as I wrote it.

Well, since it is built into the OS, the application that work with it would
be directly accessible since they are accessible without needing any AT.
Remember that any software with access built in would need to rely on OS
functions (speech, sound, keyboard etc). this would also rely on the
voiceover functionality.

Since they have an API - it would ALSO be compatible with any AT that was
out there.

Having an API only though - without AT support would not be accessible (i.e.
usable with people who have disabilities) if there was no AT. That is why
Apple built it into their system and have an API. They support AT but are
not subject to AT availability - which was a problem for them - at least for
screen readers.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> David Poehlman
> Sent: Wednesday, January 03, 2007 4:38 AM
> To: TEITAC Web/Software Subcommittee
> Cc: 'TEITAC self contained/closed products subcommittee';
> 'TEITAC General Interface Accessibility Subcommittee'
> Subject: Re: [teitac-general] [teitac-websoftware]
> [teitac-closed] "closed software"
>
> greg, am I to understand then that your #2 excludes the Mac
> which has its ownn AT?
>
> On Jan 3, 2007, at 1:02 AM, Gregg Vanderheiden wrote:
>
> Hi Norman,
>
> I agree with your premise that there shouldn't be any closed software.
>
> But if there is software that is closed (not accessible to
> AT) for any reason (business, technical or security) then we
> do want to require that it
> is accessible - no? And I believe that there will be legitimate
> arguments
> for some places where the software will be closed - and/or
> that there will be no AT developed for or that can be used
> with the product.
>
> I'm not talking about desktop computers necessarily.
>
> What if we just said
>
> 1) that products need to be accessible either via available
> assistive technology or directly accessible.
>
> 2) that products that require productivity (e.g.
> workstations) need to be accessible to assistive technologies
> to allow matching of user abilities necessary to achieve high
> levels of productivity.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Robinson,
> > Norman B - Washington, DC
> > Sent: Wednesday, December 27, 2006 2:54 PM
> > To: TEITAC self contained/closed products subcommittee; TEITAC
> > Web/Software Subcommittee
> > Cc: TEITAC General Interface Accessibility Subcommittee
> > Subject: Re: [teitac-general] [teitac-closed] "closed software"
> >
> > Since I earlier offered a different perspective on "closed
> software",
> > I thought I would respond to each item.
> >
> > 1. Security reasons: Security should be a part of a
> requirement in the
> > same way accessibility should be a part of the requirement for a
> > product. First, security options _CAN_ be accessible (e.g.,
> accessible
> > CAPTCHAs or accessible login screens). Second, where there is a
> > technical determination that no access to application programming
> > interfaces (APIs) that work with assistive technology is allowed,
> > there is a business justification. No matter what assistive
> technology
> > can do, if the system designed to block user interaction to
> only one
> > type of system interface for business reasons, that is an
> exception.
> > However, I'd be amiss if I didn't say see "First".
> >
> > 2. Besides semantics, and debating among friends, software
> can't run
> > without an operating system unless it, itself, IS the operating
> > system.
> >
> > 3. What is the point of making a classification of "CLOSED
> SOFTWARE"?
> > What does it mean to us in context of Section 508? Your
> example is one
> > of being accessible through design. I'd say the example
> doesn't help
> > the argument and problem we are trying to solve (if you'll please
> > forgive me). We are concerned when software doesn't work with
> > assistive technology and isn't designed to be accessible.
> I'd also say
> > I have the expectation that this software is generally only used in
> > conjunction with specialized hardware. Firefox web browser was
> > considered to be too small a market for certain AT vendors.
> What does
> > that mean? I think they have an API. I think this is complex
> > interaction of _accessibility interfaces_ dependent on the
> operating
> > system. Sorry, I'm an Amiga/Windows/OSX/Linux user and it varies
> > considerably. It is too easy to just think in context of
> one platform,
> > especially when embedded operating systems in phones are so
> plentiful
> > and experiencing these same issues. Sorry to ramble, I
> think I need to
> > discuss this some more.
> >
> > 4. Platform software issues are interesting. Is commercial
> > availability exemptions? Tying it to vendor product and 'official'
> > support is dangerous too; I'm sure my MS Windows vendor doesn't
> > support me running Linux on my corporate desktop, but the screen
> > reader and web browser works just fine for most of my
> needs. I think
> > that is close to the earlier iPod firmware upgrade. But who cares?
> > Even if a 3rd party or Apple made the software as an add-on to the
> > product it can be made accessible. The debate so far has focused on
> > the vendor not developing assistive technology. Third
> parties do and
> > you can make things accessible without assistive technology.
> >
> > Sorry to disagree, but the closed software approach doesn't
> work well
> > for Section 508 evaluation. I can't help but feel we're not
> asking the
> > right questions. DRM is bad for end-users, security typically
> > negatively impacts end-user experience, and accessibility
> is all about
> > the user!
> > This discussion is really useful for questioning vendors
> and how they
> > support our business/agency. I don't think finding
> justification for
> > closed software means we should place a label on software
> and treat it
> > any differently from any other software. Closed software should be
> > accessible and follow the same technical standards as any other
> > software.
> >
> > Regards,
> >
> >
> > Norman B. Robinson
> > Section 508 Coordinator
> > IT Governance, US Postal Service
> > phone: 202.268.8246
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
> > Vanderheiden
> > Sent: Tuesday, December 19, 2006 12:45 PM
> > To: 'TEITAC self contained/closed products subcommittee'; 'TEITAC
> > Web/Software Subcommittee'
> > Cc: 'TEITAC General Interface Accessibility Subcommittee'
> > Subject: Re: [teitac-closed] "closed software"
> >
> >
> > Some possible examples of closed software.
> >
> > Maybe some things like: (numbered only to facilitate discussion)
> >
> > 1 - Software that for security reasons does not allow anything to
> > access what it has on screen and which reads keyboard registers
> > directly to avoid tampering or 'remote' typing.
> >
> > 2 - Software designed to run on a product without and operating
> > system.
> >
> > 3 - Software that has no API for AT - but instead has built in
> > accessibility since there is no AT vendor who will work with and
> > support the unique capability of the software because the market is
> > too small for AT vendors.
> >
> > 4 - Something like Randy pointed to (see just below). The
> hardware is
> > not closed since new software can be loaded. But the
> > platform/software is closed.
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University