Salut,

 > comment savoir que un tel langage de programmation utilise  t-il les 
objet
du système lui même, ou ses objet à lui?
les objets control comme : edit, bouton, bouton d'option radio ... etc.

Je ne crois pas qu'il y ait un autre moyen que de se documenter et de 
tester.

 > autre question, peut-on dire que  les contrôles de tel langage est plus
accessible que les controls dans un autre langage de programmation?
les objets control comme : edit, bouton, bouton d'option radio ... etc.

En fait, ça ne dépend pas du langage de programmation, mais de l'API 
utilisée. Je suppose que tu fais la confusion parce que tu travailles 
avec des environnements qui regroupent tout, p.ex. visual studio, visual 
basic 6, ... c'est pas très étonnant, on fait facilement l'amalgamme.
Pour te donner un exemple parlant: je peux faire une GUI en C++ avec 
WXWidgets et ça sera relativement accessible, mais je peux aussi faire 
une GUI en C++ avec QT, et ça sera beaucoup moins accessible. Le langage 
n'a pas changé, seule l'API utilisée a changé.
Après, alors, effectivement, il y a des API qui produisent des 
interfaces assez accessibles, et d'autres beaucoup moins, jusqu'à pas du 
tout pour la majorité.

 > est ce que la portabilité des langages de programmation d'un système
d'exploitation à un autre, affecte le niveau d'accessibilité dans le
logiciel codé dans un système d'exploitation?

Encore la confusion API/langage. Si on parle strictement de langage, la 
portabilité n'a rien à voir: tu peux coder aussi bien une interface 
accessible en C/C++ qu'en python, java ou autre chose. ATtention au fait 
qu'une interface programmée dans un langage multiplateforme avec une API 
multiplateforme peut être très accessible sur un système et pas du tout 
sur un autre. Ca dépend de ce qui est utilisé.

Par contre si on parle d'API, alors là, oui, ça a une influence certaine !
En général, la GUI la plus accessible est celle produite par les API les 
plus proches du système: API Win32 sous windows, cocoa sous mac, GTK+ 
pour linux/GNOME, QT pour linux/KDE, etc.
Le problème, c'est qu'en ce qui concerne les bibliothèques de GUI 
multiplateformes, il y a deux façons totalement contradictoires de voir 
les choses.
1 - GTK, QT et java swing se concentrent avant tout sur une portabilité 
graphique. Autrement dit, l'aspect graphique des composants ne changent 
pas ou que très peu d'un système à l'autre. Pour y arriver, cela 
requiert souvent de ne pas utiliser les composants standards du système, 
mais de les émuler, ce qui permet d'avoir l'entier contrôle sur le 
dessin des composants (on n'a juste besoin d'avoir accès aux primitives 
de dessin de chaque OS). La conséquence logique, c'est qu'un composant 
émulé n'est pas du tout accessible, ou que partiellement. A moins 
d'utiliser des API d'accessibilité comme MSAA ou IAccessible2 et les 
équivalents sous mac et linux, mais encore faut-il que la bibliothèque 
de GUI y donne accès et que le développeur prenne le temps de l'intégrer 
à son programme. En gros, donc, c'est vraiment pas gagné, surtout que 
ces API sont très complexes. Petit inconvénient secondaire à cette 
technique, c'est qu'elle nécessite souvent beaucoup de mémoire.
2 - WXWidgets et java SWT eux par contre se concentrent sur utiliser au 
maximum ce qui existe déjà nativement sur le système d'exploitation où 
fonctionne le programme. Ils ne passent à l'émulation que si c'est 
vraiment nécessaire (si le composant n'existe pas sur le système cible). 
Le gros avantage, c'est que tous les composants natifs utilisés sont 
généralement accessibles d'office sans avoir à utiliser d'API spécifique 
complexe, au moins un minimum. Seuls les composants émulés ne sont pas 
accessibles ou que partiellement. Inutile de dire que pour nous, ce type 
de bibliothèque est beaucoup mieux ! Le gros problème, c'est que 
l'aspect graphique est différent d'un système à l'autre et peut varier 
pas mal, et ce manque d'homogénéité graphique entre les systèmes est 
très largement détesté par les voyants, qui préféreront donc utiliser 
les bibliothèques de la première catégorie.

 > est ce qu'il y a un langage de programmation préféré chez les 
personnes non  voyantes, si oui, pour quoi?

Quel joli lancer de troll dans la mare ! Perso je ne pense pas qu'il n'y 
ait véritablement de préférence ou de refus commun àt tous les non-voyants.
Par exemple personnellement je ne comprends pas comment les non-voyants 
peuvent être à l'aise avec python car il nécéssite d'être strict sur 
l'indentation qui est une chose qu'on ne peut pas facilement repérer au 
lecteur d'écran, mais c'est un avis personnel, beaucoup de non-voyants 
utilisent python et même plutôt bien puisque certains arrivent même à 
faire un lecteur d'écran avec.
Idem pour les environnements usines à gaz comme visual studio qui 
regorge de trucs pas accessibles ou pas optimaux selon moi, mais 
certains s'en accomodent très bien malgré tout aussi.
D'autres critiquent java pour sa lourdeur, C++ pour sa difficulté, php 
pour son aspect parfois un peu "langage de bricoleur", etc... mais tout 
cela n'est pas lié à la non-voyance.
Donc comme pour les voyants, ça reste à mon avis assez personnel et 
chacun défend sa ou ses langages de prédilection.

Progliste :
Pour se désinscrire de la liste : 
mailto:[email protected]?subject=unsubscribe

Pour voir les archives de la liste :
http://www.mail-archive.com/[email protected]/       

Pour accéder aux fichiers de la liste
http://outils.archive-host.com/partage.php?id=2Qar9Hy6ftzr
Pour y ajouter des fichiers demandez-moi le ou sur la liste ou en privé, je 
vous répondrez en privé.

Répondre à