Làm thế nào bạn có thể lập trình nếu bạn bị mù?

Thị giác là một trong những giác quan mà hầu hết các lập trình viên đều cho là điều hiển nhiên. Hầu hết các lập trình viên sẽ dành hàng giờ để nhìn vào màn hình máy tính (đặc biệt là trong thời gian họ ở trong khu vực ), nhưng tôi biết có những lập trình viên mù (như TV Raman hiện đang làm việc cho Google).

Nếu bạn là một người mù (hoặc dần dần bị mù), bạn sẽ thiết lập môi trường phát triển như thế nào để hỗ trợ bạn lập trình?

(Một gợi ý cho mỗi câu trả lời. Mục đích của câu hỏi này là đưa những ý tưởng hay lên hàng đầu. Ngoài ra, người đọc màn hình có thể đọc những ý tưởng hay trước đó.)

Tôi là một sinh viên đại học hoàn toàn mù, người đã có một vài kỳ thực tập lập trình nên câu trả lời của tôi sẽ dựa trên những điều này. Tôi sử dụng windows xp làm hệ điều hành và Hàm để đọc những gì xuất hiện trên màn hình với tôi trong lời nói tổng hợp. Đối với lập trình java, tôi sử dụng nhật thực, vì đó là một IDE đầy đủ tính năng có thể truy cập được.

Theo kinh nghiệm của tôi, theo quy tắc chung, các chương trình java sử dụng SWT làm bộ công cụ GUI có thể truy cập dễ dàng hơn sau đó các chương trình sử dụng Swing, đó là lý do tôi tránh xa netbeans. Đối với bất kỳ chương trình .net nào, tôi sử dụng visual studio 2005 vì đây là phiên bản tiêu chuẩn được sử dụng trong kỳ thực tập của tôi và rất dễ truy cập bằng cách sử dụng Hàm và một tập lệnh được phát triển để làm cho mọi thứ như trình thiết kế biểu mẫu dễ tiếp cận hơn.

Đối với lập trình C và C ++, tôi sử dụng cygwin với gcc làm trình biên dịch và emacs hoặc vim làm trình soạn thảo của tôi tùy thuộc vào những gì tôi cần làm. Rất nhiều thực tập của tôi liên quan đến lập trình cho Z / OS. Tôi đã sử dụng phiên rlogin thông qua Cygwin để truy cập hệ thống con USS trên máy tính lớn và C3270 làm trình giả lập 3270 của tôi để truy cập phần ISPF của máy tính lớn.

Tôi thường dựa vào lời nói tổng hợp nhưng có màn hình chữ nổi. Tôi thấy tôi thường làm việc nhanh hơn với lời nói nhưng sử dụng màn hình chữ nổi trong các tình huống có dấu chấm câu và trở nên phức tạp. Ví dụ về điều này là nếu các câu lệnh có nhiều dấu ngoặc đơn và JCL lồng nhau trong đó dấu câu là cực kỳ quan trọng.

Cập nhật

Tôi đang chơi với Emacspeak dưới Cygwin http://emacspeak.sourceforge.net Tôi không chắc chắn nếu điều này sẽ được sử dụng như một trình soạn thảo chương trình vì nó dường như là hơi không đáp ứng nhưng tôi đã không nhìn bất kỳ tùy chọn cấu hình chưa.

Tôi bị mù và đã lập trình được khoảng 13 năm trên Windows, Mac, Linux và DOS, bằng các ngôn ngữ từ C / C ++, Python, Java, C # và các ngôn ngữ nhỏ khác nhau trên đường đi. Mặc dù câu hỏi ban đầu xoay quanh việc cấu hình môi trường, tôi nghĩ nó được trả lời tốt nhất bằng cách xem người mù sẽ sử dụng máy tính như thế nào.

Một số người sử dụng môi trường nói chuyện, chẳng hạn như TV Raman và môi trường Emacspeak được đề cập trong các câu trả lời khác. Giải pháp phổ biến hơn cho đến nay là có một trình đọc màn hình chạy trong nền giám sát hoạt động của hệ điều hành và cảnh báo người dùng thông qua lời nói tổng hợp hoặc màn hình chữ nổi vật lý (thường hiển thị ở đâu đó từ 20 đến 80 ký tự). Điều này có nghĩa là một người mù có thể sử dụng bất kỳ ứng dụng có thể truy cập.

