Thread Subject: Re: Some comments ontheSpreadsheet (excel/html)

Return to this mailing list's archives

From: Gregg Vanderheiden
Date: Sun, Jan 21 2007 3:15 PM
Subject: Re: Some comments ontheSpreadsheet (excel/html)

Comments marked GV:





Gregg



> -----Original Message-----

> From: David Poehlman

>

> Hi Greg and all,

>

> I may not be fully understanding the comments below correctly but

> I've placed my assertionss in line and only left those in which I've

> addressed. There are questions here but I hope this results in

> clarity where now some of it is unclear and that we gain informationn

> where things are not understood but should stand.

>

> Thanks!

>

> On Jan 20, 2007, at 10:53 PM, Gregg Vanderheiden wrote:





>> Comment #2

>> H11 says

>> This will be difficult to achieve with touch-screen devices. How do you

>> "feel" a virtual on-screen button before activating it?



>> This is a good comment. But most touch screen devices also have

>> tactilely

>> discernable buttons. (The iphone does for example). So we should add

>> "This would be difficult to achieve on a touch screen device unless all

>> information and functionality from the touchscreen are also

>> achievable using

>> the tactilely discernable controls.'





> dp I would say that it would also be possible to operate a touch

> screen if there were audible/otherwise (vibratory) discernable

> feedback and the ability to confirm selections.

>

GV: We did create an audible method for locating buttons on a screen. But
it only worked with a portion of people who were blind and is not
recommended. It doesn't work across people who are blind, it is
unreliable, and it only works on screens with a small number of items on it.
Vibratory would have the same problems. So, yes, theoretically some could
use this but no, you couldn't use this as a general approach for access to
touchscreens by people who are blind.









>> Comment #4

>> D18 says

>> Where provided, at least one of each type of expansion slots,vports and

>> connectors shall comply with available industry standards.

>>

>> Do we ever define what an industry standard is? The Ipod connector

>> is a

>> proprietary connector - but is a de facto standard since there is a huge

>> industry with many many companies that use it. They may pay a royalty.

>> But did you know that the standard phone connector that is on all

>> phone for

>> the last 30 years or so is a standard but you also had to pay a

>> royalty to

>> use it in a product (or you did til the patent ran out)? Ditto for the

>> HDMI connector. So what do we call a standard connector? Any

>> connector

>> that is used on a product? Any connector that is documented and other

>> companies can use?





> dp: I may be saying the same thing here but I think what we are

> trying to get at is that a power connector should look like a power

> connector. an ethernet connector shouldd look like one and so on.

> In other words, I wouldn't expect an ethernet connector to look and

> act like an usb connector danger will robinson, you just blew up your

> device..

>



GV: this provision is much more than that. it says that if you have
expansion ports, at least one should be a standard expansion port. We need
to really rethink this one in light of todays technologies to determine both
what would be of benefit and what is possible.







>> Comment #5

>> K18 says

>> This is important for AT, as it is the way to get "in" to the

>> device. USB,

>> Bluetooth are important. But having the hardware interface is only

>> half the

>> battle - software drivers are also necessary to accept and arbitrate

>> the AT

>> input. (Something for the Software subcommittee?)

>>

>> This is an excellent comment. And not covered in 508. maybe we

>> should say

>> "connection" instead of 'connector"



> dp: connection or connector might be a bit missleading since they

> both seem to imply hardware. I know that we talk about establishing

> a wifi connection or a bluetooth connection, but what we are actually

> doing is establishing communications between devices. I cannot think

> of one word that adequatelyy expresses the connection of hardware

> devices and establishment of communications in a non hardware way

> though.



GV: Connector is hardware. Connection is physical layer and more. As you
pointed out you can have a Bluetooth connection.

But if it is ambiguous then we may need to say specifically what we do mean.









>>

>> Comment #6

>> H20 says (in part)

>> Discussion on "BIOS" (basic input output system) of a computer. This is

>> used to make low-level adjustments to the hardware. Typically a

>> maintenance

>> activity. Some say BIOS needs to be accessible. Technical difficulties

>> since the OS is not yet running at the time of boot-bios, and normal

>> AT & IT

>> software not yet running. In some cases, bios settings can be done via

>> utility software after the computer has booted up from the normal

>> desktop.

>> Is that good enough?

>>

>> I would say that 'if access during boot up (done by bios software) is

>> part

>> of daily operation - like a company that requires you to have a bios

>> password that must be entered before a laptop will boot, then any such

>> interaction needs to be accessible. If the only time you need

>> access to

>> the bios routines is for settup or maintenance then you would only

>> need this

>> to be accessible if you determine that setup and maintenance need to be

>> accessible. And for setup- access when the laptop is fully booted

>> should

>> cover the issue.





> dp: this is a bit too fine a split. I think this can be addressed in

> one stroke such as something like: "access shall be provided to any

> maintenance operation which will be dperformed by a person with a

> disability.....?.



GV: The reason I raised it is that currently under 508 as implemented,
repair is not covered. The word maintenance is ambiguous because it
covers both repair and daily maintenance which could be adding paper to
personal printer or charging the battery (which clearly is covered).





>> Comment #8