Vì vậy, cá nhân tôi sử dụng Visual Studio 2008 ngày nay và chạy nó với rất ít sửa đổi. Tôi tắt một số tính năng như hiển thị lỗi khi tôi nhập vì tôi thấy điều này gây mất tập trung. Trước khi gia nhập Microsoft, tất cả sự phát triển của tôi đã được thực hiện trong một trình soạn thảo văn bản tiêu chuẩn như Notepad, vì vậy một lần nữa không có tùy chỉnh nào.

Có thể cấu hình một trình đọc màn hình để thông báo thụt lề. Cá nhân tôi không sử dụng cái này, vì Visual Studio đảm nhận việc này và C # sử dụng niềng răng. Nhưng điều này sẽ rất quan trọng trong một ngôn ngữ như Python, nơi khoảng trắng quan trọng. Cuối cùng, Emacspeak sử dụng các giọng nói / cao độ khác nhau để chỉ ra các phần khác nhau của cú pháp (từ khóa, nhận xét, định danh, v.v.).

Tôi bị mù và là một lập trình viên trong 12 năm qua hoặc lâu hơn. Hiện đang là một kiến ​​trúc sư cao cấp và làm việc với Sapient Corporation (một công ty tư vấn dựa trên cambridge tạo ra cả các giải pháp doanh nghiệp dựa trên web và khách hàng dày). Tôi sử dụng một số trình đọc màn hình nhưng chủ yếu gắn với Hàm cho windows và NVDA.

Tôi đã làm việc chủ yếu trên nền tảng Microsoft và phòng thu trực quan như môi trường của tôi. Tôi cũng sử dụng các công cụ như phòng thu doanh nghiệp MS Sql và các công cụ khác để truy cập DB, giám sát mạng, v.v. Tôi đã cố gắng dành thời gian cho emacspeak nhưng vì công việc của tôi chủ yếu dựa trên nền tảng MS, không bao giờ thực sự dành nhiều thời gian ở đó. Tôi cũng đã dành vài năm làm việc trên C ++ trên linux - chủ yếu sử dụng notepad hoặc visual studio trên windows cho tất cả các mã hóa và sau đó samba để chia sẻ các tệp với môi trường linux. Cũng sử dụng borland C cho một số công cụ thử nghiệm. Gần đây đã chơi xung quanh với python, điều mà như những người khác đã lưu ý ở trên đặc biệt không thân thiện với người dùng mù vì nó được viết bằng cách sử dụng thụt lề làm cơ chế làm tổ. Đã nói rằng, NVDA, trình đọc màn hình nguồn mở phổ biến nhất được viết hoàn toàn bằng python và một số người cam kết trong dự án đó bị mù. Một câu hỏi đặc biệt thú vị mà tôi thường được hỏi với tư cách là một kiến ​​trúc sư là làm thế nào để tôi xử lý các sơ đồ - UML và visio và hoa hồng hợp lý, v.v. Visio có lẽ là công cụ lập sơ đồ dễ tiếp cận nhất hiện có. Tôi đã có thể viết các kịch bản hàm để đọc sơ đồ hoa hồng hợp lý cho tôi. Tôi đã sử dụng một công cụ gọi là T-dub (hiểu sơ đồ kỹ thuật cho người mù) được phát triển bởi một số trường đại học Đức để truy cập các sơ đồ UML 2.0. Đã sử dụng một công cụ xấu xí dựa trên java có tên là Magic draw để thực hiện phát triển theo mô hình và là một người chuyển đổi trong dự án androMDA và giúp phát triển trình tạo mã .Net từ mô hình UML. Một câu hỏi đặc biệt thú vị mà tôi thường được hỏi với tư cách là một kiến ​​trúc sư là làm thế nào để tôi xử lý các sơ đồ - UML và visio và hoa hồng hợp lý, v.v. Visio có lẽ là công cụ lập sơ đồ dễ tiếp cận nhất hiện có. Tôi đã có thể viết các kịch bản hàm để đọc sơ đồ hoa hồng hợp lý cho tôi. Tôi đã sử dụng một công cụ gọi là T-dub (hiểu sơ đồ kỹ thuật cho người mù) được phát triển bởi một số trường đại học Đức để truy cập các sơ đồ UML 2.0. Đã sử dụng một công cụ xấu xí dựa trên java có tên là Magic draw để thực hiện phát triển theo mô hình và là một người chuyển đổi trong dự án androMDA và giúp phát triển trình tạo mã .Net từ mô hình UML. Một câu hỏi đặc biệt thú vị mà tôi thường được hỏi với tư cách là một kiến ​​trúc sư là làm thế nào để tôi xử lý các sơ đồ - UML và visio và hoa hồng hợp lý, v.v. Visio có lẽ là công cụ lập sơ đồ dễ tiếp cận nhất hiện có. Tôi đã có thể viết các kịch bản hàm để đọc sơ đồ hoa hồng hợp lý cho tôi. Tôi đã sử dụng một công cụ gọi là T-dub (hiểu sơ đồ kỹ thuật cho người mù) được phát triển bởi một số trường đại học Đức để truy cập các sơ đồ UML 2.0. Đã sử dụng một công cụ xấu xí dựa trên java có tên là Magic draw để thực hiện phát triển theo mô hình và là một người chuyển đổi trong dự án androMDA và giúp phát triển trình tạo mã .Net từ mô hình UML. Tôi đã có thể viết các kịch bản hàm để đọc sơ đồ hoa hồng hợp lý cho tôi. Tôi đã sử dụng một công cụ gọi là T-dub (hiểu sơ đồ kỹ thuật cho người mù) được phát triển bởi một số trường đại học Đức để truy cập các sơ đồ UML 2.0. Đã sử dụng một công cụ xấu xí dựa trên java có tên là Magic draw để thực hiện phát triển theo mô hình và là một người chuyển đổi trong dự án androMDA và giúp phát triển trình tạo mã .Net từ mô hình UML. Tôi đã có thể viết các kịch bản hàm để đọc sơ đồ hoa hồng hợp lý cho tôi. Tôi đã sử dụng một công cụ gọi là T-dub (hiểu sơ đồ kỹ thuật cho người mù) được phát triển bởi một số trường đại học Đức để truy cập các sơ đồ UML 2.0. Đã sử dụng một công cụ xấu xí dựa trên java có tên là Magic draw để thực hiện phát triển theo mô hình và là một người chuyển đổi trong dự án androMDA và giúp phát triển trình tạo mã .Net từ mô hình UML.

Nói chung, tôi thấy rằng tôi phát triển mạnh nhất trong môi trường nhóm, nơi tôi có thể làm việc dựa trên những điểm mạnh của mình. Ví dụ, trong khi sơ đồ cực kỳ hữu ích để giao tiếp / ghi lại thiết kế, quy trình thiết kế thực tế bao gồm rất nhiều suy nghĩ và động não và khi thiết kế đã được nghĩ ra, một trong những đồng đội của bạn có thể giúp bạn nhanh chóng vẽ ra một cách gọn gàng hình ảnh ra khỏi nó Mọi người hiểu sai về những điều trên là thiếu độc lập hoặc khả năng trong khi tôi coi đây là sự phụ thuộc thuần túy - như tôi chắc chắn rằng một mình đồng đội không bao giờ có thể tự mình nghĩ ra thiết kế đó -turn, nếu tôi phụ thuộc vào anh ấy để làm tài liệu thiết kế, vì vậy hãy là nó. Hầu hết các rào cản tôi phải đối mặt là không thể truy cập dựa trên công cụ.

Tôi là một nhà phát triển mù và tôi làm việc theo Windows, GNU Linux và MacOS X. Mỗi nền tảng có quy trình làm việc khác nhau cho người dùng mù. Điều này phụ thuộc vào trình đọc màn hình mà nhà phát triển mù sử dụng. Các công cụ phát triển không hoàn toàn có thể truy cập được cho các nhà phát triển mù. Tôi có thể nhập mã và sử dụng các hàm biên dịch trong tất cả các IDE nhưng có nhiều vấn đề nếu tôi phải thiết kế giao diện bằng các công cụ thiết kế như Interface Builder, XGlade hoặc khác. Khi tôi đang phát triển với Borland Delphi, tôi có thể thêm một điều khiển, ví dụ như Nút và tôi có thể sửa đổi từng thuộc tính trực quan của điều khiển bằng cửa sổ thanh tra đối tượng. Nhiều IDE sử dụng các cửa sổ kiểm tra đối tượng để sửa đổi các thuộc tính trực quan và không trực quan, nhưng vấn đề đối với một nhà phát triển mù là thêm các điều khiển mới bởi vì phương pháp để thêm một điều khiển mới bao gồm kéo và thả điều khiển từ bảng màu vào khung vẽ. Visual studio 200x sử dụng các phương pháp thay thế để làm điều này nhưng giao diện của IDE thay đổi trong mỗi phiên bản mới và đây là một vấn đề lớn vì trình đọc màn hình cho Windows cần hỗ trợ đặc biệt, sử dụng tập lệnh, để xác định từng khu vực của một số ứng dụng không phổ biến. Một nhà phát triển mù có thể sử dụng Visual studio 2008 với trình đọc màn hình của mình nhưng khi một phiên bản IDE mới này xuất hiện, anh ta phải chờ phiên bản mới của các kịch bản cho phiên bản IDE này. Xcode với Trình xây dựng giao diện không có cách nào khác để kéo và thả các tác vụ. Tôi đã hỏi nó với Apple nhiều lần nhưng họ đang làm việc trong những thứ khác. Tôi đã xuất bản 3 ứng dụng trong Cửa hàng ứng dụng (Máy quét mìn có thể truy cập, máy xay trái cây có thể truy cập và Chương trình RSS ciegas) và tôi phải thiết kế tất cả giao diện theo mã. Đó là một công việc khó khăn nhưng tôi có thể quản lý tất cả các tính năng của từng điều khiển. Eclipse có một trình soạn thảo mã có thể truy cập nhưng các công cụ phát triển khác như bảng điều khiển gỡ lỗi, các trình cắm để thiết kế hoặc khu vực tài liệu có vấn đề đối với các công cụ hỗ trợ cho người dùng mù.