>> K20 says

>> Categorization of levels of interoperability: 1) Not accessible by

>> itself,

>> and not compatible with AT; 2) Not accessible by itself, but compatible

>> with AT; 3) Accessible by itself, but not compatible with AT; 4)

>> Accessible by itself and compatible with AT. We need to address each of

>> these categories: which ones are 508 compliant, and which ones aren't?

>>

>> This is good. IF the users will have the AT required (or it would be

>> provided to them) I would say 2,3 and 4. If it required AT that the

>> users don't have and won't be given then I would say only 3 and 4. I

>> would presume all gov employees would be given the AT they need by

>> the gov

>> so #2 would always be ok but that members of the public would not and

>> that

>> for E&IT that the public would need to use to access gov info - one

>> would

>> have to look at what AT they are likely to have.

>>

>> I personally feel that for productivity devices such as a personal

>> computer

>> where you must be efficient to be competitive on the job that only

>> #2 and

>> #4 would be sufficient (i.e. AT compatibility would be required) but

>> some

>> people on the TEITAC have challenged that.





> dp: what does accessible mean? If number 3 is truly im play, it does

> not ever have to be accessible to AT.

> If number 3 is truly in play, number 4 does not need to exist. It's

> a shame for a product to be fully accessible but have the ability to

> disable the access so that someone can use their AT. Oh, I know, we

> don't want to have to learn something new and perhaps different, but

> if standards are followed, things aren't much different. I learned

> the MAC. It's accessible to me but different. I know all people

> aren't like me but then why not just give people something they can

> use in that case which is accessible thrugh their AT. I'm trying

> unsuccessfully it seems to put across something which comes down to

> the fact that if our goal is accessibility, we don't want to encumber

> its progrress or obstruct it.



GV: Not sure I understand the question here. The blank on the form talked
about the four situations that you can have. 3 of them yield
accessibility. Your Mac example is one of the ones that is in an accessible
category. Actually it is sort of in all three of the categories.







>

>

> Comment #9

> O20 says

> Section 1194.31 (f) We discussed the issue of why AT was left out of

> sub-part (f), when it was included in (a) - (e). We considered Doug

> Wakefield's explanation of this, which was that there were mechanical

> interfaces related to mobility impairments, for which there is not AT

> (such

> as laptop latches, on/off buttons, etc). The intent was to not let IT

> manufacturers "off the hook" for accessibility requirements for which

> there

> is no AT. The problem here is that there IS AT for other access problems

> related to people with mobility impairments (such as mouse and keyboard

> alternatives).

> We identified that there are access issues for which AT does not

> exist, and

> others for which it does. This is not a fact related to Mobility

> Impairments

> (sub-part f) only; it is the same for all types of disabilities. This

> bears

> out the need for a definition separating the Functional Performance

> Criteria

> into at least two categories: functions for which AT exists, and

> functions

> for which it does not.

>

> I think the way to address this is to change these to say

>

> "All functions are operable by [ insert disability type] through at

> least

> one mode of operation either directly or using AT that the users are

> likely

> to have with them."



> dp: Can we use something other than disability here? Is there a more

> operative way to express our intent? I only raise this because it is

> access which is important, not disability type? and also, one type

> of solution might fit several types?



GV: Sure - we could say "without vision, without hearing, etc." that
doesn't say the user doesn't have vision it just says the product should be
operable without vision. This approach too has problems when you play it
out but it is easier for developers. We should definitely explore both.

Note that these aren't solutions. They are functional requirements.
Solutions would be what you would use to meet the functional requirements,
and yes - solutions may address all or part of many different technical and
functional requirements. I'm going to take your suggestion to the General
Group since they are supposed to be looking at the functional criteria.

From: David Poehlman
Date: Sun, Jan 21 2007 4:25 PM
Subject: Re: Some comments ontheSpreadsheet (excel/html)

Greg, My responses inline and only what I've address is left. Thanks
for the explanations and clarifications.

GV: We did create an audible method for locating buttons on a
screen. But it only worked with a portion of people who were blind
and is not recommended. It doesn�t work across people who are
blind, it is unreliable, and it only works on screens with a small
number of items on it. Vibratory would have the same problems. So,
yes, theoretically some could use this but no, you couldn�t use this
as a general approach for access to touchscreens by people who are
blind.



dp: how can I find out more about this and more details about the
approach used?





GV: Not sure I understand the question here. The blank on the form
talked about the four situations that you can have. 3 of them yield
accessibility. Your Mac example is one of the ones that is in an
accessible category. Actually it is sort of in all three of the
categories.

dp: I missunderstood the intent of the categorization and you've
cleared it up. Thanks!



GV: Sure � we could say �without vision, without hearing, etc.�
that doesn�t say the user doesn't have vision it just says the
product should be operable without vision. This approach too has
problems when you play it out but it is easier for developers. We
should definitely explore both.

Note that these aren't solutions. They are functional requirements.
Solutions would be what you would use to meet the functional
requirements, and yes � solutions may address all or part of many
different technical and functional requirements. I'm going to take
your suggestion to the General Group since they are supposed to be
looking at the functional criteria.

dp: thhanks, I look forward to the discussion.