Tài liệu là một vấn đề cho các nhà phát triển mù quá. Nhiều mẫu và trình diễn sử dụng hình ảnh để hiển thị lời giải thích (đặt cài đặt môi trường như bạn có thể trong hình)

Tôi nghĩ rằng câu hỏi không phải là mù quáng. Câu hỏi đặt ra là các công ty và nhóm phát triển nghĩ rằng khả năng truy cập ảnh hưởng đến phần mềm cuối cùng nhưng nó không ảnh hưởng đến phần mềm phát triển. Họ nghĩ rằng một người dùng mù nên là một khách hàng nhưng một người dùng mù không thể là một người bạn phát triển.

Các hiệp hội mù yêu cầu khả năng tiếp cận các sản phẩm và dịch vụ nhưng họ quên các nhà phát triển mù. Người mù có thể làm luật sư, nhà báo, giáo viên nhưng một nhà phát triển mù là một khái niệm xa lạ ngay cả với người mù. Nhiều lần tôi cảm thấy cô đơn vì một số người bạn mù của tôi không thể hiểu công việc của tôi.

Bạn có thể đọc ý kiến ​​của tôi về vấn đề này trong bài viết này, bằng tiếng Tây Ban Nha, trong blog của tôi http://www.programaraciegas.net/2010/11/05/la-accesibilidad-en-crisis-para-los-desarrolladores-ciegos/ có một công cụ dịch thuật trong trang web. Xin lỗi nhưng tôi đã không dịch nó.

Emacs có một số tiện ích mở rộng để cho phép người dùng khiếm thị thao tác với các tệp văn bản. Bạn sẽ phải tham khảo ý kiến ​​chuyên gia về chủ đề này, nhưng emacs có khả năng chuyển văn bản thành giọng nói. Và có lẽ nhiều hơn nữa.

Ngoài ra, có BLinux:

http://leb.net/blinux/

Linux cho người mù. Đã được khoảng một thời gian rất dài. Tôi nghĩ hơn mười năm, và rất chín chắn.

Hãy nhớ rằng "mù" là một loạt các điều kiện - có một số người mù về mặt pháp lý có thể đọc một màn hình thực sự lớn hoặc với sự trợ giúp phóng đại, và sau đó có những người không có tầm nhìn. Tôi nhớ một bạn cùng lớp ở trường đại học có một thiết bị đặc biệt để phóng to sách và phần mềm đặc biệt cô ấy có thể sử dụng để phóng to một phần của màn hình. Cô đã làm việc chăm chỉ để hoàn thành đại học, vì thị lực của cô ngày càng tồi tệ và sẽ biến mất hoàn toàn.

Lập trình cũng có một loạt các nhu cầu - một số người rất giỏi trong việc tạo ra rất nhiều mã, và một số người giỏi hơn khi nhìn vào bức tranh lớn và kiến ​​trúc. Tôi sẽ tưởng tượng rằng với những khó khăn do giao diện màn hình gây ra, mù có thể tăng cường khả năng của bạn để có được bức tranh lớn ...

Hanselman đã có một podcast thực sự thú vị với một nhà phát triển mù gần đây .

Tôi đã làm việc cho Hiệp hội Người mù Greater Detroit trong ba năm điều hành BBS phù hợp với quyền truy cập mù và làm việc với một số người dùng mù về cách đáp ứng tốt hơn nhu cầu của họ và với những người dùng mới bị mù để họ thích nghi với phần cứng có sẵn và dịch vụ phần mềm có sẵn tại thời điểm đó. Nếu không có gì khác, ít nhất tôi đã học cách đọc chữ nổi như một hàng rào chống lại trường hợp tôi từng bị thương trong tình huống tương tự!

Phần lớn người dùng và lập trình viên mù sử dụng một trình đọc màn hình thuộc loại nào đó. Hàm nói riêng là phổ biến. May mắn thay, hầu hết các ứng dụng lớn ngày nay cung cấp một số hình thức truy cập khuyết tật. Bạn có thể phải điều chỉnh môi trường của mình một chút để cắt giảm cuộc trò chuyện, ví dụ như xem xét việc vô hiệu hóa Intellisense trong Visual Studio.

Một màn hình chữ nổi ít phổ biến hơn và tương đối đắt hơn nhiều và có thể hiển thị 40 hoặc 80 cột văn bản và có thể được sử dụng khi định vị / dấu câu chính xác là quan trọng. Mặc dù trình đọc màn hình có thể được cấu hình để xử lý dấu chấm câu, rất nhiều người thấy nó gây mất tập trung và trong nhiều trường hợp sẽ dễ dàng hơn trong việc cảm nhận theo cách của bạn. Hàm có thể được cấu hình để điều khiển màn hình, vì vậy bạn không tung hứng các ứng dụng trợ năng.

Ngoài ra, rất nhiều người dùng mù về mặt pháp lý vẫn còn một số ít cảnh tượng để lại cho họ. Sử dụng hình nền có độ tương phản cao và chức năng phóng đại có thể giúp ích rất nhiều cho những người dùng này.

Sử dụng ToggleKeys trong Windows sẽ cho phép bạn nghe khi bạn vô tình chạm vào một trong các phím 'mũ khóa', 'khóa num', 'khóa cuộn', v.v.

Tôi biết ít nhất một lập trình viên Haskell sử dụng trình đọc màn hình và lập trình rõ ràng các chương trình mà không sử dụng quy tắc bố cục của Haskell, và thay vào đó, sử dụng thay vào đó là không thành ngữ, nhưng được hỗ trợ {;}, bởi vì nó dễ dàng hơn / ít gây mất tập trung hơn cho anh ta trình đọc màn hình của anh ta để đọc dấu chấm câu hơn là để anh ta tìm ra vết lõm chính xác tuân thủ các quy tắc bố cục của Haskell. Cũng với lưu ý đó, tôi đã nghe thấy một vài lời cằn nhằn từ một vài lập trình viên mù về việc họ phải viết Python.

Cuối cùng, bạn học cách chơi trên những điểm mạnh của mình.

Tôi không thể nhớ lại nguồn, nhưng tôi đã nghe / đọc về một dạng cú pháp âm thanh "tô màu" - để thay vì một chuỗi gán được đọc là

foo bằng trích dẫn này là một trích dẫn chuỗi

phần chuỗi sẽ được đọc với một cao độ hoặc giọng nói khác nhau để làm cho sự phân tách các yếu tố rõ ràng hơn.

Một nơi để bắt đầu là dự án Blinux:

http://leb.net/blinux/

Dự án đó mô tả cách lấy Emacspeak (trình chỉnh sửa với văn bản thành giọng nói) và có rất nhiều tài nguyên khác.

Tôi đã làm việc với một người nhìn bằng mắt nhưng không cho họ sử dụng màn hình - họ đã làm tốt với phần mềm đọc màn hình và dành nhiều thời gian để sử dụng các ứng dụng dựa trên văn bản và trình bao.

Danh sách các gói trình đọc màn hình của Wikipedia là một nơi khác để bắt đầu: http://en.wikipedia.org/wiki/List_of_screen_readers

Tôi là một sinh viên sau đại học tại Bắc Kinh, Trung Quốc. Tôi chuyên ngành khoa học máy tính và rất nhiều công việc của tôi là lập trình. Tôi sinh ra với thị lực kém, tôi cần sử dụng các công cụ phóng đại để nhìn rõ phông chữ trên màn hình. Tôi sử dụng các công cụ nhận dạng của microsoft trên windows và sử dụng công cụ phóng to của compiz nếu trên linux. Tôi thường đặt công cụ để phóng to gấp ba lần kích thước phông chữ gốc. Đối với tôi công cụ maginify là ok, vấn đề chính là tốc độ, tôi phải di chuyển chuột để giữ con trỏ theo văn bản tôi đang xem, phóng to của microsoft cung cấp tùy chọn "tự động theo các điểm chỉnh sửa văn bản", điều đó đặt tôi từ di chuyển chuột liên tục khi chỉnh sửa hoặc mã hóa. Nhưng nó không phải lúc nào cũng hoạt động vì phần mềm chỉnh sửa hoặc IDE có thể không hỗ trợ điều đó. Các công cụ phóng đại trên linux rất khó sử dụng. KMag đi kèm với KDE có tốc độ làm mới khủng khiếp khiến mắt tôi không thể tin được, phích cắm phóng đại của công ty mà tôi đang sử dụng hiện tại vẫn ổn, nhưng không có chức năng lấy nét tự động (lấy nét tự động theo sau). iOS cung cấp giải pháp khá hoàn hảo cho tôi với phóng to toàn màn hình, đặc biệt là trên màn hình 9,7 inch của ipad. không cần lấy nét tự động vì tôi hầu như không sử dụng chúng để viết mã hoặc thực hiện các công cụ chỉnh sửa khác. Android cung cấp rất ít chức năng trợ năng, chỉ như phản hồi rung, điều này vô dụng đối với tôi. không có bất kỳ loại công cụ phóng đại tốt nào trên Android, chưa kể đến chức năng nâng cao như phóng to toàn màn hình trên iOS. Tôi đã từng học Qt, muốn xây dựng một công cụ phóng to hữu ích trên linux, thậm chí trên Android. Nhưng hầu như không có một số tiến bộ. nhưng không có chức năng lấy nét tự động (lấy nét tự động theo sau). iOS cung cấp giải pháp khá hoàn hảo cho tôi với phóng to toàn màn hình, đặc biệt là trên màn hình 9,7 inch của ipad. không cần lấy nét tự động vì tôi hầu như không sử dụng chúng để viết mã hoặc thực hiện các công cụ chỉnh sửa khác. Android cung cấp rất ít chức năng trợ năng, chỉ như phản hồi rung, điều này vô dụng đối với tôi. không có bất kỳ loại công cụ phóng đại tốt nào trên Android, chưa kể đến chức năng nâng cao như phóng to toàn màn hình trên iOS. Tôi đã từng học Qt, muốn xây dựng một công cụ phóng to hữu ích trên linux, thậm chí trên Android. Nhưng hầu như không có một số tiến bộ. nhưng không có chức năng lấy nét tự động (lấy nét tự động theo sau). iOS cung cấp giải pháp khá hoàn hảo cho tôi với phóng to toàn màn hình, đặc biệt là trên màn hình 9,7 inch của ipad. không cần lấy nét tự động vì tôi hầu như không sử dụng chúng để viết mã hoặc thực hiện các công cụ chỉnh sửa khác. Android cung cấp rất ít chức năng trợ năng, chỉ như phản hồi rung, điều này vô dụng đối với tôi. không có bất kỳ loại công cụ phóng đại tốt nào trên Android, chưa kể đến chức năng nâng cao như phóng to toàn màn hình trên iOS. Tôi đã từng học Qt, muốn xây dựng một công cụ phóng to hữu ích trên linux, thậm chí trên Android. Nhưng hầu như không có một số tiến bộ. Android cung cấp rất ít chức năng trợ năng, chỉ như phản hồi rung, điều này vô dụng đối với tôi. không có bất kỳ loại công cụ phóng đại tốt nào trên Android, chưa kể đến chức năng nâng cao như phóng to toàn màn hình trên iOS. Tôi đã từng học Qt, muốn xây dựng một công cụ phóng to hữu ích trên linux, thậm chí trên Android. Nhưng hầu như không có một số tiến bộ. Android cung cấp rất ít chức năng trợ năng, chỉ như phản hồi rung, điều này vô dụng đối với tôi. không có bất kỳ loại công cụ phóng đại tốt nào trên Android, chưa kể đến chức năng nâng cao như phóng to toàn màn hình trên iOS. Tôi đã từng học Qt, muốn xây dựng một công cụ phóng to hữu ích trên linux, thậm chí trên Android. Nhưng hầu như không có một số tiến bộ.

Khi tôi còn đi học, chúng tôi có một thành viên trong nhóm nghiên cứu bị mù. Anh ấy lớn hơn một chút, có lẽ là giữa những năm 40. Anh ấy nói với chúng tôi về cách anh ấy lập trình máy tính đầu tiên của mình (cũng khá phổ biến trước khi chuyển văn bản thành giọng nói) để xuất nội dung của màn hình trong Mã Morse. Để khắc phục vấn đề trứng gà rõ ràng, anh ta phải viết lại hoàn toàn mã mỗi lần từ đầu cho đến khi nó hoạt động đủ tốt để anh ta đọc lại cho anh ta.

Bây giờ anh ta sử dụng chuyển văn bản thành giọng nói, mặc dù anh ta lên kế hoạch mã rất kỹ lưỡng trước khi thực sự viết bất kỳ đoạn nào, để giảm thiểu vòng lặp gỡ lỗi.

Anh ấy cũng khá giỏi trong việc đưa ra các bài thuyết trình PowerPoint, mặc dù anh ấy không có thị lực, cũng có định dạng tốt như bất kỳ người thuyết trình nào nhìn thấy.

Bài đăng trên blog này có một số thông tin về cách nhóm Visual Studio làm cho sản phẩm của họ có thể truy cập được:

Hoạt động tham quan phòng thí nghiệm của Visual Studio Core Team

Nhiều lập trình viên sử dụng Emacspeak:

Emacspeak - Máy tính để bàn hoàn chỉnh

Trở lại New Zealand, tôi biết một người bị thoái hóa điểm vàng , nên đã bị nhìn thấy một phần. Anh ta là một lập trình viên rất tài năng và sử dụng Delphi vì anh ta có thể làm việc bằng cách nhận ra các hình dạng từ Điều này dễ thực hiện hơn với cú pháp giống như Pascal so với một dấu ngoặc vuông C-ish. Anh ấy có một trang web, nhưng dường như không đề cập đến thoái hóa điểm vàng, vì vậy tôi sẽ không đặt tên cho anh ấy.

Tôi bị mù và từ vài tháng nay, tôi đang sử dụng VINUX (một bản phân phối linux dựa trên Ubuntu) với SODBEANS (một phiên bản của netbeans có bổ trợ có tên là SAPPY có thêm hỗ trợ TTS). Giải pháp này hoạt động khá tốt nhưng đôi khi tôi thích khởi chạy Win XP và NVDA để khởi chạy nhiều trang trên FireFox vì Vinux không hoạt động tốt khi bạn cố mở hơn 3 cửa sổ của FireFox ...

Như nhiều người đã chỉ ra, emacspeak là giải pháp đa nền tảng lâu dài cho nhiều tin tặc cũ ngoài kia. Vì nó hỗ trợ Linux và Mac ngay lập tức, nó đã trở thành phương tiện ưa thích của tôi để phát triển các dự án nhận thức Windows.

Đối với vấn đề thực sự đi xuống cú pháp thông qua một thính giác trái ngược với một hình ảnh trực quan, tôi đã thấy rằng tồn tại một loạt các kỹ thuật để có được một gần gũi nếu không trên cùng một sân chơi.

Các biểu tượng thính giác có thể thay thế cho các mô tả bằng lời nói cho một ví dụ. Bạn có thể, đặt âm cho khoảng cách một dòng được thụt vào. Âm càng dài, vết lõm càng xa. Vì các âm có thể phát song song với văn bản thành lời nói, thông tin đi qua trong cùng một khung thời gian và không tuần tự hóa việc giao tiếp của một cái gì đó rất cơ bản.

Chữ nổi có thể giải mã nhanh chóng và chính xác cho người dùng cú pháp chính xác của một dòng. Đây là một cái gì đó hữu ích hơn cho những người sử dụng chữ nổi trong cuộc sống hàng ngày; lợi thế lớn nhất là truy cập ngẫu nhiên vào nội dung của màn hình. Các đơn vị có thể làm mới thường có các phím bộ định tuyến phía trên mỗi ô ký tự có thể đặt con trỏ đến ô đó. Không đấu tranh với các phím mũi tên O (n) op vs O (1) truy cập.

Chiều kích thính giác (cao độ, tỷ lệ, âm lượng, biến động, độ phong phú, căng thẳng, v.v.) có thể truyền đạt một khái niệm (từ khóa, lớp, biến, lỗi, v.v.). Ví dụ, các bình luận có thể được đọc trong một biến động đơn điệu ... phù hợp, nếu tôi có thể nói như vậy :).

Emacs và các trình soạn thảo khác ở mức độ thấp hơn (Visual Studio) cho phép một lập trình viên kiểm tra chương trình một cách tương ứng (khối tiếp theo, khối gấp, xuống defun, nhảy đến def, đi lên cây phân tích, v.v.). Bạn có thể nhanh chóng có được bức tranh "lớn" về cấu trúc của toàn bộ dự án đang làm điều này; với các tiện ích mở rộng như Cedet, bạn có thể nhận được sự tốt đẹp của nền tảng chéo VS / Eclipse / etc và trong trình soạn thảo văn bản.

Có lẽ có thể tiếp tục, nhưng một cách ngắn gọn, đó là cơ sở lý do tại sao một số người trong chúng ta ra khỏi đó để hack trong ngành công nghiệp, adacdemia hoặc trong tầng hầm của chúng tôi :).

Một nhóm sinh viên từ Đại học Nam Illinois Edwardsville và Đại học bang Washington đang nghiên cứu ngôn ngữ lập trình cho người khiếm thị:

http://www.youtube.com/watch?v=lC1mOSdmzFc

harald van Breederode là một chuyên gia, huấn luyện viên và người dẫn chương trình Oracle DBA nổi tiếng người Hà Lan bị mù. Blog của anh ấy chứa một số lời khuyên hữu ích cho người khiếm thị.

Điều gì trên thế giới một bàn phím chữ nổi thậm chí là ??

Có những thứ như nhà văn chữ nổi nhưng bạn sẽ không bao giờ sử dụng nó làm thiết bị đầu vào cho máy tính.

Nếu bạn chỉ đơn giản nói về một bàn phím có ký hiệu chữ nổi trên đó thì đây cũng là một ý tưởng rất tồi. Bạn sẽ có nhiều phím hơn để tiếp cận trong khi gõ và nó vẫn sẽ chậm hơn.

Gõ cảm ứng KHÔNG phải là một kỹ năng thị giác, một người mù có thể làm điều đó tốt như một người nhìn thấy.

Tôi nghĩ rằng điều này sẽ hoạt động tốt trong lập trình cực đoan bằng cách sử dụng nguyên tắc lập trình cặp. Nếu bạn đang tạo ra phần mềm cho người mù, ai làm tốt hơn thì ai đó thực sự sẽ tiếp xúc với các yêu cầu kinh doanh, vì vậy tôi không nghĩ rằng nó rất xa vời.

Đối với việc viết mã, tốt, trừ khi có một số loại phản hồi tôi nghĩ rằng một người có thể đấu tranh với cú pháp. Phản hồi âm thanh có thể giúp một điểm mặc dù.

NVDA là một trình đọc màn hình nguồn mở tốt để giành chiến thắng.

Điều gì về việc phát minh ra một loại thiết bị mà bạn cắm vào cổng usb và về cơ bản đó sẽ là một "tấm cao su" có thể tự sửa đổi để hiển thị mã của bạn, cho phép người mù đọc nó thay vào đó để nghe?

Có nhiều công cụ hỗ trợ người mù hoặc nhìn thấy một phần bao gồm phản hồi lời nói và bàn phím chữ nổi. http://www.rnib.org.uk/Pages/Home.aspx là một trang web tốt để được giúp đỡ và tư vấn về những vấn đề này.

Khi tôi gặp Sam Hartman, anh ấy là một nhà phát triển Debian nổi tiếng từ năm 2000 và bị mù. Trong cuộc phỏng vấn này , ông nói về khả năng truy cập cho một người dùng Linux. Anh ta sử dụng Debian và gnome-orca làm trình đọc màn hình, nó hoạt động với Gnome và "thực hiện công việc tương đối tốt khi nói Iceweasel / Firefox và Libreoffice".

Nói cụ thể về lập trình, ông nói:

Mặc dù [gnome-orca] không nói được gnome-terminal, nhưng nó không thực sự đủ tốt để nói các chương trình thiết bị đầu cuối mà tôi cảm thấy thoải mái khi sử dụng nó. Vì vậy, tôi chạy Emacs với gói Emacspeak. Trong đó, tôi chạy trình giả lập thiết bị đầu cuối Emacs và trong đó, tôi có xu hướng chạy Màn hình. Để thêm phần thú vị, tôi thường chạy các phiên bản bổ sung của Emacs trong các màn hình bên trong.